Exploring the Myths Around Agile and Architecture

By Scott Ambler

Agile and architecture?  Crazy talk!  As many agilists will readily tell you, they have little need for the inherent overhead of architecture.  Similarly, many architects will tell you that agilists are nothing more than inexperienced children who don’t know that they’re in over their heads.  These of course are just two of the enduring misunderstandings that have kept agilists and architects from working together effectively.  In this blog I explore the myths that are preventing us from collaborating with, and learning from, each other.

I’ve straddled the agile and architecture communities for years, having led the development and evolution of the Agile Modeling method since 2001 and working with IASA from its very early days.  All of the myths described below have a basis in fact, but at the same time none of them are completely accurate either.  We can and should do better.

Myths Architects “Know” About Agile

Let’s explore the “undisputed facts” that architects know about agilists:

1. Architecture isn’t even an aspect of agile. Architecture, whether you care to admit it or not, is an important aspect of any software development method. Having said that, some agile methods such as Scrum purposefully do not address technical practices around architecture, design, testing, and so on.  You’re expected to tailor in fit-for-purpose techniques to address these aspects. Because Scrum rhetoric tends to dominate discussions about agile, this can be confusing for non-agilists.
2. Agilists don’t understand the bigger picture. Agilists tend to focus on the team and the immediate needs of their stakeholders, not the overall needs of the organization. As a result, agilists can be perceived to not grasp the bigger picture, which is fair enough because they often don’t. Disciplined agilists, on the other hand,follow the principle of enterprise awareness and thus explicitly consider organizational issues and long-term strategies.
3. Agile architecture strategies are naïve at best. This depends on the agile strategy that you’re following.  Extreme Programming (XP) addresses architecture via metaphors, which is likely what gives most architects pause, and Scaled Agile Framework (SAFe) promotes the concept of architectural runways.  Architectural runways are their way of saying architecture models, but because tends to be a swear word for most agilists most agile methods will choose to avoid using it (as well as other words like governance, management, serial, and phase).  Disciplined Agile, taking a more robust tack, embraces and promotes agile architecture strategies and roles throughout the entire tool kit.
4. Agilists can’t architect. This is observably not true, given the number of mission-critical software-based solutions, including life-critical ones, built using agile strategies. You very likely use some of these solutions on a daily basis.

Myths Agilists “Know” About Architecture

Now let’s explore the “undisputed facts” that agilists know about architects:

1. Architecture is big design up front (BDUF), and BDUF is bad. Since the early days of agility BDUF has been considered bad, bordering on evil, and to be honest a very large percentage of software projects have gone astray because of too much up-front modeling and planning. But that doesn’t mean that initial architecture modeling is bad, it means that too much is bad.  The key is to do just enough up-front modeling as the situation warrants.
2. Architects only create nice PowerPoint decks. To be fair, there are a lot of PowerPoint architects out there, but not every architect is like that. And sometimes you do in fact need a nice PowerPoint deck to help get your point across.  The real problem is architects who only create models, white papers, and slide decks and not roll up their sleeves to actively help teams in architecture.
3. Architects will only slow us down. Traditional architecture will very likely slow down and increase the risk to an agile team. Agile architecture strategies, those that are collaborative and evolutionary in nature, will not do that but instead will often decrease both overall calendar time and technical risk for the team.  It is possible for architects to add real value on agile teams, but to do so they must be agile themselves.
4. Architects can’t be agile. Agile software teams build working solutions in a collaborative and evolutionary manner, not a serial manner. For someone to add value on such a team they must be flexible, willing to learn, willing to share, and willing to be involved with work outside of their speciality. In short, architects working with a software team will need to be willing to write code, to test, to analyze, and do anything else required to help the team to succeed.

Choose to Look Beyond These Myths

My experience is that architecture is an important part of agile and that architects can greatly benefit from working in an agile manner.  We need to work together to break down the barriers, and that requires flexibility, open-mindedness, respect for one another, and a willing to experiment with new ways of working.

This is the first of a series of blog postings that I will write about agile architecture.  In this blog I’ve made several interesting claim that I will expand upon in future writings. Stay tuned.