Paying the predictability tax.

February 24, 2019. Filed under management 127

The core observations from Fred Brook's The Mythical Man Month is that assigning more folks to work on a project often slows delivery:

Men and months are interchangeable commodities only when a task can be partioned among many workers with no communication among them... when a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.

As I've been rethinking our approach to planning, one particularly interesting aspect of Brooks' communication cost is that larger teams require the prioritization of predictability over throughput.

While in the best case, good architecture will minimize dependencies, it's neither possible nor advisable to eliminate all dependencies, because all leveraged work creates dependencies, and you do want to be doing leveraged work to run a productive organzation.

The more teams involved in creating a plan, the more conservative you have to be with each component's delivery dates, to minimize uncertainty introduced in the overall timeline. One team self-coordinating can take advantage of all of their productivity, e.g. operate at "p100" productivity. If there are two teams with heavy cross-dependencies and somewhat flexible timelines, then perhaps you can operate at "p80 productivity."

As you add more and more teams, you quickly reach a place where predictability means you can rely on your "p50 productivity" at best.

Predictabiltiy tax is lost p95 productivity.

The difference between your team's actual productivity and the productivity it's able to demonstrate with required predictability is your team's predictabilty tax.

While this predictability tax manifests in many ways, one good example of how emphasizing predictability shifts behavior is team planning process:

  • Kanban focuses exclusively on maximizing throughput, with work-in-progress limits generating back pressure to drive a cycle of virtuous team/process/system improvement.
  • Agile focuses on focuses several week sprints, and adapts to new information rapidly at the end of each sprint.
  • Waterfall focuses on defining the end state and then reasoning backwards to identify the necessary milestones to reach that target.

Almost no company acknowledges using a waterfall-style planning methodology, but almost every company approaches cross-team planning with a waterfall-based mental model of commitments and coordination in order to hit their predictability requirements.

This means they spend less time optimizng their approach to delivery or optimizing their product decisions, with that potential energy shifting to optimizing timelines.

There's no quick fix for coordination. Your four best tools are good technical architecture, good organizational design, good process design, and remembering to pay attention.