Scaling Improvement

The pattern for scaling improvement is remarkably simple:

*How to scale improvement: contribute help at the biggest nearby bottleneck*

Whatever level of an organization you are at, use some of your surplus slack (generated from a virtuous cycle of improvement) to help out where it’s most needed! On the other hand, if your team is at the local bottleneck — and hence you’re not in a position to help others — ask others to help you.

Management can play a critical role in this process in large organizations: by setting up and protecting improvement cycles, sense-making at larger scales, coordinating the flow of surplus slack, and initiating policy change and de-scaling and restructuring over time to reduce communication overheads: de-siloing the organization or making it more fluid to support the nature of the work (rather than to preserve fiefdoms).

Identifying the biggest local bottleneck requires sense-making and measurement: e.g. mapping as much of the local value-stream as possible. Non-technical bottlenecks (e.g. a low trust culture) require other forms of sense-making to identify, usually talking to people. This sense-making is a critically important job for management, especially at the higher levels.

If you understand where the biggest local bottleneck is within your sphere of influence, you can help direct improvement focus and local slack towards it. E.g. When a lower-level team reports that they have succeeded in making local improvements and have some extra slack available, you will be in a position to point them in the right direction:

Can you please help this other team — who are struggling at our most grievous bottleneck — by either sharing some of your learnings or taking over some of their workload
Alternatively, if all the teams in your purview are running smoothly, either offer support at the next level up, or to a neighbouring unit who you know are struggling

Another possibility is that the offer of help may come from above. “Your group are the bottleneck from our perspective. We need more from you, and can offer help.” Because you know where your major internal pain point is thanks to ongoing sense-making you will be able to explain what kind of help would be most valuable, and to direct it where it’s needed once you get it.

may be that a team with surplus slack who is directed to help another team may be directed down the organization to tree to zoom in on where the help is really needed.

Relation to the Theory of Constraints

This approach is essentially a distributed version of Eliyahu Goldratt’s Theory of Constraints, extending it to the situation where we do not have a view of the entire value stream. (It similarly generalises Lean.)

“Since the strength of the chain is determined by the weakest link, the first step to improve an organization must be to identify the weakest link.”
Eliyahu Goldratt

Where Goldratt prescribes understanding the whole value stream first (excellent advice), but the organization is too large and complex, I ask that everyone try to understand as much of their local patch as possible, and then exploit communication and overlap between patches to channel surplus slack to where it’s most needed.

The remarkable aspect of this approach is that it performs a double optimization:

Improving productivity and flow
Increasing staff morale

But wait there’s more! This approach also helps identify generous system thinkers: such people should be rewarded and retained.

Relationship to Scaled Agile

The Theory of Constraints and Lean struggle without a complete end-to-end view of the value stream, Scaled Agile approaches lack sufficient focus on systemic bottlenecks.

Applying the above scaling pattern corrects this limitation and opens up the possibility of dropping much of the complexity of Agile scaling frameworks: instead apply team-level Agile patterns at all organizational levels, and complement them with the scaling pattern and Prager’s Law.

Conclusion

The above scaling pattern is simple, but not easy. The first obstacle is setting up virtuous cycles of improvement at the team level. If you cannot do this is, there will be little improvement to scale.

Beyond asking executives, managers, stakeholders, and knowledge workers to shift their mindset from working harder to working smarter, the scaling pattern demands more sense-making and dynamic collaboration was common in the recent past. For people who succeeded under the industrial paradigm, this represents a major change. Unlearning as well as learning will be needed.

Nevertheless, I believe it paints a fundamentally optimistic outlook: our future success lies in helping others by sharing workload and improvements (and rewards) to make things simpler and easier. Not just for our customers, shareholders, and bosses, but also for our colleagues and ourselves.

Scaling Improvement

Relation to the Theory of Constraints

Relationship to Scaled Agile

Conclusion

Further reading

Share this:

Like this: