Agile Fix Price
von Gaylord, am 6 Juni 2011 - 0 Kommentare
How to make a contract for a project that will be implemented in an agile way?
Working with SCRUM is quite straight forward as long as you are inside the origanization that owns the project. But once you are an external supplier and sell the implementation of a certain piece of software to a customer, the game changes. As a supplier, the perfect scenario would be to be paid by the hour. In this case the customer can supply the product owner and freely define and prioritize requirements for each sprint. The project risk (including the risk of having chosen the wrong supplier) is then completely on the customer side.
This is where the purchase department of large companies kicks in: They want to buy software like a car: "Tell me the features, give me a price, let us lower the price a bit, then you deliver on time, we check the deliverable. If everything is ok, we pay". Since 30 years, software develpment never worked this way, and since almost the same time, people think they just need to try harder next time.
This game is ok for the supplier as long as they put enough buffer into the budget and into the time plan and prevent scope creep during the project. The bid needs to be so high that in the best case the supplier gets something on top of his usual daily rates for taking the risk. In worst case, his margin will go down... In such a project environment you cannot let the customer define prioritization of the Tasks to implement because the project is then not about delivering the best possible solution anymore. It is about fulfilling the contract. The product owner (speaking Scrum again) needs to be inside the suppliers organization. The customer is only a stake holder. The potential of agile is very limited in such an environment.
A solution that appears more suitable for both sides is described in an article by Bernd Österreich (sorry, german) and at InfoQ as "Agile Fix Price". The idea is basically to make a normal offer with normal estimation (broken down to individual requirments), then you make a Special Contract that says:
- We implement all the required functionality (link to Requirments-Spec) for XYZ EUR (or US-$)
- We work with an Agile Method (for example: SCRUM), customer supplies the Product Owner
- In parallel to the agile develpment process, we deploy a bean counter who always checks the implemented functionality against the original requirments. Each deviation is written down in form of a Change Request
- Change Requests can be additional work or less work compared to the original offer. They are estimated in person hours
- Shortly after each planning session, the list of change requests is updated and (very important:) discussed with and approved by the customer
- Once a CR is approved, the customer can decide if the want to extend the budget (and timeline if needed) or if they want to leave out other functionality of comparable effort.
It seems like this method is a good compromise between supplier and customer stakes. The "dark side" of this approach is that the "bean counting" and discussing the detected changes with the customer take a lot of time. This is hard work that nobody wants to do. It is still extremely important to prevent scope creep while keeping as much flexibility as possible in the development process.
Our rules of thumb are that the "beancounter" job takes about 1-1.5 days per 2-weeks sprint. The discussion with the customer is about 45 minutes per sprint.
The beancounter needs that much time because she needs to be able to stand an argument with the customer over each detail in the CR. Otherwise, the customer will be very upset to be confronted with unreflected CRs that turn out to be part of the original requirements during discussion. The needed time depends a lot on the quality of the requirements and on the structure of the calculation documentation.
It is further very important that the customer understands and supports the reasons for this aproach and sees that:
- supplier cannot take the risk of working more if there is no chance of working less than expected
- customer wants to have benefit from agile, so they need to pay the price of additional communication effort with SCRUM
- customer wants to have fix price, so they need to pay for the additional "bean counting" overhead in the project
If this is clear, and if the atmosphere during the meetings is one of a bazaar more than of a cathedral (to quote an old open source article) the agile fix price can be the least annoying of all options to do agile project work...