Agile Programs: Possible or a Pipe Dream?

In This Issue:

Agile Programs: Possible or a Pipe Dream?

Yes, agile programs are possible. If fact, some of you are reading this email and saying, “Of course they are possible JR, we're doing them. We've even spoken about it with you!” We have. I've noticed that everyone appears to have a unique solution that fits their context. That's the reason you haven't seen a book from me yet. That's also why I may not have returned *your* email yet.

You know me–I'm not particularly prescriptive, except about not being prescriptive and using your brain. Here are the guidelines I have found are useful for agile programs so far:

1. Do not expect the architecture to just appear out of thin air. While I do not subscribe to Big Design Up Front, you will need to nurture the design or architecture along for a large complex program. I advocate thinking about design in each iteration, and possibly having a kanban queue of architectural features so the architecture is done just in time, using flow for the features. You still implement the features by slice. You implement as little of the components (by architecture) as possible. You prototype to answer questions. You implement a walking skeleton to answer questions. But you use the architecture to guide your development, and keep the architects as working software developers, not as religious priests.
2. Synchronize all the iterations all over the world for all the feature teams. Let me unpack that sentence for you. Programs need feature teams, not functional or component teams. So make sure you have feature teams, teams who can be responsible for finishing features. And, assuming they are all over the world, because that's what I see more often than not, make sure they synchronize their iterations. That means if one team has a two-week iteration, all teams have two-week iterations. No teams have three-week iterations. If some teams have trouble with shorter iterations, it's the role of the program manager to clear the impediments for the teams with the longer iterations to move to the shorter iterations. Especially in a program, you need feedback more often, not less. You want to see feedback more often to expose the program's potential risks.
3. Determine a way to show the program's status that works for you. I happen to like program burnup charts. I love demos that show the product working, but it's hard to put a demo on the wall. A thermometer showing program status might be a good first step. Maybe a storyboard will work for you. Whatever you do, think about who the status is for, and then develop something that works for that audience. Remember, you have the entire program staff, senior management, and other people I don't know about who need to see the program status. As a program manager, your job is to think about all those people and consider what they need. You might need to develop different kinds of status for different kinds of people.
4. Risk happens on agile programs, too. And the larger the program, the more risk there will be, just because of the program's size. So, if you're managing a program, ask for risks, from the feature teams, from the people helping you manage the program, from anyone. And then, manage those risks. Don't wait for the risks to occur; proactively manage them.

These are just the guidelines I've uncovered so far. Stay tuned for more.