Do You Need Titled Architects for Your Agile Programs?

[article]
Summary:

Johanna Rothman received a variety of responses to her recent writing on agile architecture. In this article, she attempts to clarify her case for having an architect on some—but not all—agile programs, depending on a number of factors.

I’ve been blogging about agile architecture, and the responses have been fascinating. Some people are totally against the idea of an agile architect, regardless of the size of the program. Others are ready to give me the benefit of the doubt. In this column, let me clarify the case for (or against) the job-titled agile architect.

As with all interesting questions, the only correct answer is “It depends.” It depends on the size of your program, how architecturally complex the product is, the desired speed of release, how long you have been practicing agile, how much technical debt you have, and how distributed your program is.

Programs Are Different from Projects
A project is a unique and novel effort, characterized by risk. It has a beginning and an end. A program is the organizational coordination of several projects’ results into one deliverable, which has value to the organization. So, while each project has its own risk, the program has the strategic risk for the organization.

Programs may continue for several releases of the product or system. Programs are large, and one thing we know about software is that it does not linearly scale. What works for a small project or for one team does not work for eight, twenty-five, or forty-two teams.

Program Size Is a Factor
One factor in considering whether you need a formal architecture role on your program is the program size. How many total people do you have? The reason to consider the total number of people is because of the communication paths in the teams and among the teams.

Assume you have seven-person teams. We know that the communication paths inside a team are (N*N-N)/2 which works out to twenty-one paths for a seven-person team. If you have two or three teams, the teams may still be able to build informal communication paths among themselves to share architectural knowledge. 

Once you have four to seven teams, you are at the hairy edge of what teams can do informally. I have seen several programs work successfully without a formal architect role and one spectacular failure. I have seen two programs work successfully with three architects participating on feature teams and as architects on the programs. Clearly, your mileage will vary.

On programs with eight teams or more, I strongly suggest you have an architect team, who participate both as part of the feature teams and as architects. Agile architects write code, test, and look ahead just a little to smooth the way for the feature teams.

How Complex Is Your Product
Organizations normally use programs to create “complex” products in the sense that the technical team has more or less opportunity to refactor as they develop the product. (Product complexity might not be the right term here, but it’s the best term I have right now. Let me know what term you would use in the comments below.) Within that notion, there are more-complex and less-complex products. That complexity allows you to make architectural decisions more often or less often.

Figure 1 shows one way you might think about product complexity and product type.

Figure 1: Product complexity and opportunity to rearchitect and refactor

User Comments

1 comment
bob corrick's picture
bob corrick

One way to focus on architecture is to consider system requirements, as suggested by Julian Browne http://www.julianbrowne.com/article/viewer/systemic-requirements and of course Tom Gilb http://www.gilb.com/tiki-download_file.php?fileId=47

We need to be aware that design choices can end up being an "architecture by default". When we are aware of this, and can act to make a difference, we contribute to better systems - whatever our job titles.

September 6, 2011 - 12:07pm

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!