Sat 16 April 2016
Many large projects are late. Most of the time the the actual journey turns out to be much harder and much longer than it looked when we started out.
From a management perspective we are constantly looking for validation that we're hitting the plan, whether it's traditional milestones and deliverables, or sprints. We're constantly asking 'how long will it take', just like kids are always asking 'are we there yet?'
Sadly, 'estimate' is just a polite way of saying 'guess' and our guesses are often wrong.
But the good news is, I'm pretty sure that improving our estimates and plans is not the most important thing when it comes to delivering large scale projects in the least possible time.
A project is like a journey. If we want to complete a journey from A to B, what can we do to get there as fast as possible?
Before I give you my take on the answer, why not have a go yourself? The map below runs off the bottom of most screens, so you'll have to scroll past it to read on. Before you do that, why not write down your ideas about how to speed up a journey. And by all means click on the map to find out what happens when you try to walk from San Francisco to Los Angeles.
OK, now you're here, let's get from A to B as fast as we can.
There are quite a lot of factors. I expect you've thought of some of them. I'm pretty sure you've not thought of all of them:
CHOICES: How are we traveling? Walking, running, swimming, cycling, driving, flying?
PREPARATION: How much preparation do we need to do? Buying tickets, packing, saying goodbye, waiting for a taxi, getting to the airport, checking in, getting through security...
OBSTACLES: How do we deal with holdups? traffic, check-in line.
SPEED: How fast can we go? Can we improve our fitness, get a better bicycle, a faster car, a more direct flight?
IMPORTANCE: How important is it? Can we hire a helicopter or a jet? Maybe we don't need to go at all.
By now I expect you're out of things that can affect the journey time.
FREQUENCY: How often do we need to make the journey? Maybe we should invest in a private plane. Or arrange to move A or B to shorten the journey. Or settle for phonecalls and streaming video.
UNCERTAINTY about starting point: What if we're not where we think we are? Do we actually need to start from A? Maybe our journey can be faster if we go directly to B.
UNCERTAINTY about travel conditions: traffic jams, bad weather, diversions, breakdowns.
UNCERTAINTY about destination: Do we know for certain where B is? What if we go where we think it is, and find out it's actually somewhere else?
Maybe you're wondering what this has to do with software?
Well, all of the above factors affect software projects. And most of the time our perception of where we are starting from (A), and where we are going (B) are somewhere between vaguely right and mostly wrong!
We don't really know where we are at, because there's too many external factors, and our communications are imperfect. For example:
- the budget is not what we think it is, because someone's already spending some of it elsewhere
- the team is not as strong as we think
- most of them are still being asked about issues from their previous projects
- the platform doesn't really work as well as it looks in the demo
- the suppliers' prices are subject to change control
- and their competence and delivery dates are exaggerated
And we definitely don't know precisely where we're going, because:
- the spec is terrible
- and since we are 'agile' the team are going to ignore it anyway
- we're working with some new stuff and nobody really knows how that's going to pan out
- there are interlocking projects, and we'll need to adapt to what they do
- there are competing projects, and we'll need to adapt to what they do
- management may adjust priorities or move the goalposts at any time
So let's revisit the factors, in project terms:
UNCERTAINTY: if we're not sure about 'here' or 'there'
- we choose somewhere in the general direction of 'there', near where we think 'here' is,
- and set off towards that first interim goal
- and keep gathering new information about 'there' (and maybe about 'here' too)
- and choose the next goal (maybe even abandon the first goal) based on new information as we digest it
CHOICES: can we choose
- another destination?
- different deadline?
- different processes, team, tools, systems?
DIRECTION: we'll get 'there' faster if
- we know where 'there' is
- we start from the closest place (which may not be re-using the last implementation)
- we go straight towards it if there's a direct path
- or we choose the best indirect path
- or we carve out a new path if the indirect ones are too slow
SPEED: engineers work faster when
- they are intelligent
- and they have time, bandwidth and permission to think
- and they know what the objective is
- and they believe in the objective
- and they are up-to-speed with the tooling
- and the tooling itself is fast
- and the tooling is appropriate for the job
- so don't choose a jet to travel across town
- don't choose scissors to cut the grass
- don't choose anything other than git for version control
BLOCKERS: best to
- clear them as fast as we can
- or go around, over, under, through
- or choose a different route, even if it involves more distance
FREQUENCY: if we're going to be doing this a lot
- get the fundamentals right: scope, architecture, approach, people
- so we're not still dealing with crap in five years' time
RISKS: best to
- identify them as early as we can, and mitigate against them
- keep our options open (maybe we'll find better hardware, tools, people)
- get feedback as fast as possible (real-time comms, iterations, honesty + transparency)
- be ready to adapt to problems and changes
PREPARATION: best to
- take into account all of the above (hence it's last on this list)
- there's no point preparing for the wrong journey
- some of the preparation can wait, and be done on the way, or later (no need to choose final hardware on day one, if we're expecting new products to appear in a few months)
Are we there yet?