I was at client a while ago that were after any assistance they could get on a project exhibiting all the symptoms of a classic Death March project.  A waterfall based process gone horribly wrong, developers working ridiculous hours, poor code quality, emergency fixes, misunderstood and late-changing requirements, staff leaving due to stress and so much more.  It was all there.

I was originally going to write about how this all came about, but the more I thought about it the more I realised that how it came about wasn't really that interesting to me.  What was interesting was what crunch time revealed:

1. Communications.  The prevalent form of communication during crunch time was verbal, and typically face to face with a notepad or whiteboard handy.  Hardly any emails, hardly any paperwork, just people talking to people to ensure communications were clear and understanding was mutual.  Fast and effective.

2. Team work.  Pressure can do one of two things to a team - either break it apart or bring it together and form something stronger.  In this case it was the latter.  Watching how the team came together to support each other and achieve a result was fantastic.

3. Blurring of boundaries.  There is usually a very clear departmental delineation between the developers and the infrastructure people (i.e. the team responsible for the production environment).  This is the case in many large firms, however during this particular crunch period the line was much more "malleable" with people from both departments working extremely closely together to find problems and get things resolved as quickly and efficiently as possible.  Why developers couldn't have read-only access to production on a regular basis is still a mystery, but at least they overcame it during the crunch.

4. Impediment Removal.  The manager responsible for the development team did everything in their power to remove obstacles.  Whatever it took, they did it.  This ensured that the team could focus on delivering the project and that nothing else interrupted them.  At one point the CEO even picked people up from their homes to save them time on the commute.

5. One prioritised task at a time.  During the crunch all the remaining tasks were prioritised in a simple excel sheet.  Each developer took a task and worked on it, and nothing else.  No multitasking, no new jobs until the current task was complete.  This avoided the usual situation of having 5 tasks all active at once as trying to task swap between them as the mood takes you.  The excel sheet was communicated to everyone everyday so that all stakeholders were kept up to date on progress.

 

It's really interesting how crunch time forces you to genuinely prioritise what you do. How much regularly wasted time teams usually have and how much of that just isn't necessary when a deadline looms and just how effective people can be if you clear the decks for them.

What's even more interesting is that this is the sort of behaviour we want from an agile team each and every day of the year.  Just without the soul crushing pressure of a death march project :-)

Something to think about, isn't it?