This post has been moved to my company blog at Growing Agile – you can read it here:
Quite a few statistics are quoted in this blog, yet very little of this form of analysis is applied to the Scrum process. It would be interesting to objectively measure what the actual improvement in the delivery of software using Scrum in terms of the on time and on budget principle.
It seem that a lot of the reason given for adopting the Scrum process are mostly perceived benefits rather than any objective measurable benefits in terms of delivering software on time and on budget.
If you follow the link to Scott Ambler’s research he does have data on the success rate of agile and Scrum vs traditional projects. I don’t quote these because I think that’s an outdated notion of success which is not relevant anymore.
From my own experience the reason this is hard to measure is very few of the companies I have worked for kept data on their success before adopting agile. Mostly because they were never successful. As a result it is difficult to show a measured improvement if pre-Scrum there was no measurement.
“But I can’t sell this to my customers. We sign contracts with them saying what we will deliver, or we ship products that need to meet what we promised the market a year ago.”
And I say, how do you feel about lying to your customers?
Let’s say that the above is spot-on accurate: that any promise to a customer about what we will deliver is a lie. Does this mean that in industries where the customers have no choice but to demand specific products through a contract (e.g., government work), it is simply impossible to use scrum? I am curious because I very much want to apply scrum, but am in an industry where the contracts are fixed exactly like this. Is it possible to do it simply by adding padding so that we can meander creatively and deliver extra, high-value features at the same time that we are delivering on the agreed-to contract?
Yes I think you can apply Scrum in a Fixed Scope contract and you will probably get some improvement over your current process because you should have feedback on real progress each sprint. However the agile manifesto states we value customer collaboration over contract negotiation. This means it is more important to deliver software that meets the customers business need than it is to deliver what the contract asked for. I don’t believe any customer can know up front exactly what they want. Therefore the idea of delivering stuff just because they asked for it a year ago is not agile in my view. I think the secret lies in your sentence “customers have no choice”. Customers do have a choice about how they contract. There are many companies now contracting on an agile basis. They contract on the business goal, rather than the software scope. Government departments are doing it too.
Check out this blog post and ask yourself “what is possible for me?”. Even if it seems impossible to change how your customers think now, I say try Scrum, build trust, and then see what the possibilities are from there.
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account.
( Log Out /
You are commenting using your Google+ account.
( Log Out /
You are commenting using your Twitter account.
( Log Out /
You are commenting using your Facebook account.
( Log Out /
Connecting to %s
Notify me of new comments via email.
Blog at WordPress.com.