Agile Architecture

Agile approaches work for projects. Have you considered how to make agile work for a program? A program is composed of several projects, typically across the organization. Each of the sub-projects delivers value. But the real value to the organization is when all of the projects deliver results in a synchronized fashion.

Since agile approaches are so good at managing risk and complexity for smaller projects, program manager Ben thought he might be able to use agile for a large program–and he was concerned. “I can see how to use agile for my project when I have one or two teams. But I don’t have a one- or two-team project. I have four software teams, a firmware team, a hardware team, marketing and support to deal with. I have a program. How the heck can I make agile work for my program?”

As Ben organized and managed the program, he addressed the issues of architecture, product backlog, the program team and the iterations.

Iterate on the Architecture

In a traditionally planned program, the architects get together and spend significant time developing architecture before starting any development. In an agile program, the architects are an integral part of the teams, locally guiding the architecture and using that knowledge to make global decisions about the program’s architecture as the program proceeds.

In Ben’s case, the market dictated the hardware architecture. The hardware dictated the firmware architecture. But the software architecture and the lower level firmware design were wide open. Ben talked with his teams and with the overall architect, Roni. “I don’t see how we can define the overall architecture and be correct at the beginning. We need to iterate on the architecture. How will you do that?”

Roni and the teams decided to have an overall architecture team that cut across the software teams. They started with five teams: four software-only teams and a firmware team. They only had access to two architects aside from Roni. Without enough architects for each team, they decided that the architects would move to the teams that appeared to have the most need for an architect (based on which stories teams took during an iteration). They would see how this proceeded for a few iterations. If moving the architects around didn’t work, they would combine the software and firmware teams into three teams instead of five teams total. That way, each team would have a permanent architect.

Some Guidelines Helped the Architecture

Roni and the architects requested that the teams follow these guidelines:

  • Never spend more than 15 minutes discussing the architecture, or its pros and cons. Once you spend 15 minutes, it’s time for hands on the keyboard. Use a short spike to develop a prototype or explore something about this architecture so you can speak from experience, not theory.
  • Everyone pair as often as possible so people could see evolving patterns as they proceeded.
  • Developers use test-driven development (TDD) or behavior-driven development (BDD) approaches, to see the design and architecture possibilities as early as possible.
  • If you are stuck for 15 minutes, ask for help.

The architecture team knew they could not do all the architecture work themselves in advance or even just in time for the teams, so they requested the teams help. The 15-minute timebox helped people see how their ideas might work. When people pair, the navigator is able to see the big picture of the code, and possibly see design patterns. Test-driven or behavior-driven testing is more about design than it is about testing.

Roni thought these guidelines were enough so that the teams wouldn’t go too far away from a coherent architecture for the product in a given iteration. In addition, she planned to advocate for architecture and design reviews as part of the work in several future iterations. Even though the teams agreed to each of the architecture guidelines, they had plenty to discuss about what it meant use these guidelines. They did not adopt these practices without pain.

Define a Program-Wide Backlog

While the architects were discussing how to do architecture, Ben approached Margaret, the product owner. She was also the Marketing VP, and Ben was concerned that she would not have the time to spend with any one team, much less all of them. Ben and Margaret discussed the problem, and Margaret agreed to assign two product managers to the program. She designated one of them, Sally, as the person who could make overall product owner decisions. Additionally, Ben requested business analysts for each team so they would have someone to discuss the requirements with.

Margaret helped define the overall product backlog, and worked with Ben on ranking the backlog between iterations. Sally was present at those meetings, but Margaret made the decisions. Margaret had the initial responsibility for grooming the entire backlog.

Define a Program Team

A program team is the risk-management body for the program. It has the people who can identify and lead the management of cross-program risks, make cross-program decisions and make sure the program meets its release criteria–all in service of the program. The program team looks across the entire organization. In the same way as a project team is wholly responsible for their commitments achieving “done” for an iteration, the program team is responsible for the product achieving “done” for the release. The reason you need a program team is because the problem is too big for one person (a single project manager) to see all the potential risk areas and make decisions.

Ben’s program had four software teams, so he had four software project managers, the firmware project manager, hardware project manager, Margaret for marketing, Roni for architecture, the hardware project manager and the technical support manager. The people on the program team are responsible to report from the program team back to their work teams. Ben’s team had a total of 11 people. Ben was concerned that they would not be able to make any decisions because of the team size.

In the first iteration, the project teams and the program team conducted standups every day. Sally stood in for Margaret when Margaret had other commitments. The program team made it through the first four iterations with daily standups and weekly decision-making and risk assessment meetings.

Refactoring the Program Team

By the fifth iteration, it was clear that Margaret was not participating on the program team–Sally was filling in for her, grooming the overall product backlog and making the program-wide decisions. And, with 10 people on the program team, some of the software project managers decided they didn’t all need to be there.

The software project managers met and elected one person to be their advocate to the program team. That meant that the other project managers did not have to be at the program team standups or meetings. Ben’s program team was down to six people: one software project manager, firmware project manager, hardware project manager, Sally for marketing, Roni for architecture and the technical support manager.

One of the problems the program team encountered was that the hardware and firmware teams wanted different length iterations than the software teams.

Synchronize the Timeboxes

The software teams chose two-week iterations. The hardware and firmware teams decided on three-week iterations. This became a problem for managing the product backlog: If you had a story with hardware, firmware, and software, it was difficult to synchronize the work. The software project manager raised this as an obstacle in the daily standup with two examples, and the program team addressed it that week in their problem-solving meeting. They decided to move to two-week timeboxes across the organization.

Summary of Current State

Ben’s program is about halfway through its expected 18-month duration. He is pleased because he can see progress for all the teams. He knows that when the hardware team is ready to deliver pilot hardware, everyone will see how real the team’s progress is. Not only are the project teams conducting retrospectives, Ben’s program team is also conducting retrospectives. This helps the teams see what they need to adapt to keep the program working for everyone.

Programs are more difficult than projects. If you are a program manager, you might make different decisions than Ben did. For example, when I asked him why he didn’t advocate for same-length timeboxes from the beginning, he grinned and said, “If I dictated that everyone had to have two-week timeboxes, I would have had a revolution. This way, everyone felt the pain, and it only cost us part of one timebox.”

Any project or program of significant size will experience architecture problems. People will roll off and onto the project for any number of reasons. It’s key to build in inspect-and-adapt feedback loops into the program to address these knowable risks, and the ones you can’t anticipate. For example, in this column, I didn’t address the issues and risks of iteration planning or estimation across several teams, end-of-iteration demonstrations or reviews and cross-program retrospectives. I’ll address them in future columns.

If you have a project larger than a couple of teams, consider program management. You can use agile approaches, and you will have to adapt them to your environment.


I thank Gil Broza, George Dinwiddie, Esther Derby, and Don Gray for their comments.

© 2010 Johanna Rothman. This article originally appeared on

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>