Architecture and Programs: Incremental Progress Not Big Bang

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.

2 Replies to “Architecture and Programs: Incremental Progress Not Big Bang”

  1. The problem is that the roadmap is organized in years, not in quarters or months.
    Roadmaps are a guide, not a backlog. With that in mind, incremental delivery, even if the customer doesn’t see an increment review as delivery, is the result of transforming your roadmap to product through the backlog.

    I see the problem as tranferring the implicit priority found in a roadmap into a prioritized backlog. Your suggestion of organizing the roadmap by smaller timescales helps to make more explicit the priority of the roadmap items, but it does not complete the activity.

    I believe the customer and product team would be better served by leaving the roadmap in longer increments (no less than quarters) such that it is not confused as a product backlog. Take the most nearterm portion of the roadmap and turn it into a product and, subsiquently, iteration backlog. Execute against this while maintaining good communication with your Product Owner.

    Over time you will find that your tactical product backlog will enable the roadmap organically. The roadmap by remaining focused on longer cycles can more easily fluctuate with the changes discovered through product delivery and environmental influences while not being bogged down by the psychological committment of being directly associated with Product Backlog items.

  2. Basically, those who manage the programs know how the system rolls. They must know what a “walking skeleton” is to their customers.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.