How Agile Architects Lead

Lisa, Vin, and Derek in their comments on Agile, Architects, and Programs were concerned about how an architect might lead the test architecture work. They have good reason to be concerned. I hadn’t expressed how I see architecture working in an agile program, and they haven’t been to my talks, where I have discussed it. This mind meld stuff doesn’t work yet in blogging. Sorry, folks. I’ll try to be more specific.

I am not talking about an external architect, who leads from an ivory tower and does not get his or her hands dirty. Read my most recent Gantthead.com column, Agile Architecture and Program Myths. External architects do not add value to an agile project or an agile program. Derek, while I agree with you in principle, have you worked on a complex product or system with a few hundred people? If you have and you have not had architects to guide the development, how did you succeed? I’m talking about guidance, not policing. I suspect we agree more than we disagree, but I’ll leave that decision to you.

First, the architect is responsible for the business value of the architecture, not for telling people what to do. An architect can do this in many ways:

1. Balancing the short-term goals with the overall system integrity, risk, expediency, technical debt, anything else that you would trade off short term goals against.
2. The ability to sustain development against technical debt. For test systems, this is the age-old problem of testing vs. automating the tests and how you automate the tests. I’m a huge fan of automate enough and refactor your way into what you need, because you may not know what you need until you see how the system under development evolves.
3. Writing acceptance criteria for system qualities and quality scenarios.
4. Leading the definition of how a complex system is structured, organized, and implemented. Landing zones can help guide this effort.
5. Working with the team in a hands-on way. No seagull architects. No PowerPoint architects. No prophets. No police. Agile architects develop code and develop tests.
6. Architects work with the entire project team, not just the challenging or interesting parts. In fact, if there are rote parts or boring parts, maybe that’s where the architect is needed most to automate something so humans don’t have to do it. In my workshops and in my executive briefings, I tell managers they should put their most talented people, aka architects, on the things that prevent them from easily moving to agile. For complex programs, those are most often the build system and test automation. I suggest they use the architects for several iterations to make significant progress on those problems, and get to some version of done.

There’s a reason I don’t call a program architect a “chief” architect. I don’t want to have the notion of hierarchy. I firmly believe that the architect is beholden to the program, to the business results, not to the organization’s hierarchy. That’s somewhat naive on my part, but using the word “chief” reinforces the hierarchy.

Architects lead by doing. Sometimes they do the hard work to pay down technical debt that’s been accumulating for years. Sometimes they do the hard work of seeing how the features are evolving into an eventual framework, or two or three. And, when you have 200 or 300 or 400 people on a program, all over the world, working in 2-week iterations, I still think you need people who are exploring just ahead of feature teams, so that the feature teams are free to develop features. I hope some of you agree with me.

There is a difference between agile on small projects of 1-3 teams and agile of 4-8 teams, and agile of 9 teams and more. Part of it is the communication paths. See my post of Why Team Size Matters for the issue of communication paths. Part of it is that coordinating the design and architecture among very large programs is a non-trivial task. It’s partly managerial in nature. It’s partly technical in nature. It’s not a problem that can be solved with hierarchy and maintain agility. And it is a difficult problem to solve. If you have solved it in your organization, I would love to hear from you.