If I am remodeling a house, I need to know how much to budget. I also need to know when the drywall contractor will be complete so I can schedule the painter. Similarly, with software development, I need to budget and I need to know when features will be complete so that stakeholders can prepare.
So, it’s natural to want to know up front what is coming, how much will it cost, and when will it get here. Where we often run into problems is with the degree of detail.
As anyone who’s been down the path can attest, it’s difficult to know everything up front when you’re remodeling a house. It is exponentially more difficult when you’re doing software development. Software development is, by its very nature, unique every time. If it weren’t unique we wouldn’t need to build it, we could just buy it.
So does this mean we can’t set any expectations up front? No, but we need to set expectations at the appropriate level of detail, deferring commitment on some details until the maximum amount of information is available.
Successful agile organizations’ teams plan continuously and at different levels of detail.
It is in our roadmap where we see the healthy tension between setting expectations up front and deferring commitment. Rolling wave planning creates a roadmap that communicates what high-level features will be delivered to the market and when. The level of detail is also key. We find the best roadmaps fit on one slide. This is effective because it encourages two healthy habits. Firstly, communication is enhanced by having a simple representation of the future. Secondly, we can’t put a lot of detail on one slide, and this encourages us to defer commitment.
But what about those who are in a situation where your customer/business/boss says they want it all. Again, level of detail is key. Usually when stakeholders say they want it all, they’re not talking about minutiae, they are talking about their minimum viable product. When differentiating between minimum viable product and the nice-to-haves, I find Jeff Patton’s story mapping technique immensely useful.
Jeff explains it best:
When it comes time to prioritize stories, I don't prioritize the backbone. It just "is." I do prioritize the ribs—the stories hanging down from the backbone. Place them high to indicate they're absolutely necessary, lower to indicate they're less necessary. When you do this, you'll find that all the stories placed high on the story map describe the smallest possible system you could build that would give you end to end functionality. This is what Alistair Cockburn refers to as the "walking skeleton." I always try to build this first.
Successful agile organizations know that the most important learning experience occurs not from detailed up-front planning, but during development itself, and so they implement short feedback loops so that they can adjust as they go.
Is a fixed-price, fixed-delivery approach incompatible with such an empirical approach? Perhaps, but only if you are fixing price at the wrong level of detail. Remember though, if you get it wrong you are not taking away your agile ability, you are doing something far more dangerous—you are reducing your options.
To learn more about planning, check out Chalk Talks: Agile Planning for Scrum Teams.