Recently there was an email on the Scrum development mailing list regarding how to keep a common, consistent architecture which is maintained and used throughout multiple Sprints without someone designated as architect. Here was my response:
I would consider myself a software architect with quite a few projects under my belt. I started using some Agile techniques before I knew what Agile, XP, or Scrum were. I ended up finding myself working more on getting teams to collaborate and come to decisions based on good information rather than prescribing a particular architecture approach. As I have come to find out over many years, there are many approaches to architecture (as in design) that can work in particular contexts. Just as OO development and design patterns are not the best way to develop software in every project (such as real time systems and device manufacturing), so to is it not the case that architecture (more than minimal design) is needed.

“Disclaimer”:

—

Before I go sticking my foot in my mouth, the following scenarios are generalized and probably overkill for most organizations. Stick to the least amount of controls that will keep enough chaos for your particular needs. I am working with a company right now in which we are possibly implementing some of what is discussed below. They have an existing “Architecture”-based organization and we are trying to help them become more Agile. I hope that the topics discussed below are helpful in thinking about your organization but if not I wouldn’t be surprised.

—

I run a local chapter in the Puget Sound (Seattle) area of the IASA (Int’l Assoc. of Software Architects) and will be facilitating discussion and breakout activities on how Agile and architecture teams work together. There is more information on this at http://www.solutionsiq.com/iasa.html. There are multiple disciplines within the “Architecture” realm such as Enterprise (more business focused), Infrastructure (more hardware / facilities focused), and Solutions (more application/data focused). Each of these perform a service based upon a perspective of the organization which I believe can fit well with Agile.

“Potentially about the original email”:

—

If the Solutions Architect can be closer to the team (potentially on the team) to help in the development of the product that could be very helpful. We want to make sure they are prepared to be a member of the team and not a special case. If the rest of the team can understand and somewhat agrees with the architect about their ideas then that person will automatically get respect from other team members. It is also good if the architect can be coached on how to incorporate the ideas of others into the design, potentially on less critical areas, to help foster respect across the team.

As for the “not coding” aspect of this, I think this may be a concern overall. I just conducted a training session on TDD where one of the attendees, whom we coached to implement Scrum and Continuous Integration already, wanted to make it clear that design was needed. We tried to make sure it was understood that design was still done, whether it was through the automated unit test code or on paper napkins translated into test code, but that decisions about platform, frameworks, and services may not be needed from the start. We should implement in the simplest form first and then refactor to a desired design which may over time incorporate what is thought of as software architecture design. It was very difficult to get this point across entirely but I believe it can be learned over time.

This may be the situation that you are in. How do you facilitate that learning about keeping good design even though it is emerging throughout the product development life cycle. One way that I sometimes facilitate this is by giving the problem context to the group (possibly the solutions architect group) and have them figure out how they can best work in this model. Allow them to be skeptical of the model and answer their own questions. You may need a coach for this if you do not have somebody who feels comfortable speaking about architecture design and it’s use in Agile development.

—

“To further the Architecture and Agile discussion”:

—

The Solutions Architect is closer to the implementation of products/projects within an organization. They are a good fit to be team members on a particular project, a mentor for teams using new technology, taking tasks on multiple team sprint backlogs (hopefully not all at the same time), and providing communication support to the Enterprise Architecture group (feedback loop for potential best practices, issues with vendors, etc…).

An Infrastructure Architect “may” be close to the implementation teams at times and have their own long-term vision, short-term goals, and possibly running multiple Agile projects. They need to align closely with the teams, Enterprise Architecture group, and possibly product teams to make sure the vision and goals of the Product Owner and supporting cast (SME, customers, analysts). We still need to think about deployment in large organizations in order to keep it manageable, supportive of product delivery, and cost effective.

The Enterprise Architect tends to be a helper in the translation of product vision into attainable goals. The problem with many implementations of EA within organizations is that it is quite prescriptive in managing vendor, platform, processes, and data choices. This can put a strangle hold on the potential output of the entire organization and is a large burden on the EA group itself. In my experience, an EA may be a good choice as the Product Owner mostly in large projects. They understand how to remove potential integration dependencies, how business functions with technology, and the higher level picture of the business. They can help in the discussing all of these important items with the implementation teams to help them in making better decisions with a bit of Product Owner training and further understanding of Agile values and principles.

—

I am quite interested in hearing other people’s views on this and any constructive criticism about the content. This topic can get quite deep and have so many potential scenarios that I have discussed here but if we keep our eyes on the Agile values and principles we can figure out how we can work together better. Thanks.