Last week, I attended the first Swiss Lean/Agile/Scrum conference. As usual, the Swiss take a long time to catch up with new ideas and technology, but when there’s money to be had, they’re right up at the front of the line. Anyway, Ken Schwaber gave a very interesting presentation on the concept of “Done”. He showed the canonical burndown chart, and then took the individual vectors apart.

Seeing the variables separated like that got me to thinking, and I had the chance to run my thoughts past Karl Scotland and Keith Braithwaite, both of whom went out for a beer with me afterwards.

Back in the early days of XP, we defined a set of project variables:

The rule went, “Time, Resources, Quality, Scope – choose three”. Whichever three you chosse, the fourth variable would be a function of the other three. Which three were actually chosen was the customer’s decision. Some customers (and managers) don’t understand this rule, and try to grab control of all 4 variables. By doing that, the first variable that’s dropped is quality, followed by time.

So, how do these sets of variables map to each other? The first two are easy:

• time = time
• backlog = scope

The other 2 are a bit more difficult:

• V = f(R)

Velocity (burndown rate) is a function of the available resources. Regardless of what you have to do, having more resources will normally allow you to go faster. This function is non-simple and non-linear, unfortunately: as Fred Brooks rightly says, “adding manpower to a late software project makes it later”, but the simple case is a more or less linear function.

Quality is even more complicated:

• q = ∂V/∂t

As Dan Rawsthorne says, “Quality is the first derivative of the burndown”. The quality of a product is directly related to the development velocity/burndown rate.

So, so much for that thought. Keith spun the thought even further, proposing in his recent blog post that you can increase velocity by increasing quality. I agree with him, and I recommend you read the post.

At the end of my Scrum courses, I do a final exercise and let the attendees prepare a 5-minute presentation on Scrum. Depending on the people and circumstances, this presentation may be targeted at management, marketing, customers, developers etc. At a recent course, someone asked me how I would present Scrum as an elevator story to management, and I remembered something I used when starting my business in 2001:

Scrum is not a win-win proposition, but a triple win-win-win proposition. It meets the needs of all 3 parties involved in the process: customers, management, and developers.

• Customers  win by getting the product they actually want and need.
• Management wins by having a real-time tracking and controlling of time and budget.
• And last but not least, developers win by having the freedom and responsibility to build world-class products.

That’s my story in a nutshell…