Another slightly abstract post today, though based on very real and pragmatic problems. When working on a project, where there are 100s of different options for things you can do and you’re drifting in to option paralysis, often a manager will use a deadline (for example, an event, or a customer demo) as a way of forcing the team to make decisions and progress – aka “helping the team to focus” :-). But I’ll argue that you can go one step further, and just use completely arbitrary deadlines to help bring focus. Why wait for an event in the real world?

I’ve previously mentioned Good Strategy/Bad Strategy by Richard Rumelt – a great book on how to create meaningful and useful strategies. One of the core stories in the book is around the moon landings in the 60s: scientists were worried about how they could design a landing vehicle to land on a unknown surface that would survive. This was leading to paralysis where the teams couldn’t progress because there were just too many unknowns in the problem. So, what did the director do, to aid progress? She set what was, essentially, a completely arbitrary constraint, that the moon surface would look pretty much like a desert in the US. What the director was doing here was setting a completely arbitrary constraint – how could she know if the eventual lunar surface was anything like the surface of the desert? Couldn’t she just have been so wrong that all of the work was a waste of time? My view is that it doesn’t matter – what she gave the team was a way of moving forward, getting something done. Maybe it was a waste of time, but better to do something – and likely learn some things along the way – than just do nothing, paralysed by uncertainty.

There’s another more subtle theme that goes through this book as well – constraints over time. The concept of “proximate objectives” (i.e. setting a short-term objective) relies on a constraint in time – “We are going to achieve this thing in 6 months” (or a year, or whatever). Why 6 months? Why not 9 or 10? Why should your timescales be based on half of the time it takes for the Earth to orbit the sun? Again, completely arbitrary.

One of the great things we’ve implemented at Redgate is the concept of release trains – see http://blog.red-gate.com/success-weekly-releases-occasionally-dont-release-release-wednesday/ for some more info. This is a method for running an Agile project and representing a backlog, by splitting the work for a project up in to separate carriages on a train. Each carriage represents a block of work which will be released. But here’s where it gets interesting – each block of work (or “carriage”) is a pre-decided length. For one project, this is 6 weeks – so every block of work carried out as part of the project needs to be done in 6 weeks. How can the team work with such artificial constraints? What if the work that needs to be done is 8 weeks? Or 4 weeks?

Here’s why this works so well – if you’re adding a new feature to a product (let’s say it’s “Allow user to register on the site”) a large part of what the product manager and team have to decide is “How big is this piece of work? How long are we going to take on it?”. And this is a problem – how do you make this decision? How do you assess the importance of the work and stop at the appropriate point, before moving on to the next feature? This is a real problem – before you do the work, you don’t really know how important it is, so when will you know when to stop?

Now, if we set, what is admittedly, a completely artificial length, to the piece of work we do – say 6 weeks – what does this give us? At least:

1. A roadmap – we can draw the train (with carriages) on a piece of paper and say, “Here’s what’s happening in the next 6 months – we’re going to do four blocks of work on features A, B, C and D” (four blocks of 6 weeks is approximately a half-year, with time off for good behaviour). So everyone knows what’s coming, internally and if you like, externally. NB: We’re still Agile – nothing is set in stone, we can adjust based on feedback and so on. But you are giving visibility to those that want it.
2. It forces good decisions in a team – if you want the feature to do everything, then it won’t look beautiful. Or vice-versa – but not both. For example, for our feature “Allow users to register on the site”, well it could integrate with all sorts of authentication mechanisms – Active Directory, 3rd party mechanisms, your own, but it’s not going to do all of those in 6 weeks AND have wonderful usability. The team has to start making grown-up trade-offs – is one sort of authentication okay? Is usability more important that types of registration? Suddenly the discussion is about the real value of each piece of work to customers – and this is good.

I.e. it gives product managers visibility and a great tool for planning, and it gives teams a mechanism for making good decisions. But primarily it stops option paralysis – conversations like “Well, if we did make it look nicer, wouldn’t that be great?” or “Why don’t we add these other three authentication systems as well?”. It allows you to get on with something, do it, finish it, measure its success and move on.

Of course there’s a risk – what if, by just adding that one extra feature, you did the thing that every customer wanted and that made the product a success? Well, may be, but two things:

1. How would you ever know that, upfront? You can’t.
2. Opportunity cost – what if the next carriage on the train was the thing that unlocked customers? You’ll never get on to it if you don’t get the current carriage completed.

So I’m a fan of completely arbitrary deadlines – IMHO, don’t even bother looking for a real deadline (or other constraint), just set one at an artificial point in time. The benefits out-weigh the cognitive dissonance caused by working to something that seems somewhat random.