The Role of the Agile Architect

We’re Agile, we don’t need no stinkin’ architects!

It would seem that Agile principles are in direct conflict with a traditional software architect role — in an agile project, where the creation of working, tested code trumps everything else, nothing separates architecture from design and implementation. They are all wrapped up together in the practices we use to produce the code.  Instead of traditional documents and diagrams, the architecture is going to be exposed through the software itself…

So what does an Architect do in an architecture-antagonistic TDD/Agile/XP shop?

Mark J. Balbes, PhD recently shared his experiences as an Agile Architect, and it was so compelling we just had to share.

Architecture Is a Frame of Mind

To Mark, architecture is a frame of mind. There is no room for an “ivory tower” architect that sits at a desk creating diagrams and making architectural rules for development teams to follow. Agile development favors person-to-person communication over written documentation. If you’re an agile architect, the best place to be is in the war room with the development team, working alongside them every day.

The architect’s role, then, is not to dictate to the team, but rather to guide, mentor and cajole the team in the right direction.

The War Room Is Where It’s At

The hustle and bustle of development is exciting and provides almost everything Mark needs to do his job. In the war room, Mark can listen to what is going on with the team, shepherd the team to keep the software development moving in the right direction and mentor team members on the concepts they may not be familiar with.

Listen First

Mark has found that as an agile architect, listening is the most important skill. In the war room, he has positioned himself so he can hear all that goes on. Part of his job is to listen to the discussion, pick out the important aspects of each side, help the team see the advantages and disadvantages of each proposed solution then come to a consensus.


Mark also acts as a mentor to the team. While he is certainly not the strongest technical member of the team, he can often see potential solutions that the rest of the team misses because he is looking at the problem from a different perspective.

Shepherd the Team

Mark is a shepherd for the team. There’s a saying, “The road to hell is paved with good intentions.” That is definitely true for agile software development, where a series of small solutions can snowball into an unwieldy mess. The problem arises out of the agile philosophy of doing the simplest thing possible to solve a problem and not trying to solve tomorrow’s problems today. This philosophy works well most of the time. However, there are occasions when a series of simple enhancements builds to an unworkable or unmaintainable solution. It’s Mark’s job to see when that is happening and change course before his team wastes too much time and effort.

It’s All About the Code…

The agile architect is a jack-of-all-trades, doing what is necessary to ensure architectural integrity of the product.  Listening, guiding, mentoring and cajoling are all part of the job.  While the team owns the solution to a problem, it is the architect’s job to state what the qualities of the solution should be.  And when something is particularly tricky or important, the agile architect rolls up his sleeves and gets to work coding with the rest of the team.

The agile architect must understand the current state of the software and know where it is going. He must spend his time with the team and be involved in all aspects of the project. The days of the ivory tower architect, sitting in an office producing diagrams and documents that may or may not be relevant, are dead.

[HT: ADTMag]

11 Replies to “The Role of the Agile Architect”

  1. Good post, however I think you’re speaking in generalizations. While it’s true that agile teams can favour building a solution in increments that lead to code-first myopia, that’s more an antipattern than a rule of thumb when it comes to architecture.

    Since the early days of Scrum and XP, the suggested guidance has been to build a system in thin slices that cut across all aspects of the proposed solution architecture, not just an isolated portion. The goal is to not just have working code, but rather working code that demonstrates an end-to-end solution.

    Having an embedded architect is good in this regard because they can help guide the team on how to hook up the hoses – but they need to be cognizant that the design is going to evolve and emerge as various aspects are put into motion, tested, inspected and adapted.

    In this regard, having an architect who can code would be a good idea; however, I’d be reluctant to have them “cajole” and “sheperd” the team into their wishes – they could be just as wrong as anyone, and it subordinates the role of the team to a mini-PM under a loose command-and-control structure.

    1. Thanks for the feedback here. I think there needs to be a healthy balance between architect leadership and helping guide the team.
      I had a class this week where a participant said that master software architects are key to agile projects… please, when you find one, let me know. I have yet to find a ‘master’ anywhere!

  2. Great post. I think this is a very good description of how the architect role changes on an Agile team. I’d go further and not have the title ‘architect’ at all. A technical leader is a technical leader regardless of what you call them.

    The points here are great for architects to aspire to.

    1. Yep. I agree. What do titles do anyway other than further hierarchy structures? In agile we talk about “teams.” A team is a full package of people. All working together. “Architect” included… 🙂

  3. Pingback: The Role of the Agile Architect | Agile | Syngu
  4. Great article, Peter. I would suggest that a team that has been formed to produce a relatively long-lived solution needs to consider the whole life cycle of their product. How will you craft a product that is supportable, sustainable, extensible, and highly available, at the lowest achievable life cycle cost? These aren’t product owner concerns, but they are valid concerns of the organization funding the development. Having an owner and advocate for those non-functional requirements, in the same way the product owner owns responsibility for the functional requirements, is a natural extension of Agile in general and Scrum in particular.

Leave a Reply