Agile Needs More Architecture ‘Stuff’

By Scott Ambler

Sometime during 2022 or 2023 the agile gold rush, but not the agile movement itself, ended. I recently I wrote The Agile Community Shat the Bed where I explored what I believe to be the key reasons for this: too much framework adoption rather than actual improvement; too much agile certification rather than education; too many fads rather than grounded strategies; too much purity rather than agility; and too much fluff rather than stuff.  In this article I discuss how a lack of “architecture stuff” in mainstream agile contributed to the mess the agile community currently finds itself in.

First, let’s explore how mainstream agile pretty much ignored architecture over the past two decades:

1. Mainstream agile frameworks didn’t address architecture in a meaningful way. Scrum purposefully didn’t address technical issues, including architecture. While I have always argued that this was a valid scoping decision by the people behind Scrum, I also argued that it was a serious mistake to do so. SAFe® was a bit better, having architecture bolted on in the early 2010s in the form of an architectural runway, but there wasn’t any real meat there. The Disciplined Agile® (DA) toolkit explicitly addressed architecture, and roles for architects, in a detailed manner but was a distant third in the marketplace compared to Scrum and SAFe.
2. Agile certification didn’t address architecture in any meaningful way. The only real body of knowledge around agile architecture was contained in the Agile Modeling method, but there was no certification scheme for it. DA, and I presume SAFe certification, addressed architecture in their certifications to the extent that they included architecture.
3. Agile architecture wasn’t faddish enough. The only agile architecture fad that I can point to would be in the early days of agile when the extreme programmers liked to talk about having an architectural metaphor for whatever it was you were building. Interesting idea, but it was far too high-level and pretty much disappeared when XP was eclipsed by Scrum in the early ‘00s.
4. Architecture wasn’t on the radar screen for pure agile. In many ways the agile movement was a pushback against onerous management and modeling methods of the 1990s, including those around software architecture. Agilists railed against big design up front (BDUF), and rightly so, but then mainstream agilists wrongly took their rhetoric to the extreme to perform no up-front architecture at all. The belief that architecture would evolve over time, while true for competent teams, didn’t work well for teams that were short on architecture skills.
5. Architecture was addressed in a fluffy manner by agile teams. Complaining about BDUF, hoping that the architecture will emerge without putting in any real effort to have that happen, and waxing philosophically about architectural metaphors simply didn’t get the job done for some reason. If only someone had come up with some sort of architecture game, yeah, that would have worked! 🙄

The bottom line is that the concept of an agile approach to architecture didn’t fit well with the agile goldrush of the past two decades.  It didn’t have to be this way, given the wealth of agile architecture strategies available to practitioners and the ease of adopting them.

Agile Architecture “Stuff” Exists

I’ve written about agile architecture strategies here in Architecture & Governance Magazine for several years, sharing great ideas from Agile Modeling. These great ideas include, but certainly aren’t limited to:

1. A clear role for agile architects. The first step to get serious about architecture is to include an architect on agile teams. Agile Modeling calls this role architecture owner, a nod towards Scrum’s product owner role, although if you want to call this role agile architect or simply architect then go ahead. The important thing is that someone has the responsibility for guiding the team in architecture decisions and sharing architectural skills with others.
2. A clear role for agile enterprise architects. Similarly, to ensure that teams produce something that reflects the overall direction of your organization, there needs to be explicit support for enterprise architecture. Agile enterprise architects collaborate with, and guide, the architecture owners on agile teams.
3. Collaborative and inclusive modeling. A fundamental concept in agile is that teams work in close collaboration with one another, and this includes agile architects. Key strategies that support this include active stakeholder participation where the architecture owner collaborates with other people and inclusive modeling where simple tools and techniques are applied to do so.
4. Sufficient initial modeling. Disciplined agilists perform initial requirements and architecture modeling early in an initiative to identify what they need to do and how they believe they will do so. This initial modeling is high-level, providing enough insight for moving forward effectively.  A little bit of up-front thinking can go a long way towards ensuring success.
5. Prove the architecture with working code. A fundamental software engineering concept is to prove that your architecture strategy works early on via working code. You do this by building a “walking skeleton” that implements high-value requirements that require key components of your architecture strategy in place.

Agile is Transitioning to Something Better

Like other topics that required skill and experience, architecture didn’t fit well with the overall agile goldrush strategy. I believe that agile is currently in a trough, and that for the next few years the agile community will take a long, hard look at itself and will decide to do better.  Part of doing better will be to adopt a realistic strategy towards software architecture. Agile isn’t dead, but the agile goldrush is.