Scrum@Scale Case Study

Summary

When was the last time you looked at an org chart and saw a visible symbol for collaboration? There’s a very good chance you never have. The series of rectangles or boxes connected with lines symbolize both hierarchy and firewalls. When an organization is large enough to add columns to its org chart, silos are created. Each division effectively quarantines themselves from other parts of the organization. Coordination and cooperation invariably suffer.

In these kinds of organizations, middle and upper-middle managers become the gatekeepers and go-betweens. Positions which more often than not lead not to results but delays.

Scrum@Scale can transition this management tier back to what it should be doing: providing key information to leadership and clear guidance to production teams.

I helped guide a large manufacturing organization through just such a transformation.

The Old Org Way

This manufacturer had that classic structure for its org chart.

The chief information officer (CIO) is on top of this particular branch. They have a series of vice presidents as direct reports. Each, in turn, has a series of departmental directors reporting to them.

Each vice president representing the head of a very siloed department. Firewalls kept coordination to a minimum. Communication was often incomplete.

Vice presidents complained they did not have enough of a detailed knowledge of either projects or process or how they needed to interact to achieve results.

Step one in this agile transformation was launching a MetaScrum.

Gaining Focus

Our first MetaScrum was comprised of middle managers including directors of groups like financial modeling, quality, engineering test, diagnostics, product lifecycle management and others.

Given the positions of the managers involved this would technically be a Meta MetaScrum – meaning there were still layers of management above and below. Still, this group was comprised of key middle and upper middle managers.

We began by having them create lean canvases and roadmaps for each of their products.

The MetaScrum identified some 2,000 products they had a hand in, a number which was shockingly high. That worked out to two products per employee.

Making matters worse was the number of products which represented work duplicated in different organizational silos.

The MetaScrum soon realized just 10-percent of these products were actually being used.

Only these products would continue to exist. Freed of the waste which was bogging them down, and armed with a better understanding of the products and how they worked together, new mission-based teams were created. Other product based MetaScrums were spawned.

Long Term Results

The Meta MetaScrum met for a few hours every Monday. This cadence allowed them to regularly identify what their priorities were and what priorities needed to change. They also began to understand and deal with interdependencies which were hampering production.

And, having already eliminated a large amount of wasted effort on products which were never used, they identified items, code, and processes that could be reused and repurposed by other teams.

To be clear, this is no by the book transformation. Scrum@Scale suggests keeping the number of people in a MetaScrums to around five. This MetaScrum was much, much larger than that.

And yes, sometimes you do have to go bigger than the manual would like. But as the organization becomes more T-shaped as a whole, and the product owner loop is built out, this larger than prescribed MetaScrum can be split into smaller, more effective groups.