Whole-Company Big Room Planning Is Probably Making Things Worse

(This story is an expansion of one I’ve already written. You can find it here: Big Room Planning is an Organisational Smell)

So, after years of hearing about how much better things would be if you adopted agile, you’ve decided to do it. After significant consideration, you choose to start Big Room Planning (BRP). It’s a decision you did not take lightly, and you hope that the expense of getting every person in the company into a room for 2 days, every 3 months is worth both the salary and opportunity cost.

I get it. Really. It’s awe-inspiring to have everybody working together to deliver a plan. The first couple of BRP events I went to were overwhelming. It felt dymanic, efficient, and like we were really making progress. As an exec, you can see the work that everybody is putting in, and you get to hear what everybody plans to do after they leave the room. It’s both amazing to experience, and completely counterproductive.

To understand why, it’s important that we understand some of how BRP came about.

Agile teams are small. Effective agile teams tend to be anywhere from 4–10 people (familiar with the Amazon 2 pizza rule?). They are independent, make effective decisions, work directly with customers, and churn out high quality software that just works and does what the customer needs (actual experience may vary).

At some point in the past, some folks looked at effective agile teams and thought to themselves, “Wouldn’t it be great if we could scale that? Some of our work is too complex for 1 team, and so things need to be coordinated across teams.” So they came up with a variety of ways to orchestrate things across interdependent teams. These are still small teams, mostly functioning independently, but now they have a method of working with teams they depend on, or which depend on them, so that together they can all deliver something bigger than they could on their own.

This process works really well, if your organisation is set up for it. For example, if you have 3 teams that have a few mutual dependencies, sometimes it helps to have them work together, rather than remove the dependencies. Maybe you have 5 teams that are coordinating to deliver something together. Perhaps there are teams outside of development that need to be involved, so a release, and the training and documentation, all go out together. There are several good reasons for coordination at this level. And it involves (still relatively) small numbers of people working together.

Some time after this was shown to be effective (under the right circumstances), it was documented and became a process that just about anybody could implement. That means that even if you don’t have agile teams, and even if the teams you do have are interdependent in ways nobody really understands, there’s nothing stopping you from adopting the BRP process.

This is a problem. Since BRP was largely invented so that teams that are working together can more effectively deliver a single thing, it assumes that everybody understands the dependencies that make collaboration necessary. Those dependencies aren’t going anywhere, because the dependencies are the reason BRP was the right solution. Understanding those dependencies, and subordinating everything to those dependencies comes easily. However, in organisations that don’t have agile teams, everything is often interconnected. Each team works on a piece of something, which depends on something else, which depends on something else, which 3 other things depend on, etc. Everything depends on something else. This is especially true in organisations that have significant amounts of legacy systems that they’ve never addressed or broken down.

Because of all these connections, there are a number of teams that are considered critical for the success of a project (such as a database team, support team, governance, etc). These teams are often critical for the success of other projects. Often, they’re critical for the success of every project.

When organisations start their path to agile with BRP, they often start with a single group. Sometimes they call it a value stream, sometimes it’s just a collection of teams. And they pull in the various different areas that are necessary for that group to deliver. This often means pulling teams from across the organisation. After a few months, they decide to take the next step. Despite the teething pains of their current approach, they decide to expand their efforts. They decide to commit to getting everybody following this new process. So far, so good. Suboptimal, but doable.

When they go to expand the number of teams doing BRP, they first look at having separate BRP sessions for the different groups. But when they look at which teams have to be involved in the new session, there’s significant overlap with the old session. Lots of work depends on the same teams. So instead of having those teams in multiple different BRP sessions, they combine them. It’s more efficient that way. A few months later, they bring in another group. It has the same problem, which gets solved in the same way — by combining BRP sessions. Over time, this process encompasses the entire organisation.

Now the entire organisation is planning in a single session. And it has to, because everything is interdependent. If you’ve read the story I linked at the beginning, you’ll probably have an idea of what the problem is. In order for BRP to be effective, it has to have a small number of dependencies and mostly independent teams. But organisations which haven’t gone through the process of breaking down dependencies and removing them don’t have mostly independent teams. When everything depends on everything else, it becomes very difficult, even impossible, to map or understand it.

Remembering that dependencies are the only reason to adopt BRP, we now find ourselves in the position of having adopted a process and lost the value. A process that only works when there are small numbers of dependencies has been adopted under wholly inappropriate circumstances. The end result is that things get worse — they slow down, bottlenecks appear to be everywhere, people end up competing to get a small number of teams to do the work that’s important to them. This creates inordinate stress for those teams, who are put under significant pressure to satisfy everybody.

Small numbers of dependencies can be managed. The same thing doesn’t work at whole-company scale. On a small scale, managing dependencies is sensible. When it comes to hundreds, or thousands of dependencies, something should change. But because BRP suggests managing dependencies, that’s what people do. Removing the dependencies would be costly, time-consuming, and doesn’t align with strategy or funding objectives. So they get managed. Managing thousands of dependencies is impossible — it’s too big, too complicated, and too slow. So everybody ends up unhappy. And the BRP process becomes embedded, while at the same time, bypassing it becomes necessary to make progress. Congratulations, you have now successfully implemented whole-company BRP. This is about as good as you can expect it to get.

Because from now on, it’s likely to get worse. Due to the the overhead of planning, including preparing for planning, cleaning up after planning, re-planning when the plan gets derailed, working around the plan, explaining why the plan didn’t happen, etc., less actually gets done. A whole new process has been introduced, and its greatest impact is to slow things down.

Whole-company BRP is undertaken with good intentions, but it’s doomed from the start. BRP wasn’t created in order to coordinate entire organisations that have significant interdependencies. That’s not its purpose. If you are determined to do BRP (and there’s a few good use cases, including the one from the previous article), it’s important that both the work to create independent teams / groups has been done, and that it’s done for small groups within the organisation, and not the entire organisation. It all comes back to the same thing, in the end — remove dependencies if you want to go faster.