Running Scope creep backwards

One of the criticisms levied at Agile software development is that of Scope Creep. Project managers seem particularly sensitive to this issue, probably because its been fatal to many projects before and thus Project Manager are trained to watch for it and come down hard on it.

However, I’ve come to the conclusion that in a lot of Agile work the secret is to run Scope Creep backwards. Rather than have a project get bigger as more and more requests are added to it what we need to do is have it get smaller over time. Let me explain.

Typically a product/project gets specified and then work proceeds, as it does more and more "change requests" appear, things people hadn't thought of, ideas for what else it could do - scope creep. (See my piece, Why do requirements change from a few years ago if you want to know more about the why.)

As projects grow in size the chances of them meeting any deadline diminish. This is why traditional Project Managers look at Agile and throw their hands up in the air seeing rampant Scope Creep.

But if you run it backwards, write the spec, write it as big as you like, who cares how big you write it or how many features you put in. The bigger it is the less people will remember. (See my piece on the Documentation myth for why big documents don’t work.)

Allowing everything into the spec means you don’t have to have those hard conversations about what’s in and what’s out. Everyone gets to feel there thing is in.

Now prioritise. If its really big make a first pass with MoSCoW rules. Anything which isn't MUST have can be ignored for now - you've probably got more must's than you have time for anyway. Generally I’m not a fan of Moscow rules but they are OK as a starting point when you have a lot of requests.

(Note: that’s MoSCoW rules, not Moscow rules - personally my only Moscow rule is avoid the city, my last trip there was awful so future visits are restricted to changing planes.)

Now within the MUSTs prioritise 1, 2, 3.... N. No duplicate priotities. This way when something increases in priority ther things fall automatically, people immediately see the consequences of their decisions.

What criteria you use for prioritisation is up to you. Doing it by value makes a lot of sense, so does doing it by risk. It also makes sense to get some early wins under your belt.

Next work through the items in priority order.

Anything that comes in later (Scope Creep) has to be slotted into these priorities. Add a new item with priority 3 and everything 4..N moves down one.

Notice I’m not interested in change control. I don’t make any effort to restrict the work that is asked for. All I do is demand it is prioritised along with everything else. Valuable ideas can arrive at any point in the work so why draw an arbitary line to differenciate what was “in scope” and what was “out of scope.” The objective is deliver value.

Now as you work through the list you will find that with items 1..N' you have a a valuable product. Something you can at least show to customers, something people might even pay money for today.

Once you start getting real feedback - especially the sort represented by money - everything changes. Once you know what real customers want you are, literally, in business. You’ll want to add new items and look again at your priorities.

At this point you've saved yourself the work N'..N plus all the Should Have's, Could Haves, etc. This is running Scope Creep backwards.

What all of this highlights is that building a software product isn’t a binary decision. It isn’t “all of this stuff” or nothing. Its an analogue thing not a digital thing. Traditional projects spend a lot of time trying to prevent scope creep through tough change control procedures but really it doesn’t matter when a request comes in. What is important is what is the value it will bring.

Value, not arbitary dates, should be the criteria for deciding what to build.