AgileInnovation - Agile, Lean & Kanban Training and Coaching

Transcription

1 Agile and Commercial Contracts an Overview A common concern for those new to agile is how will an iterative approach to delivery work in a commercial, contract oriented business. In traditional project management methods, we use up- front planning methods to build a contract with our stakeholders this could be a legal/commercial contract if our customer is external to the organization but could also be an agreement to another business unit or department within our organization. The contract usually stipulates 3 basic elements: Scope, Cost and Schedule. Our project planning activities are usually focused on establishing the scope of features to be delivered, and estimating the cost of delivering them and how long that delivery will take. Once these aspects are agreed and written into the contract (which may be a requirements document and budget for internal customers) it can be difficult to change these. Hard and fast contracts implicitly hinder our ability to be agile. If the business context changes and the customer wants to alter the scope by dropping, adding or modifying features, we usually impose a penalty or otherwise discourage them. Similarly, if development is running behind the plan, there is often little sympathy from the customer who demands 100% scope on time and at the agreed price. This approach can lead to a lose- lose situation. We end up delivering features that the customer may not value highly anymore, while not delivering features they now realize they really need. And the development team ends up doing overtime while promising to themselves to pad their estimates next time so they won t get caught in the same situation again! Although internal agreements between IT departments and their internal customers have many of the characteristics of legal, commercial contracts, we are only going to explicitly address the latter here. Contracts are a commercial necessity they are not going to disappear anytime soon. However, they are not incompatible with agile development. They usually fall into one of two camps Fixed Price, Fixed Scope (FPFS) or Time and Materials (T&M).

2 Fixed Price, Fixed Scope FPFS contracts are very common in software development they are based on the assumption that unless constrained by a contract, the vendor will try to deliver less than KS3& Fixed&Price/Fixed&Scope& Supplier&Bears&most&Risk& Generally&does&not&give&lowest&Cost& Supplier&builds&in&Con?ngency&for&Risk& Drives&low&bids&&&Expensive&Change&Requests& Generally&does&not&give&lowest&Risk& Selec?on&favors&lowest&(most&desperate)&supplier& Customers&least&likely&to&get&what&they&want& Drives&early&defini?on&of&scope&(protect&Supplier)& Drives& JustKInKCase &Scope&(protect&Customer)& agreed, deliver it later and/or charge more money. FPFS contracts give the customer a reassurance that they will not be ripped- off and that they will get what they specified at the price and time agreed. It this case, the customer bears little apparent risk all risk is assumed by the vendor. FPFS assumes that requirements are well understood and will not change. It also assumes we can accurately estimate how long it will take to deliver, and what it will cost. Estimation is notoriously unreliable in software development however, so most organisations will pad their estimates to compensate for expected over- runs. Of course, Parkinsons law means that the work will expand to fill the time allocated to it so regardless of the amount of padding, traditionally- run projects will generally never come in ahead of schedule or cost targets. However, there is also pressure on the vendor to minimize their bid for the business, so there can be a strong bias to underestimate work. A common way to handle this is a vendor will put in a low estimate for the specified work and rely on change requests from the customer to make money. And the less successful a vendor is and the more desperate for business, the lower their bid might be. So the FPFS contract might end up being less risk free for the customer that initially assumed. FPFS can also drive early scope definition the customer has to specify at the very beginning of the project what features they want this is at a time when they know least about the project. Because subsequent change in scope may be expensive, there can also be pressure to include features that may be important by the time the project is delivered what we call Just In Case requirements. Both these factors can bloat scope beyond what it needs to be, so driving up costs. Time & Materials

