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...
I don't quite follow how this works, I think I'm missing something. When the Agile team is implementing a feature, do they refer to the requirements doc for guidance on how the feature should work? If they do, then there should be no CRs. If they don't, then the customer can be expected to balk when asked to pay for the CR to be carried out.
Also, my feeling is that a large part of the value and benefit of Agile is that in not producing a fully kitted-out requirements document in the first place, you avoid a lot of unnecessary and wasteful expense: such a requirements document is difficult and time-consuming to produce, and estimates based upon it are fairly inaccurate anyway and hence need to bulked up by a large risk multiplier.
Of course i always prefer real agile projects where the process is also appiled to the requirements management.
However, the original requirements document is part of the procurement process of big organizations and needs to be made anyway. It is the base for the project contract.
But during the sprint planning, the stories are discussed again and only then, the real contents of the sprint are defined. They will be different from the original requirements, especially for late sprints. Therefore the parallel "thread" with the "beancounter" is needed. This does not disturb the development because it is sidelined with separate people taking care of it.
This way, you can satisfy the procurement department because they get what they ordered (plus a bunch of CRs as they are used to) and at the same time the sprint planning is not limited to the original requirements...