Please login or join to subscribe to this thread
I always like to have a list of Critical Business Outcomes that have to be met. Agile should be the methodology you use to get to the business value but the requirements from the business should be static.
Getting true agile in a contract relationship requires a lot of trust between the parties.
The product and project vision is important. Without a vision you do not know in which direction to navigate.
Assuming software development:
One way of doing it is to have a contract where the buyer pays an amount per week, and the seller promises an amount of hours every week by competent persons listed in the contract. The buyer can terminate the contract at any time with X weeks notice. The buyer then assigns someone from the buyer organisation as product owner, and this product owner decides the priorities. The seller is responsible to work as efficiently as possible.
This allows the buyer to always get the top priority features. It also allows the buyer to terminate the project when the project no longer provides value for money.
Another way to do it is to have the buyer create an initial backlog. The seller estimates the backlog and offers a fixed price for the user stories in the backlog. During execution the buyer cannot change the stories already implemented or currently being implemented. Any story where implementation has not yet begun can be changed by the buyer as long as the buyer does not increase the size, or if the size of a story is increased the buyer has to remove some other stories from the backlog to keep the sum of the backlog effort from growing. The buyer must accept the size estimates done by the seller.
The problem is people - clients, partners, contractors - want their cake and eat it too.
Agile should be only about delivering incremental value through sprints. "Value" can be hard to nail down in terms of what they can expect the product to ultimately look like. Value changes when features and their priority change. Whose to know what the product will look like after twenty sprints?
Ideally, agile project contracts should be about buying a number of sprints, which are costed by sprint duration X sprint team size. Value should assigned to features delivered in a sprint.
Please login or join to reply