3 The second common contract form is Time & Materials, where the vendor is paid for the time and resources they expend on the project, not what value they deliver. In this case, most risk is assumed by the customer they do not know what they will pay for the project until it has been delivered. The longer the project takes, the more revenue the vendor earns. This can lead to a lot of customer overhead in trying to protect themselves from vendor opportunism, and this overhead is not directly adding value. However, the advantage to this approach is that scope can change as the project progresses, so it is much more suited, at first glance, to agile. However, it is problematic in many commercial situations, where the customer needs assurance that they will be delivered certain features in a set time frame and for certain price. Risk Based Contracts So neither of these approaches is an ideal fit for agile development. FPFS burdens the vendor with risk while creating a lose- lose situation for both parties. T&M leaves risk with the Customer and may impose a lot of overhead to avoid abuse by the vendor. Where should the risk lie? A basic principle is that: RISK SHOULD BE BORN BY THE PARTY BEST POSITIONED TO MANAGE IT So in the case where there is uncertainty in what to build, risk should remain with the customer. While the vendor should manage the risk for technical uncertainty where we are not sure how to build it. This indicates that using a FPFS or T&M type contract may depend on the project context. As a result, new forms of contract are emerging which try to find a sweet spot and establish win- win relationships between vendors and their customers wanted to realize the benefits of agile. For example, incentivizing early delivery by paying a premium when a project is delivered before the KS3% Time%&%Materials% Customer%at%Greatest%Risk% Supplier%has%li6le%incen9ve%to%complete%work% Need%to%control%supplier% opportunism % Tradi9onal%T&M%Management%systems% (enforce%compliance%to%plan)% Are%expensive% %create%extra%work% Do%not%add%value% Don t%support%feedback% Don t%tolerate%uncertainty%and%adapta9on% KS3& Graduated(Fixed( Price:&Builds&in& Early&Bonus &and& Late&Penalty &into& the&contract& Fixed(Price(Work( Packages,( Releases,( Itera7ons& Other&Contract&Types& Finish&On&Time:& 100/hour& Finish&Early:& 110/hour& Finish&Late:& 90/hour& Break&project&into&prioriEsed& pieces&and&contract&for&each&one& at&the& last&responsible&moment & Copyright& &2012&AgileInnovaEon&&&InspireQS& 87&

4 planned date, and deducting a percentage when it is delivered late. Another and complementary approach is to treat the project as a series of mini- projects with each feature or iteration packaged up and contracted out separately as the understanding for what exactly is required emerges. Money for Nothing, Changes for Free An interesting combination of these concepts is what s know as the Money for Nothing, Changes for Free contract. In this case an initial, high level estimate of the project scope is carried out, but with a recognition that scope is likely to change. This establishes a target price, schedule and scope for the project. In this respect this contract resembles a FPFS contract. But two clauses differentiate it: Changes for Free: The parties agree that if the customer wants to change scope they may do so with no penalty the vendor won t charge a change fee. However, if the change means a net increase to scope, then a corresponding amount of work must be removed from the project. Its possible to allow such changes because the vendor and supplier are working in an agile manner. Each feature is specified and can be developed independently of others, so removing a feature from scope before much effort has been expended on it should have minimal impact, and should not affect other features. This clause allows us estimate effort/price up front but still allow agility. KS3$ Money for Nothing: This clause allows the customer to terminate the project before it is complete if that is what makes business sense. So the customer, while agreeing to an initial scope for the project, can withdraw if the project no longer makes business sense, or the resources could be used more effectively elsewhere. However, because the vendor may have incurred costs to hire resources, etc. which they will now have to redeploy, the customer must pay 20% (or an agreed figure) of the

5 remaining contract price to the vendor (money for nothing). This sets up a win- win relationship with the customer wanting to facilitate the vendor with a good prioritized list of requirements in the hope that they will have received enough valuable features before the end of the project to cancel and save 80% of the remaining budget. Meanwhile, the vendor wants to deliver the most value to the customer as fast as possible, in the hope that they will cancel the project and the vendor will earn 20% of the remaining contract for doing nothing. KS3$ Principles of Agile Contracts In general, with agile contracts, as with agile projects in general, we want to reduce risk as early and as cheaply KS3$ as possible. This allows us more predictability and better decision making. Applying early risk reduction to contracts may involve a two phase approach to contracts. For example a FPFS or capped T&M contract to tackle the most risky parts of the project and to learn enough to estimate the remainder with acceptable certainty is one approach. So the first few sprints might be dealt with in one contract which is fairly loose and based on exploring the business and/or technical challenges of the project, while a second set of sprints would define deliverables in more detail and with more concrete estimates. Of course, even this approach on its own won t allow for agility and the application of new feedback and learning later in the so mechanisms to provide flexibility are still needed

6 though the likelihood of needing to use them may be reduced. Conclusion Traditional Fixed Price and Scope contract assume we know what we will want delivered at the end of the project and what it will take to deliver both deeply flawed assumptions. But Time and Material contracts don t give any security and the ability to budget and plan which are critical in commercial relationships. Therefore new contract forms have appeared combining elements of these aimed at establishing win- win relationships. Some principles to keep in mind: A contract should commit to How Much, not What o How Much should be related to Value/Outcome (e.g. Story Points, Function Points) o How Much should not be related to costs (e.g. Hours, materials) o The What Emerges from on- going planning, feedback, analysis of emerging reality Align interests of both parties for a Win- Win arrangement o Who wants to do business with a loser? When writing an agile project contract, include the following: Commitment How Much are we delivering/receiving Specification What are we delivering (this will be emergent) Planning, Delivery & Feedback Cadence (e.g. release and iteration schedule) How will we Estimate Effort & Value Effort estimated by the vendor Value estimated by the customer How will we Prioritise? Feature/Story Change Mechanism remember we want to embrace change for competitive advantage Definition of Done- Done