Companies transforming alongside new digital disruptors are often talking about minimum viable products (or, better yet, minimum lovable products). But there’s one more “minimum viable” category that these agile businesses should be considering—minimum viable bureaucracy (MVB).

Bureaucracy tends to have a very negative connotation, especially in agile companies that are more free-flowing than traditional enterprises. However, Mozilla and Spotify have made MVB a popular approach in agile businesses, giving executives an answer to the ever-present question—how do we maintain efficiency and consistency at scale without hindering creativity?

It’s easy to theorize about implementing MVB, but practical implementation is much more challenging. The following insights into real-world MVB implementation should provide a clearer path toward balancing agility and governance.

High-Level Steps to Planning for Minimum Viable Bureaucracy

Most projects have idiosyncrasies, and adding an agile approach makes company-wide bureaucratic management planning that involves longer horizons even harder. The right set of planning tools can be hard to pin down - and visualizing how your company operates is your first step to help.

To do this, visualize the company in terms of thick slices—one from a project perspective and the other from a knowledge transfer perspective. The project slice offers granular information such as which teams are involved (from sales all the way through execution) and the individuals working on specific projects.

Our End to End Guide to Product Development

The knowledge transfer slice of the business shows how teams and individuals interact throughout a project. As you scale, you won’t be able to communicate the same way with 60 team members on a project as you did when there were only 10. Visualizing this slice of the business can help you identify current and future bottlenecks in both quality and quantity.

Tool_Map-1.png2016 Knowledge Transfer Map: Larger circles mean more frequent connections, more circles mean more channels for connections.  
Data collected from minimal employee survey (n=5).

When you’ve identified trends in the project and organizational sides of the business, you can start thinking about how to implement minimum bureaucratic processes. But this is where you have to be careful not to create additional tension between governance and agility.

Minimum Viable Bureaucracy Calls for Guidelines, Not Doctrines

Bureaucracy could be seen in a more positive way if it is not implemented in a doctrinal fashion. With MVB, you want to focus on heuristics, enabling employees by minimizing requirements to only those that add value to projects.

In fact, you can even get an idea of how valuable your bureaucracy is by evaluating its benefits and costs.  Like MVB, you want to minimize the following equation (minimize effort while maximizing benefit).

MVB-eq.png

where
N: the number of people who are required to take action.  The fewer people required, the better.
F: how frequently they need to take action to keep this request current.  The less often this needs to happen, the better.
E: how much effort each person needs to fulfil this request.  Faster is better.
B: the value the business will gain from this request.  Try hard to put an honest value here.
D: the duration that this business value will last.  Is this something that lasts?

Think of this in terms of bike racing. All extra weight on the bicycle should be minimized, but weight on the moving parts like the wheels is even more important to reduce because it’s harder to start and keep moving. Your project teams are the same way—the more pressure you put on employees with bureaucracy, the harder it is for them to keep the project moving.

Practical MVB means you have a minimal, precise reason for each individual process requirement. We’ve created a simple scorecard to help point to places with too much effort relative to their costs.

MVB_Scorecard-01.png

3 Time-Step Examples of Practical Minimum Viable Bureaucracy

Scaling your agile business requires you to take a step back and assess how to maintain quick decision-making while delivering against growth in your company, your number of employees, and the size of your clients. This scaling process should be repeated annually as tools and teams shift and change.

To help you visualize the results of MVB implementation, here are 3 incremental examples of how minimal bureaucracy fits into agile project management:

  1. MVB on a 10-Minute Level: Part of agile project management is the daily standup. However, as projects grow larger and larger, these standups often devolve into anti-patterns where people are talking about project-related topics but aren’t actually providing any value. Using chatbots to automate simple discussions such as daily tasks can keep standups lean and focused on problems that have to be addressed. This can free the team to focus on clearing blockers while also providing a basic written project history.  Using technology to clear up bureaucratic problems even in this 10-minute situation can lead to valuable efficiency improvements.
  2. MVB on a Weekly Level: Consider the processes involved in your weekly project status updates. When there weren’t many projects or team members, a simple Word document may have sufficed for status updates. However, scaling this process can result in multiple weekly meetings just to find out that projects are progressing as expected. Cut out the non-actionable pieces of your status updates and focus specifically on what needs to get done, when it needs to be done by, and who needs to do it. Striving for actionable updates will minimize the amount of time spent in meetings while also improving the value of those meetings.  As your processes are refined, consider automating portions of the outcomes such as action item notifications.
  3. MVB on a Long-Term Level: At this stage, you’re looking at the best way to use MVB in  structuring how your projects and company should be governed and operated in the long term. There are many ways to do this, but we’ve created a bucket system where we separate all projects into Tier 1 and Tier 2 based on variables such as estimated project complexity, project timeframe, teams involved in the project, and more. Each project is rated according to each variable and sorted into its appropriate bucket. Using a RACI approach to responsibility and accountability, we can determine critical success factors for each role needed on a project. These are the general MVB guidelines we’ve come up with to ensure we stay on top of all project requirements and maintain consistent knowledge transfers through execution.

Scaling Your Business Up Means Scaling Bureaucracy Back

Traditional companies have a tendency to scale their agile businesses and bureaucracy alongside one another to maintain a sense of control over their growing teams. However, smart employees will always find ways to game the system if they feel bureaucratic management is standing in the way of a project’s success.

Scaling agility requires a shift from direct relationships between business and bureaucracy to indirect relationships. You should be minimizing your bureaucracy so that there are only as many requirements in place as necessary, maximizing project team creativity and productivity in the process.

 

If you want to learn more about the end-to-end product development process and how to manage it, download our free guide to new product development processes.

Editors note: Updated 09/27/2016 with 2016 Knowledge Transfer Map image

Editors note: Updated 04/24/2017 with Slideshare

Our End to End Guide to Product Development

Click to Comment