Fixed Price: Is it Agile?
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 product 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 product development. Product 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 upfront 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.
Above graphic used with kind permission of Jeff Patton www.comakewith.us.
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 upfront 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 ability to be Agile, you are doing something far more dangerous -- you are reducing your options.
To learn more about planning, check out The Five Levels of Agile Planning presentation.
Comments
As much as we don't like it,
As much as we don't like it, organizations do want to know upfront how much a project is going to cost them. This is the basis for decisions on whether the organization should invest in the project or not. To expect organizations to change how they evaluate investments, just because we are using an agile method or agile estimating process, is really not taking into account how decisions are really made in organizations.
The decision makers who usually expect "Fixed Price" are not always those involved directly with the agile project team or those who are directly impacted by or benefit from the outcome of the project. The pressure for fixed pricing (or for bringing projects on pre-defined time and budget estimates) really comes from way above in the organization hierarchy.
Traditional organizations (and most organizations for that matter) do not, or at least they are not supposed to, undertake major investments without a reasonable level of certainty upfront. They like to know upfront how much the investment will cost and what the return on the investment is expected to be. Estimates become the starting point of any conversation about funding of future investments. Time and cost estimates are the only currency these decision makers deal in, the further removed from the project they are. And, at every level of the organizations, people are measured based on how well they perform against these estimates.
Most of the senior business decision makers at the top of the management hierarchy in traditional/non-software development organizations don't really care or want to know how the project team plans to deliver on the project outcomes. They usually don’t even know the details of the project. They usually leave that responsibility to the Project Sponsor, who is usually the person who makes the case for the request for funding the project. These decision makers, who usually sit on various governance boards along the organization’s investment funding decision hierarchy, just want to make sure the investment is worth it for the organization at large. They want certainty because they are used to getting it when evaluating other investment options. And we can’t blame them, given all the other decisions competing for their attention their accountability for making sound investment decisions.
Unless we are talking about purely software development companies, who understand the nature of product development, I don't expect this situation to change any time soon in traditional/non-software development companies.
Not accepting this fact, in my view, is one reason that makes agile difficult to implement in (and why it has not been warmly embraced by) large traditional organizations. To me, it is not that the philosophy behind Agile has not been understood by traditional organizations. The way I see it, agile processes must be tailored to take into account the realities (and challenge) of decision making in traditional organizations.
The sooner we come to terms with this reality, the sooner we can begin taking serious steps to adapting agile methods to tackle enterprise level projects.
Samad Aidane
Managing Editor
GuerrillaProjectManagement.com