Agile and Architecture Should Be Friends

One of the most misunderstood and misrepresented documents in the history of software development is the Agile Manifesto. This may be due to many of its readers overlooking the phrase “there is value in the items on the right.” Most seem to focus on the items on the left only. Here’s the text that Cunningham, Fowler, Martin and other giants in the field created:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while t here is value in the items on the right,
we value the items on the left more.

Note that I have emphasized the items on the right. These do indeed have value but so many advocates of Agile deliberately ignore and even exclude these from their software development process and organization. Some have advocated the elimination of architecture and design entirely, leaving these open to gradual discovery through the iterative process driven by use cases and user stories and backlog tasks.

Recently I have read a number of discussions, blog posts and articles on the question of Agile and Architecture. The comments and discussion around the topic have been interesting. Perhaps this is due to the notion that developing software is only about writing the code. The general theme of these sources is that architecture (and design) are at odds with and excluded by Agile. This is one of the great fallacies of our time.

Process is the How Not the What

We really must dispel the notion that any process, whether it is waterfall or Agile and any of its variants such as Scrum, dictate the what. There is nothing in a process that tells you what to build. The process is simply there as a device to assist in putting a structure to the "how to go about building what must be built."

Compare software with cooking, if you will, for a very large number of people for several weeks. You know that you must organize your team help them find an efficient way to go about delivering three meals a day for weeks. This is the process. It has nothing to do with the ingredients and recipes. Granted you may need to adjust your process a little based on the specifics of what you plan to cook, but the food itself and what goes into it is not the process. It is the what not the how.

Architecture and Design Are Software Development Artifacts

Teams and organizations who skip architecture and design will sooner or later find themselves off track and repeating work unnecessarily. Such waste is not entirely preventable, but this does not mean we should not try. Teams that incorporate these activities into their iterations, regularly revisiting architectural questions such as non-functional requirements and component design, will find that they are better able to stay on course.

Organizations that have multiple teams will find greater stability in moving forward when guided by a centralized architecture team, comprised of architects or leads who are dedicated to and work within the organizations development teams. The architecture team works in an Agile fashion, with its own backlog and its own products including working prototypes, cross cutting standardized components, documentation of the architecture and designs, and work items to be placed on the backlogs of development teams.

In this way, development teams have dependencies on the architecture team and can make requests for additional guidance or improvements or extensions to shared, standardized libraries for which the architecture team is responsible. These requests keep the backlog of the architecture team charged with work throughout the software development lifecycle.

In addition to formal activities to improve architecture and design across the organization, the architecture team should regularly interact with development teams to include (but not limited to) the following:

• practice improvement activities—e.g. SOLID principles
• technology deep dives—e.g. digging deeper into .NET
• technical solutions brainstorming sessions—solving the hard problems
• technical debt evaluation and pay-down planning
• code reviews and walkthroughs—one on one and as a team
• presenting and sharing solutions and ideas from other development teams
• exploring and evaluating new technologies and tools

Like testing and coding, architecture and design are a part of the whole of software development. These activities are perfectly suited to Agile development practices, including Scrum. And when all of these aspects of delivering quality software are taken into account and incorporated into your Agile process, your chances of success are greatly improved.

Agile and Architecture Should Be Friends

Like the great musical that advocates that farmers and cowboys should be friends, we should accept that Agile (or any other process) has its place as does architecture and design. We cannot get along without them both.