Contratos ágiles

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.

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 Lista de productos pendientes; 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.

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 Hecho.
• Be a part of each Revisión de Sprint 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.

Download Scrum Inc. Sample Agile RFP