Late and Over-Budget: If we can’t do it with the lights out, we’d better not do it all

Last week I wrote about the bad news bump, which I think is one of the most powerful tools in the management of an Agile project.  The purpose of the bad news bump is to force a project to a crisis much earlier than is normal in a conventional project.  The purpose of the bad news bump is also to get the bosses to act strategically.  The danger of this approach is that the bosses will act succeed in acting tactically (they will always try to act tactically before they act strategically).  As we discussed in the bad news bump article last week.  One tactic is to simply deny or ignore what they’re telling you. Another is to call you names until you shut up, or get so incandescent with rage that you make sure that you never tell them bad news again.


We talked through all of this last week.  This week I want to concentrate on another particularly egregious tactic that is really, really common and intuitive.  Even though it really, really doesn’t work.  It’s got a lot of names, but they all boil down to the same dumb idea.  Trying harder, breaking a sweat, working late, crunch, 19x7.  The basic idea to these is all the same.  An Agile project manager does the maths and finds out that given the size of the backlog and given the velocity of the team a project is going to take longer than it is supposed to do.  When confronted with this the boss says “can’t they work weekends/sleep under their desks/stop sleep altogether etc. etc.?”


And of course, they can.  But really, really, this is the last thing that the boss wants. Even though you’re probably never going to persuade him of that – even as he’s being fired, or as he’s appearing at the industrial tribunal. There are two really powerful reasons for this:


1) The team trying harder and working late/weekends requires no effort and no change from the boss and hardly anybody likes to work and nobody likes to change. Getting the team to work harder avoids the awkward strategic decision that actually does need to be made.  It stop the boss having to have a difficult conversation with her boss.  And who’s to blame her wanting to avoid that?


2) The model of software as cake, that we talked about a couple of weeks ago is all-powerful and pervasive.  In the software as cake model, you want more cake, you get your team to work longer hours and they produce more cake, so what if the odd sleep baker falls in the mixer. Naturally, if it’s too tainted, you’ll throw that batch away.  And just get another baker.


Unfortunately, software isn’t cake.  Software development consists mostly of the three T’s – Talking, Thinking and Typing.  None of these can really be done very proficiently with “QWERTY” mirrored on the forehead as a result of a sneaky catnap.  In order to get good software, you need to let your team work at a sustainable pace.


When I hear the bosses advocating working “19x7” or working weekends as a solution to the bad news bump.  I must admit, my first reaction is still rage.  My second reaction is to wonder whether the bosses are certain that these people that they’re pushing so hard really don’t work for them.  What if one of them walked under bus whilst on the way home to enjoy his whole five hours of time off?  Are you certain that you wouldn’t be liable?  OK, they’re independent contracts, or they technically work for a supplier.  That’s what EA Games claimed in the law suit that resulted from the famouse “EA Spouse” blog post -  But they still ended up paying $100M dollars.


The third thing I think (and the first thing that I’m probably going to say) is that it really isn’t a good idea to be trying to explain complex business concepts to someone who hasn’t had a full day away from his desk in weeks.


If you can’t persuade the bosses that making highly-educated, technology professionals work until they drop dead isn’t a good idea, I suggest you just ignore them.  Go home at a reasonable time yourself.  Encourage your team to go home at a reasonable time. 


And make absolutely sure that all the important work happens during the working week in daylight hours i.e. when you can have the lights off. Even more forcefully than working late and working at weekends, what you should absolutely resist is any attempt to carry out important steps in the software development process over the weekend.  This is what the (rather smutty) title refers to.  You should especially avoid doing things like build and release at the weekend or late at night.  Why?  Because when things go wrong, when the lights are on, there won’t be the staff there to help you.  And when things go wrong late at night when the lights are on and the staff aren’t there to help you and your skeleton team, that’s when you’ll be tempted to cut through all the processes that you normally observe and do things like hack scripts in the live environment, and drop non-source-controlled binaries into the live environment.


When I think of this kind of scenario, I vividly remember a former boss of mine considering dropping non-source-code-controlled binaries into a live environment.  If we’d let him there was more than a slight chance that he could have left $30M dollars’ worth of software in an impossible to roll-back, un-repairable state on a live site. What is particularly dangerous about these kind of “lights-on” late-night antics is that developers, even very senior developers who should know better, will cooperate with these kind of late night antics.  The reason I think, comes back to the three T’s – good software development should always consist of talking, thinking and typing. It’s a bit dull.  Every now and again, a bunch of mostly blokes are going to want to stay up late, get drunk and set fire to something so they can feel their life has meaning.  If you’ve ever read “The Secret Life of Walter Mitty” (and if you haven’t, then you should – here, there’ a distinct air of  “Pocketa, Pocketa” about this need for drama.  The trick is, as a manager to make sure this happens well away from access to the live server.


This is software development.  Not field surgery, not guerilla warfare. There should very rarely be any requirements for drama and heroics.  Those who want this kind of drama should perhaps take up paragliding, or talking loudly in a received pronunciation acccent in certain West Yorkshire pubs (I can give you a list).


This is also why I despise military analogies for software development.  In any software project that’s delivering anything valuable, nobody should be going over the top of anything and nobody should be throwing more bodies at the problem.

147 views and 0 responses