Crunch Time: If You Play, You Pay

February 20, 2013

Wiktionaryx defines crunch time as, “A critical period of time during which it is necessary to work hard and fast.” We’ve all faced deadlines and for various reasons, when work has piled up and we need to suck it up and get things done. And this may very well mean working longer hours than usual.

Do we get a productivity boost from overtime? Yes, but we need to make sure that we limit this overtime to short bursts of a few weeks. And there is a trade-off involved; as Daniel Cook says in a great productivity presentation, “When you crunch, you pay.”

Dan’s research tells us that we need to plan for an equivalent reduction in productivity immediately after crunch time. He graphically illustrates this as follows:

As you can see, we get a temporary boost in productivity with overtime, but if we attempt to work overtime for extended periods of time our productivity begins to reverse and it can actually go negative. And no matter how you slice it, anything over 40 hours results in a recovery period.

What about teams? In his slide deck Dan shows us how overtime will trend with an agile team:

Of course, agile teams should be embracing sustainable development, shouldn’t they?

But there is a good leadership lesson here: working an existing system harder won’t achieve sustainable, long-term gains. If you aren’t reaching your desired objectives and you attempt to compensate by demanding overtime, it is predictable that productivity will temporarily increase – giving you a comfortable feeling that you’ve righted the ship – but your gains will be short-lived and productivity will level itself out in the long run.

What are your options?
  1. Focus on throughput. Find sustainable ways to accelerate completion rates of work by increasing collaboration, combining tasks and eliminating overhead that isn’t adding value.
  2. Add another team to provide greater capacity.
  3. Adjust your expectations on either the delivery date or the scope.


Nice post. I personally believe that esp. small teams are better of following a "tracer bullet" approach (Pragmatic Programmer). Implement a thin slice that reaches some minimal criteria for a motivation boost and spend the rest of time adding value till the deadline.

Of course there's the thing that you keep learning while doing (esp. if you haven't done it before) and it might lead to some rework. Especially in this case it is a good idea to use a light approach that doesn't tie you too much mentally to some specific direction and allows you to make saner choices later on.

February 20, 2013 at 2:36 PM
Dave Moran said...


Great observations! I too am a fan of creating a series a small wins. And count learning about what the customer really wants as a win as well.

February 20, 2013 at 8:29 PM

Post a Comment