Aiming towards Sustainable Pace
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — The Agile Manifesto Principle
“programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.” — Extreme Programming
An unsustainable pace is unhealthy. It contributes to burnout, quality issues, and unpredictable results.
If you are an agile leader — do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer?
Measuring Sustainable Pace
Beyond having a general idea of the sustainability of pace, perhaps it would help to have a concrete KPI related to it?
If we use the language of OKRs, maybe something along these lines:
Objective Achieve a healthy sustainable pace KR1 — People working reasonable hours AMB (as measured by) hours per week KR2 — People happy about their pace AMB continuous survey KR3 — Plans don’t assume unsustainable pace AMB ability to achieve forecasts without resorting to unsustainable pace measures
Forecasting towards Sustainable Pace by inspecting sustainability of past pace
The last KR relates to the planning/forecasting approaches we use in agile. Agile approaches leverage empirical planning approaches. They look at the past (Yesterday’s weather) to try and forecast the future. Whether it is PI Planning, Sprint/Iteration planning. Whether by looking at Velocity, Throughput, or Cycle/Flow Times — most approaches tend to ignore how these past results were achieved when using them to predict future capacity.
For example, if our velocity in previous Sprints was 15–20 points, we will probably take on about 15–20 points. But what if these 15–20 points required a herculean effort that wasn’t sustainable?