Agile Contract Models

Using the agile software development process in conjunction with client contracting is challenging due to the emergent nature of the detailed plan and product. Traditional contracts, used to bid or scope an agile development effort can subvert project execution and causes both parties miss the potential benefits of agile development since a full understanding of the client needs is assumed in a contract. 

Fortunately others have come before us who have tried different contracting models.

Some of the typical models of contracts are listed in the following table:

Contract Name	Description
Capped T&M	Use time and material  but cap the cost based on effort or scope.  Sets up a conflict with the customer as this model assumes all scope is known.
Fixed Bid	Price and scope is fixed.  Quality is the only variable – which is not good.  Assumes all scope is known.
Target Cost	Mutually target a cost, if final product cost is less, split the savings.  If final product cost exceeds target, share the extra cost.  Can be a tough sell and setting the target cost is a challenge.
Target ROI	Estimate work for effort and value to determine each piece’s ROI.  When the summation of effort and value for a sprint reaches a certain ROI, enter a ‘work wrap up’ sprint and end the project.
Contract by story point	Work is broken down into small stories and estimated by story points.  Fixed bid work is based on number of story points.  As the project progresses, scope is fixed but stories can be exchanged as long as they are not currently in a sprint.
Money for Nothing Changes For Free	This is a combination of target ROI and contract by story point.  The work is targeted toward a certain ROI and stories of the same size can be exchanged as long as they haven’t started yet.
Contract by Sprint	Each sprint is a mini project.  Could be contract by several sprints. Client can cancel after any given sprint.

* A good blog on agile contracts from another scrum.org coach:

http://scrumology.com/an-overview-of-agile-contracts/

The best contracts for agile use a variable scope and shared risk approach.  Of those, Target ROI, Contract by Story Point, and Money for Nothing Changes for Free are the most popular and effective.  Here’s a description of each.

Target ROI

Target ROI works when customers want fixed price estimates for the entire contract up front but the work has not been fully .  The Agile contract allows termination of the contract when the value of features drops below a certain ROI criteria.  It can be effective for delivering high value to the customer for a reasonable price and building trust.  The ROI value can be based on revenue or using other techniques. 

Contract by Story Point

Contract by story point works can well when the client wants a fixed bid based on work that isn’t very solidly defined or is emergent.  The estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint.  This technique works well when the client doesn’t know what they want or there is a large risk of discovery.  It can be risky though for both parties considering team velocity comes into play when billing the project.  Also story points can become a sticking point in client-provider relationships when the provider re-estimates detailed stories.

Money for nothing, changes for free

“Money for nothing, changes for free” can be though of as combination of Target ROI, Contract by Story Points, and Target Cost.  The following elements of each are combined:

·      Contract by Story Points - the estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint. 

·      Target ROI - Delivery is based on a target ROI, and project payment is based on a mutual price

·      Target Cost - Mutually determine target a cost for a certain ROI, if the ROI is reached and the final product cost is less, split the savings.  If ROI is reached and the final product cost exceeds target, share the extra cost. 

This is a complicated contract but the risk is shared, the delivered product is malleable, and success is based on what really matters – value. If the business value is not realized on a particular cost target, then there should be a fall-back to time & material.

 “Money for nothing, changes for free” contract turns the advantages of the agile development processes into a competitive advantage by prioritizing and delivering business value incrementally and allowing change when something is learned.

SAFe and Agile

Incase you don't know SAFe stands for Scaled Agile Framework.  It's a framework for scaling agile through an organization and it's controversial - why later.  Think of 20 teams working on multiple backlogs and multiple year projects.  The funding - the planning - the organization - the roles all of these things are where SAFe is meant to play.

I attended a 4 day course for SAFe certified consultants a while back and wanted to share my thoughts.  First of all, SAFe could very well be a RUP-like tool with the same negative results.  The 4 day training gives the student the ability (if passing a test) to roll out SAFe at an organization as a consultant including training and process consulting – hogwash.  

Some students could implement SAFe in a large organization. Despite experience in agile at the enterprise level, I personally feel uncomfortable in such a role without seeing SAFe in the works.  Mistakes could lead to organizational level disaster. On the other hand, having appropriate guidance on enterprise adoption can be very helpful in the right hands.

SAFe does talk about emergence, self organization, and a lot of the leadership dynamics, but in the context of company maximized profit and a push-top down mentality. Decisions made at higher organizational levels can be painful in the wrong hands when the decisions are not based on a thorough understanding of emergence.

It also breaks a lot of the ground rules of scrum through HIP sprints, multiple levels of product owner, multiple levels of scrum masters, and potentially long planning horizons.

The big questions I have about the process revolve around it’s overall focus on large, large projects.  Why do you need 50 teams on a project?  Why not make a lot of small projects?  Why plan out for a couple of years?  Can you decouple work so that dependencies among teams isn’t so much of an issue?  How do you tailor SAFe? 

These are all questions that weren’t answered in the class and, frankly, I don’t know the answers either.

Ultimately SAFe has merit as a starting point, but should be applied with caution – it can easily be implemented as a push style of management without having an understanding of agile itself.  Remember values over mechanics.  Agile in general could get an ugly name through SAFe or any other process being implemented through certified neophytes.