The Definition of Done is an agreement between the Scrum team and the product owner on a minimum quality barrier for the product that’s being built. Establishing a minimum quality barrier has much wider implications than just better quality product, although that is one outcome of having a Definition of Done. This article is about the impact of a definition of done on the types of contract that Agile teams work with.
Author: Kane Mar, Scrum Coach, http://scrumology.com
What is a Definition of Done? At its most conceptual level the Definition of Done is an agreement between the product owner and the team about what is meant when someone uses the word done. What this means explicitly is that the PO and the team need to sit down and list all the things that they need to achieve before some body of work (for example, a user story) can be considered done.
Let’s take a look as some Definitions of Done so that you have a better understand of what’s required. I found these with a quick Google search, and I’ve included the best examples below.
source: http://pollenizer.com/definitions-done-and-ready
J’Roos Flickr photostream: http://www.flickr.com/photos/jnicho02/2828060974/
source: http://agilecoach.typepad.com/agile-coaching/2010/10/defining-what-done-means.html
The Iron Triangle
In order to understand the constraints in fixed priced projects, I need to first discuss the Iron Triangle … a model of constraints often used with traditional project management. We’ll then contrast this with the constraints found in a Scrum project.
In the Iron Triangle model of constraints, one side of the triangle cannot be changed without affecting the other two. Different variations of the iron triangle exist but the most common shows time, cost, and scope at each of the vertices. A change in any of the constraints directly impacts the other two constraints.
… in 1969, Dr Martin Barnes (UK) first described the ‘iron triangle’ of time, cost and output in a course he developed called ‘Time and Money in Contract Control’; but interestingly, even then the course was not entitled ‘project control’. [1]
If you constraint one of the three variables of time, cost, or scope, it will put pressure on the other two variables … and one of the other two variables has to give.
What you cannot do is constrain all three variables at the same time.
The concept of an iron triangle was popularized by its inclusion of the PMI’s Book of Knowledge (PMBOK). Modern PMI members will object and say that it’s no longer part of the PMBOK and this is true. The concept of the iron triangle was removed from the PMBOK starting with edition 4 (the current edition is PMBOK 5) after having been a fundamental part of the PMBOK for the first 50 years of its existence.
There is a fourth dimension to the iron triangle which is seldom called out; that is Quality. Quality sits in the middle of the iron triangle, and it directly impacted by all of the three previously mentioned constraints: time, cost, and scope. It’s often shown in the middle of the iron triangle to make this point.
Constraints in fixed cost projects
Fixed-priced contracts are a really bad term, because we fix more than just the price. Most Fixed-priced contracts have the following constraints:
* There is an agreed upon scope that needs to be delivered
* There is a delivery date for putting the product into a production environment (often with dates for interim milestones), and
* There is a fixed price for the work.
All three constraints of the iron triangle are fixed with Fixed-priced contracts. Going forward I will use the time Fixed-priced contracts for contracts that have a fixed time, fixed cost and fixed scope.
But wait … there’s more!
There is one final constraint which the quality of the product. So we can deliver the agreed time, cost, and scope to the detriment of the quality of the product that we’re shipping.
With Fixed-priced contracts, we should expect to see behaviors that compromise the quality of the product but not the other constraints. And this is exactly what we observe: as project teams come under pressure to deliver we seldom remove scope or extend the deadline. Rather, activities such as unit testing, code reviews, and integration are the activities that are compromised.
Constraints in Scrum
Scrum (and agile software development) take a different approach to producing products. The approach taken by Scrum teams is to fix the quality, and we do that by having a Definitions of Done.
What this means is by fixing quality then one of the other attributes need to change. Either scope must be variable, or cost must be variable, or time must be variable … something has to give.
Let me be clear about the implications of having a Definitions of Done. Having a Definition of Done breaks Fixed-priced contracts. Attempting to do a Fixed-priced contract with Scrum will lead to an iterative death march anti-pattern. [2] [3]
Postscript
I wanted to end this article there, but I felt that it would raise more questions than it answers. The most important of which is; what types of contracts make sense in an agile or Scrum environment? There are many types of contracts that Agile teams will use including Time and Material (T&M) contracts, capped T&M, etc. By far my personal preference is incremental delivery contracts. I wrote a brief overview of agile contracts, here http://scrumology.com/an-overview-of-agile-contracts/
References and notes
[1] http://www.mosaicprojects.com.au/PDF_Papers/P050_Origins_of_Modern_PM.pdf
[2] Some argue that it’s possible to do fixed priced contracts with Scrum (reference: http://www.noop.nl/2008/09/fixed-price-contracts-require-agile-practices.html) but even then they’re really talking about using variable scope contracts.
[3] One argument that is often offered up is ‘Isn’t as a Sprint a mini-fixed cost project?’ The answer is clearly no; although Sprints are time bound and cost bound (assuming a dedicated team) they have variable scope.
Biography
Kane Mar is a Scrum Coach and Certified Scrum Trainer. He first worked with Ken Schwaber (the Co-creator of Scrum) in 2001 and has been actively involved with the Agile community ever since. Mar became a Certified Scrum Trainer (CST) in 2006, a Certified Scrum Coach (CSC) in 2007, started the very first Scrum users group (Seattle Scrum) in 2007, and co-founded Scrumology.com in 2009. You should check out his blog on http://scrumology.com