Have you ever waited weeks for one piece of functionality so you could release a large project? Have you been in the situation where the software is waiting for the hardware? Or where the database admin held up the entire release because his work wasn’t coordinated with the feature-based teams? That’s because you were working on a program, not a project.
Program management is the art of coordinating several sub-projects to a common objective. Until the parts are assembled into the whole, the parts–while useful–have no business value to the organization. The whole program delivers business value to the organization.
Agile approaches help manage risk for projects. Is it even possible to scale agile approaches to programs? Yes, and it’s not trivial. There are four areas to consider when scaling agile to programs: backlog management, product architecture, managing risks across the program and explaining program state.
Manage the Backlogs
If you’re lucky, you have a product where the subprojects or subsystems are relatively independent. For example, consider a cell phone system. You can imagine that the call handling subsystem is independent from the voicemail, which is independent from the camera and so on. The applications on a cell phone are just that–applications. They have some defined interfaces, but the project teams can work independently to deliver the applications.
In that case, you can manage the backlog for each application separately. You do need architects and an overall product owner to look for and manage the backlog interactions. It’s easier to develop and manage a program backlog if you have a platform and applications as your product. Each item on the program backlog becomes a set of features for an application team or teams.
But what if you don’t have a platform and applications? What if you have an interconnected system with layers that interact up, down and sideways? An example might be an insurance application, where the engine for calculating insurance is in the middle with state-specific interfaces on top and database services on the bottom. Here, the work for the database and the engine are intimately connected with the state-based interfaces.
You’ll have to manage the backlog for the components that are common to the system and manage the backlog for the features. You’ll have to decide how much component development to do in advance and how much to do just in time for a feature. Those decisions are not easy, and can change your backlog–and potentially change your product architecture.
For example, you might decide to choose a state with the highest business value and develop the backlog for its features. As you develop the features for that state, you can develop the components, knowing that you have another 49 states to develop features for. Once you have one state complete, you can work on the other states as you please: off one backlog, or separate backlogs for each state so the teams can work more in parallel.
All this backlog management requires a program-level product owner, as well as product owners for feature teams. Can teams share a product owner? Maybe, if the features are highly related so that the product owner (and maybe some business analysts) can keep discussing what they mean. But don’t expect one product owner to be able to manage the backlogs for all the feature teams. Backlog management means you keep working by business value. And, at some point, the features demand an architecture to increase business value.
Keep Thinking About Architecture
There is nothing in agile that says you can’t look ahead to see and anticipate the system’s architecture. However, you want to be quite wary of developing the architecture before you have any experience developing the features.
I realize that many people balk at the idea of delaying architecture. I used to think we needed some architecture in advance–a sprint 0, if nothing else. Then I worked with one program where they had developed an architecture before any features.
The architects insisted on a sprint 0 where they fleshed out the architecture but implemented no features. They proceeded merrily into sprint 1, when they realized they had a fatal flaw in the architecture. If they had tried implementing features first to see what they needed for an architecture, they would not have wasted one sprint on architecture.
Wasting one sprint was not a terrible thing. More often, I see large programs where the architects spend a few months developing the architecture. On one notable program, they spent the first three months developing the architecture. They finally started on features, progressed about halfway through their anticipated schedule and then realized the architecture would not support the system’s need for performance and reliability.
The problem is that it’s difficult to see what’s architecturally risky before you start the program. Sure, some features may be tricky to implement. But until the system starts to integrate, it’s difficult to know what is truly risky. Implementing by feature with architectural checkpoints would have helped that program instead of taking the time to develop the entire architecture first.
Here’s the problem with architecture before features: You increase the feedback time to test your architecture rather than decrease it. You can’t ignore architecture or wait for it to “just” emerge. You can and should look ahead so you don’t cut off potential architectures. You may even want to build architectural reviews into your iterations. But you want to as little architecture anticipation and design until you need to.
That might mean that after you implement several features–at least three, maybe seven–that you create component teams along with feature teams so that the component teams can create the underlying services of the product for the feature teams. (Maybe. Depending on your product, you may not need to have component teams.)
Manage Risks Across the Program
Because no one kind of agile program management fits all programs, you will encounter risks where you never expected to. Maybe the marketing people can’t launch their campaign when they thought they could. Maybe the hardware is running into problems. Managing an agile program requires that the program team (the project managers for the program) will identify and manage risks within their teams and across teams.
To manage risks, the program team needs to meet often enough to synchronize where their teams are going and the problems those teams have encountered. You might decide to have a daily standup, assuming there are nine or fewer of you. Once you get to 10 people, a standup can be confusing because not everyone has enough context.
You might have to group all the software teams into a software program and the hardware teams into a hardware program. Or you might have the security program with the software and hardware that makes the security features. You might release a sub-program with the marketing, training and deployment teams working together to make sure that release happens smoothly when it is supposed to happen.
However, you need to organize the project teams and make sure they organize themselves so they can answer these questions:
- What problems have you solved that affect the entire program since the last time we met?
- What problems are you working on now?
- What obstacles do you have?
These questions look like standup questions, except they are focused around problems that affect the entire program–not reporting on status.
Explain Program State
If you’re running a project, the team can demo its progress at the end of each iteration. The team can track velocity with a burn-up chart. But when you run an agile program of 25 teams, does it make sense for a program demo, especially in the early days of the program? Not always. So what do you use instead?
One possibility is several burn-up charts showing how the teams are doing against their backlogs. Another possibility is an image such as a fundraising thermometer (until you can start to show demos). A third possibility is storyboarding, where you walk people through the completed features even if you don’t demo them.
The issue with explaining the program state is that you’ll have imprecise status reporting earlier in the program because so little of the program is integrated with a product. Once you have a product, it’s fine to demo.
That’s Not All Folks
There are more issues in an agile program, especially because many programs have distributed teams. But once you’ve thought about and have an approach to managing the program and the sub-projects’ backlogs, a way to keep architecture in mind and review it, a way to manage risks and explain the program state, it’s possible to apply agile to programs.
© 2010 Johanna Rothman. This article originally appeared on Gantthead.com
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.