People complain about bureaucracy almost every day. They say it’s too slow, there are too many sign-offs, too many handoffs, it’s anti-innovation, and it carries many negative connotations. That’s true. But the opposite is also true — when there’s no bureaucracy, people tend to complain just as much. They’ll say, “Why isn’t there a process here?” or “Why is no one reviewing the results of the work?” So if there’s too little bureaucracy, people complain, and if there’s too much bureaucracy, people complain as well.

The core problem with bureaucracy is, as Oscar Wilde put it, “Bureaucracy is expanding to meet the needs of the expanding bureaucracy.” It feeds on itself. You don’t want too little, you don’t want too much — you want just the right amount. But bureaucracy is self-reinforcing and self-feeding. It grows. Because of this, in Scrum@Scale we use the concept of MVB — Minimum Viable Bureaucracy. We want to keep bureaucracy in check because if we don’t, it will grow, overtake the system, and slow everything down.

Think about it — you probably have something in mind right now, some governmental bureaucracy or part of your organization where bureaucracy has gotten completely out of hand. MVB is just a concept, and a concept alone won’t change much, but it can serve as a counterweight. It raises awareness that bureaucracy tends to grow if left unchecked.

What I like to do with this concept is introduce it as early as possible. If there’s already a need or desire to increase bureaucratic structures, it’s usually too late. So I introduce it right at the beginning and say, “By the way, there’s this concept of Minimum Viable Bureaucracy, and it’s about keeping bureaucracy in check.” People usually nod and buy in because everyone knows bureaucracy is a pain and, in theory, nobody likes it. But once it starts to grow, people often want it to grow — for political interests or because they think there’s a real need. That’s why introducing the concept early is critical.

Once introduced, I’ll print it out, hang it in rooms, or display it at the beginning of PowerPoint presentations to keep it visible. Then there will come a moment when someone wants to add a meeting, an event, a check, or a process that could increase bureaucracy. That’s the moment to be alert and ask: “Is this really necessary, or are we just adding to the bureaucracy?”

Remember, in Scrum@Scale we want just as much bureaucracy as we need to survive — not less, because that leads to problems, but not more, because we don’t want bloat. It’s a lightweight concept, but extremely powerful. It helps keep bureaucracy in check, rein it in, and even remove excess bureaucracy when necessary.

If you want to learn more about MVB — Minimum Viable Bureaucracy — or other concepts from Scrum@Scale and Business Agility, head over to Team Flow. I teach regular seminars on these topics and would be happy to see you there.