I’ve been working on agile program management and a colleague emailed me about his program. He’s having trouble seeing how to do agile on a large program. The customer wants to see a working system before they add the features, so the customer thinks the program need to provide “all” the architecture, with some hard-coded pieces to show the working system and then add features.
In a way, this is incremental progress. They are trying to get a full underlying system to show the customer. To me, it’s still big-bang architecture because they won’t have tested the architecture with any real features. Instead, I wonder if the customer would be satisfied with a “walking skeleton”. That’s where you implement a few features and just enough of the architecture to show real progress. Or, I wonder if the customer would be satisfied with a prototype of some pieces of the system along with a walking skeleton of other pieces of the system.
Part of the problem is that the product managers have had time to think about this and they have years of product roadmap. The problem is that the roadmap is organized in years, not in quarters or months.
One of the challenges of agile program management is that everyone has to think in smaller chunks of work, that incremental thinking. People who’ve worked on large programs before “know” they have to get everything down on paper so they have a shot of getting any of it done. They know how long it takes for previous programs to deliver (a long time), so they want to the program team to know everything they need to do so the program releases with almost everything in it.
The problem is that the more big-bang you are, the less likely you will get everything you want. That’s because there’s a ton of work in progress, and that it’s hard to be omniscient about how your architecture will work in practice. If you can work in short iterations, say 2 weeks, and do a demo at the end of the that time, you have a much better of moving to a more incremental approach.
What I suggested is to have a quarterly roadmap of features, and rank the features for the iterations. Have the entire program work in two-week timeboxes, getting to done at the end of a timebox. Make sure you can do a demo at the end of each timebox. Keep inspecting and adapting, never lengthening the timeboxes, but making sure that if you have dependencies and need to implement a few components, that you know in advance and implement as little as possible by component. If you do choose to hard-code pieces, make sure you plan to refactor. Hold architecture reviews as part of your iterations.
This is not easy to do. It’s easy to say and quite difficult to do. But it’s worth trying.
