As Scrum and Agile practices become mainstream and fundamentally change the way companies work internally, it is only natural that the way companies work with each other will also change. Unfortunately, many procurement departments are ill equipped to contract in a manner friendly to incremental development. So how can Agile companies operate under a change control board? Fortunately there are a few solutions.
Upon completion you will:
- Know the philosophical underpinnings of an Agile contract
- Discover how Agile contracts anticipate change
- Learn how a Product backlog fixed in scope and can change priorities
- Know how to write an Agile contract
- Qualify for Scrum Alliance SEUs and PMI PDUs. See FAQ for details
ScrumLab PrimePrime members enjoy unrestricted access to all our webinars and advanced Scrum topics. It includes clear definitions and insightful videos from the inventor of Scrum on the most advanced topics in the agile community.
Agile Contracts Overview:
Traditional contracts rely on three features: a fixed scope that is developed sequentially, fixed deadlines that cannot easily be moved, and variable staffing resources. If the contract is fixed in price, the service provider quotes a price for the entire project (excluding customer changes) and takes on all of the risk for delivering on time and on budget. If the contract is based on the time and materials, the service provider promises to complete the work while billing the customer a set rate per hour of time. In this case, the customer takes on all of the risk associated with delays and cost overruns. These contract conditions have a direct impact on the Team and can negatively affect the entire development process.
Further complicating the traditional contract, the customer believes the contract phase is the only opportunity they will have to request functionality. As a result, the scope usually includes every conceivable feature without considering whether it delivers Business Value.
View and Download Class Slides
The Problem with Traditional Contracts
Complicating the traditional contract, the customer believes the contract phase is the only opportunity they will have to request functionality. As a result, the scope usually includes every conceivable feature without considering whether it delivers Business Value.
At the outset of negotiations, the customer and service provider decide on the exhaustive set of requirements that must be met in order for the project to be considered complete. The contract is also drafted under the assumption that the software will be developed sequentially. In this development model the vision, specifications, architecture, development and testing are each completed in a defined process. As a result, any change request causes a ripple effect all the way back to the architecture, which requires lots of re-work and creates waste.
As the product is developed and the customer gets a clearer idea of how it will be used, they request a change. The development Team is interrupted by these new ideas, which slows them down and extends the life of the project. Costs go up and the delivery date slips. These scope changes drive 75% of cost overruns. In response, companies have set-up internal Change Control Boards that limit changes in the scope (and the corresponding costs.) Unfortunately, a side effect to the boards is that needed and delightful features do not get included in the final product.
Money for Nothing and Change for Free
An Agile contract is based on: customer collaboration, responsiveness to change, and emphasizing collaboration over contract negotiations. These principles untether the development process from a fixed plan.
Scrum relies on iterative development in which individual functionality is designed, built, tested, and delivered in one Sprint; building value from one Sprint to the next. This is fundamentally different than a defined process and is the basic concept that allows Scrum Teams to deal with change as it occurs.
Instead of drafting a plan that includes the entire scope of the project from soup to nuts, the Scrum process starts with a Product Backlog; basically a list of all features that could be included in the final product. Because 80% of a projects value is in only about 20% of the features, the Scrum Team starts working on the highest value features first. All features are complete by the end of each Sprint: designed, written, and tested. The following Sprint, the next most valuable features are worked on and brought to completion. These features build upon each other until enough value has been accumulated to release the first version of the product. The Backlog is built in close consultation with the customer so both the provider and customer have the same expectations.
Change for Free: Because not all features are created equal, if a customer decides they wants to change priorities or add new features they can do so. The Product Owner would simply insert the requested feature into the Product Backlog, where appropriate. This doesn’t slow the development process down or interrupt the Team because the Team is focused on completing the current Sprint Backlog, which is fixed during the Sprint. The customer is not charged for the change as long as they indicate which lower priority feature of equivalent point value should be pushed out. As the slide above clearly shows, 65% of features are never used so this is usually an easy choice. Change is free because the scope of work remains the same.
Money for Nothing: Because Scrum delivers projects in completed slices of functionality, once the provider has delivered enough of the high-priority functionality for the customer to be happy with the product, the development process can stop. Any features that were in the original scope of the contract but not developed (because the customer realized that those features weren’t necessary) are left uncompleted. The money left over is split between the customer and the provider i.e. Money for nothing. The contract should specify what percentage of the remaining money should go to each party. This can be a 50-50 split but depending on the relationship and level of trust between the provider and customer the split can be as much as 75-25 either way.
Contract Particulars: Customer participation is absolutely necessary for the Scrum to work. Because of this, the provider needs to make sure the contract includes very explicit requirements for customer participation. Below are some suggestions for both the provider and customer.
Customer participation should include:
- Prioritizing features by business value in conjunction with the Product Owner and the Team
- Agreeing to estimates for all work. Scrum measures output in Points not hours. The customer representative needs to understand this process and be present during estimation.
- Partaking in Sprint planning meetings by discussing the selected features with the Team. The customer representative needs to be present to provide clarification of features to the team if necessary.
- Help write the conditions of satisfaction for each feature, so the team and client have a shared definition of when a feature is Done.
- Be a part of each Sprint Review meeting, and provide timely feedback both for both work-in-progress and completed work.
Not all customers feel comfortable participating so heavily in the development process. The more a customer is willing to participate, the better the product will be. However, if the Product Owner is able to elicit feedback regularly from the Customer and play an active role with the Team, a less involved customer may not be an slow things down. The point is to ensure that the product vision is well represented in the development process. This is why a high-performing Product Owner is extremely valuable and the role should never be under resourced. Paying for a quality Product Owner will pay you back.
Provider agrees to:
- Commit to delivering the portion of the project scope that the customer ultimately desires. (This is based on the idea that 80% of the value is delivered by 20% of the features.)
- The Money for Nothing clause can be enacted only if the customer maintains participation with the Team Scrum during the project and the provider delivers completed features at the end of each Sprint that satisfy the customer.
- In the event that both parties cannot mutually agree on work estimates or the customer does not maintain participation in with the Scrum Team, the contract shall revert to a traditional time and materials billing contract.