Problem in a nutshell: Work should be released when it reaches the quality needed with the features required. Of course small releases give the fastest feedback, and this post isn’t saying you should do larger releases. This post looks at whether setting a date or time goal does impact delivery.

Runners in the New York marathon finish in higher concentration just prior to hour and half hour and fifteen-minute elapsed time boundaries. Why? It is speculated that their is a mental race going on in each runner head and they try and achieve the next personal goal-post. Don’t they just run as fast as they can? Sure, but they also need something to pace themselves against in order to judge their ongoing pace and balance it against exhaustion (it should be noted i’ve never run a marathon!).

Clustering of finish times.

Clustering of finish times.

Its 1.4 times more likely to finish 3:59 than 4:01.

Its 1.4 times more likely to finish 3:59 than 4:01.

Having a goal in mind means that constant adjustments throughout the marathon help achieve finishing on goal. Whilst the runners can’t pickup half hour faster than personal best, they get early feedback they are off pace and adjust early to maybe reach a few minute(s) before a boundary.

I think the same needs to happen when we set goals for software delivery teams. They need constant feedback that they are on-pace for adjustment early – NOT cramming at the end. Having a date in mind is the only way to compare delivery pace of work versus a pace required to achieve that delivery without heroics. Heroics are failure. It puts teams in burnout mode and they fail to continue consistent pace after crunch making it impossible to reliably forecast. If I see a team moving into a feature or project have crunched in a prior delivery, I halve my throughput estimates for one to two times the crunch period. Its just NOT cost effective to have teams crunch.

My advice –

  1. If teams have crunched, reduce throughput estimates by 1/2 for 2 times the crunch period they endured
  2. DON’T use throughput samples during crunch mode. They are artificially high and cause crunch mode in the next plan!
  3. Set a delivery date and work out what team size and scope will fit into that period (using our spreadsheets of course :))
  4. Track delivery pace against this plan. The moment delivery falls behind, revisit the scope expected and communicate it is at risk. Get small actions taken earlier
  5. Track when teams are crunching versus sustainable. I put a C and a S in the notes of any throughput weeks I capture in our spreadsheets. Any team spending more than 10% year crunching is costing the company delivery pace and money. Compute this by estimating the salary of the team and computing what running half pace for 2x the crunch period costs.

Troy.