Fixed Date Fixed Scope Scrum

Often when talking to people transitioning to agile or thinking about it I get asked the question: “Agile seems great, but in our business we need to engage in fixed scope fixed date projects with our customers, so how can Scrum work for us?”

Usually when I am asked this I realise that the person I am talking to believes that agile is an alternative to waterfall to deliver the same thing, and they are trying to choose between the 2 approaches, kind of like choosing between vanilla or chocolate ice cream.

However what you need to realise is that agile and waterfall are not in the same category, they are not even trying to achieve the same thing in my view. Only when this is understood will people stop asking how they can get waterfall artifacts from Scrum, and instead embrace what agile has to offer.

So if I’ve just confused you further, let me explain what I mean.

What waterfall promises is a known delivery of predetermined scope on a fixed date. This seems fantastic and exactly what we need in software until you realise two fundamental problems:

1. It is a lie. According to the Standish Group’s Chaos report only 16% of software projects deliver on time and on budget. This number is far too low to just be due to bad execution. How can most of our industry be bad at their jobs?
2. You don’t need it. Again according to the Standish Group 64% of scope is rarely or never used. That sounds like an awful lot of waste to me. Would you not rather pay 64% less and just get stuff you will use?

The waterfall myth

Talking to a colleague today, he referred to the ‘illusion of predictability’. In a waterfall project you do the requirements and deliver a Requirements Doc. Check, you are on track. You do the design and deliver a Design Doc. Check, you are on track. You write the code and reach Code Complete. Check, you are on track. You start testing and the wheels fall off. The problem is that you were never on track. You had problems from day 1, but the interim artifacts deluded you into thinking you were predictable. Agile offers only one way of measuring if you are really on track: the delivery of working software. You need to deliver 3 features. You deliver 1 feature. You are on track. You deliver 2 features. You are on track. You try to deliver feature 3 and the wheels come off. You still have a product with feature 1 and 2 in it, ready to ship. No delusions, just honest visibility about what is really done.

The light bulb moment for me came when reading Ken Schwaber and Mike Beedle’s black book. They describe how waterfall is a defined process, similar to what is used in the classic engineering. Given a defined set of inputs, and processes you will get a defined output. What they realised is that software is not that. We can’t use a defined process control model because the nature of the work is not the simple execution of predefined tasks. Instead we need to look at an empirical process model, one which acknowledges that the only way to control the outcome is by continuous inspection and adaption. This is not new. In fact Deming talked about “Plan, Do, Check, Act” in the 1950′s.

                                                  Deming Cycle

If we want software projects to start being successful we need to let go of our view which believes that a defined process model works for software. It doesn’t. It’s been proven. We need to embrace an empirical model. I also think we need to redefine our parameters for success.

Previously a successful project meant that it was delivered on time and on budget. That is according to a budget and time frame determined at the start of a project (usually months if not years before completion).

Research shows that this is not what customers value most. A survey by Scott Ambler shows:

• 83% of respondents believe that meeting actual needs of stakeholders is more important than building the system to specification.
• 82% believe that delivering high quality is more important than delivering on time and on budget
• 70% believe that providing the best ROI is more important than delivering under budget

You might be asking yourself: “If agile isn’t going to give me projects that deliver fixed scope on time and on budget what is it going to give me?”

Here’s my view:

1. An honest view on a daily basis of where you actually are according to your plan, which is based on evidence, not someone’s subjective view of their percentage complete.
2. Systems that your customers actually use.
3. Better quality software.
4. A return on investment for your customer that will hopefully delight them and keep them coming back for more.

Now you say: “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? How do you think they feel when you deliver late or with bad quality? Isn’t it time we faced up to being honest with each other? Can’t we start a new style of business, one built on integrity? I guarantee that once customers realise that this is what you are about they will be far more likely to do more business with you in the future.

I accept that it might be a hard sell initially. I accept that some customers might be hesitant, and there are some techniques we can use to meet them half way and provide them with enough detail for them to be confident to engage in the contract. I’ll mention these in a later post, so stay tuned. However, I do not mean for these to be methods for people to continue the fixed scope fixed date lie. The aim should be for complete transparency with our customers, and for building a relationship that will enable us to be even more agile in the future, because this can help us to be even more successful, and in turn for our customers to be even more successful.

Also take a look at our book Growing Agile: A Coach’s Guide to Release Planning for some more ideas.