13 October 2014, by Chris Harris
The following is an excerpt from Zoe Cunningham’s new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on her website, here.
They won’t go away
Every team and individual works to some kind of ‘to do’ list. It might be in their head, or written down in the form of stories, or stored elsewhere, but we all have one, and some sort of ordering will be applied to this list.
One very common means of ordering is in fact the very opposite of a good order for development tasks. If your subconscious is inclined to lead you along the easy path through life, then you will find that the more simple tasks will tend to drift to the top of the pile. This may result in you feeling very efficient – you’ll be burning through loads of tasks, and probably even getting ahead, which has to be good, right?
Wrong. The apparent gains you make by taking on the easy tasks first are in fact the opposite; they constitute a debt of hard tasks and risk that you’re building up for later in the project. Your burn-up chart will eventually tail off as you hit the harder, less-well-estimated and riskier tasks. And the later you uncover these problems, the fewer options you have for dealing with them.
The best tasks to do first are therefore the hardest ones – the ones that fill you with dread just from looking at them – the ones that you really do not have a clue how to approach – the ones that you hope might go away if you ignore them. They won’t.
They represent uncertainty
Hard tasks are essentially risks. If you don’t know how you’re going to do something, how do you know that it’s even possible? You certainly don’t know whether it can be done within the time allocated. If something is difficult, there’s a good chance that it will take a lot longer to solve that you’ve allowed for.
The other tasks that should be prioritised first are those that are in some way dependent on other parties. If you have developers who don’t like to interact with irrational, unhelpful and unreliable third parties (and let’s face it, who does?), they may be naturally inclined to leave such tasks until they have no choice but to do them. Of course, it’s the unreliable nature of third parties that means that you need to leave plenty of elapsed time (if not actual working time!) to deal with whatever inconsistencies and changes you might uncover, and to work around system outages, holidays and all the other blockers at their end. How many times have you been given a third-party interface definition and tested against the test site successfully, only to find that the live site doesn’t use quite the same format? How many times have you left your testing to the last minute only to find out that the test server is down? The weapon with which you can overcome these pitfalls is time. Make sure you have enough of it.
They might include delivery tasks
‘Release tasks’ deserve a special mention at this point. They’re easily overlooked, for all the reasons I’ve just mentioned. They can be very much ‘out of sight’ during the development phase of a project – they are simply not part of the tasks that you’re doing now; they are part of the next phase. What’s more, they often hinge upon many unknowns. You might not even know whose job it is to figure out the unknowns. If you’re going to have to deploy on to hardware that’s owned by another department or even a different company altogether, there are all kinds of potential hurdles that you’ll need to just identify before you can start planning for the rollout of your software. Some of these things you can do yourself, but some will need the involvement of the guys who run the hardware. Whilst development is still ongoing, dates, exact user characteristics and all kinds of other essential facts can be completely unknown. And this is exactly why you need to start planning this phase nice and early.
If your team is going about its tasks in the wrong order, it will manifest itself in late or rushed deliveries, last-minute changes and a general air of panic as you approach the end of a project. Don’t be tempted to leap in! Managing your team to help them achieve their objectives in such a situation must still be done in the same way: through empowerment and delegation rather than micromanagement. Insist that they try a new way, and let the results speak for themselves.