There are Two ways of looking at our work. The primary constraints of any project include Scope, Cost, Time and Quality. I have represented them in the following diagram as “The Traditional Way” and ” The New Way”.
The Traditional way : This is the Scope driven way of looking at the work. In the traditional way, Scope is always considered central. Assuming that Quality is non-compromisable, the other two factors are varied – time and cost. That is one of the major reasons why there are project delays and cost overruns.
The New Way : In the new way its all about Simplicity (Agile Manifesto principle 10 – “Simplicity, the art of maximizing the amount of work not done is essential). In this way, more importance is given to completing on time and in budget. Scope is considered flexible to the extent that we give what the customer wants. Of course there has to be a structure around how we give variable scope and that is described in Scrum/XP/DSDM etc. This is also based on the fact that most customers don’t really care about all scope. Its about 20% of the Scope giving 80% of the value. Thus Agile frameworks focus on Value rather than Scope – and value could be delivered on giving the Scope that customer values.
The Struggle with writing contracts in the New Way
One of the common dilemma faced by people executing Agile implementations is the way they structure the contracts. Most agile frameworks like Scrum are based on “Timebox” principle which means that the time is not variable. However, most customer-vendor relationship work on fixed-scope-fixed-cost contract (typically called Fixed Price Contracts). With the change of mindset to fixing up the “Timebox”, one might think that the contract type that we are talking about fixed-time-fixed-cost-fixed-scope. Now thats a recipe for a poor quality. If you fix up Scope, Cost, Time then the people will end up varying quality.
The most practical way to structuring the contracts to work in the “New Way”
The most common type of contract used in Scrum is either time and materials (T&M) or a pseudo-fixed price. Pseudo-fixed price is just a T&M contract with the cost of each sprint defined as resource hours multiplied by the rate. The true fixed-price contracts are the ones for which the utmost care has to be taken; otherwise, the team will find itself working on a worse-than-Waterfall project.
I have lead many projects in Scrum and dynamic systems development management in Europe and have observed some common mistakes managers make in writing a fixed-price Scrum contract. For example, Scrum contracts are written in the same way as traditional contracts, and the managers add only the “will be done in Scrum methods” line in the contract. In the traditional contract, the cost and time are always variables, with some change of budget or contingency added. However, the customer argues that because it’s Scrum, and that the concept of timebox applies, the contingency and the change budget inherently get removed. This makes the contract fixed time, fixed cost, and, of course, fixed scope.
I suggest the following modifications to traditional fixed-price contracts to make them applicable to Scrum:
- Modify the scope section by using the MoSCoW principle (the Musts, the Shoulds, the Coulds, and the Woulds).
- Use the Shoulds and Coulds as a scope tolerance when the customer asks for changes to be incorporated. Obviously, you will adapt to the customer changes, but then the customer should also understand that the scope cannot be fixed and that there is always a cost for the change. It is just that the cost of the change is taken in terms of knocking off some of the scope from the Shoulds or the Coulds.
- Include a condition that states that the scope is flexible, but when it is added to the Must section, it is fixed. However, the scope written in the Should and Could section is “negotiated” based on the changes suggested by the customer.
Leave some room for the negotiation of scope in the contract. Otherwise, you will find your team doing a fixed-price, fixed-scope, and fixed-time contract, which would be really unfortunate for the team.
This Article was published on Scrum Alliance on 30-Dec-2015 and link to this article is
https://www.scrumalliance.org/community/member-articles/1301