Big Room Planning. Useful or necessary?

In any organization where multiple teams work together on a product or application landscape, there is a need for coordination. One team’s changes should not compromise the stability or operation of another team’s systems. Some features may require multiple teams to make changes to their code. You can of course leave this to chance, or you can trust the teams to do that coordination. You can also schedule an extensive integration test to check afterwards whether everything still works together.

You can also try to anticipate the problems and ‘force’ the teams to coordinate work and dependencies with each other in advance. A Big Room Planning is a great tool to achieve this.

The different scaling frameworks in the Agile field all have their own variant of a Big Room Planning with their own characteristics:

• SAFe has the PI Planning. It lasts two days and is with all teams of the Agile Release Train. Several sprints are then planned.
• In LeSS they use the term Sprint Planning 1 for the consultation with (representatives) of all teams. This happens again every sprint, but with good preparation it takes a maximum of two hours.
• Nexus has the Nexus Sprint Planning, which is comparable to what is done in LeSS. The teams each pick up a number of items from the overarching backlog and then work it out further in their own sprint planning.
• The Spotify model describes a more organic process in which dependencies between teams are continuously mapped and coordination is sought on that basis.

In the remainder of this article, I broadly follow the SAFe variant. SAFe is currently the most widely used scaling framework.

What do you need for a Big Room Planning?

So, it really seems like a good idea to arrange coordination with multiple teams, but do you need something special for that? What do you have to think about?

Basically, it’s not that complicated. If you know where you want to go with your product or applications and have documented it in a vision and roadmap, then you are well on your way. Then you can fill and prioritize the backlog, in which the work for the teams is gathered. In most cases this will be a central backlog ‘across the teams’ with perhaps somewhat larger items than on the backlogs of each individual team. The vision is what you want to eat, the roadmap is the recipe, and the backlog is the list of ingredients you need.

The second thing that is needed, in addition to the vision and roadmap, is reliable teams. You will make agreements with each other about who will do what and when. The plan and success of each team is partly dependent on another team. The joint success depends on all teams. In addition to the teams being able to trust each other, we expect each team to be mature enough to properly assess and plan their own work. Unfortunately, if the plan of one team is worth nothing, so is the shared plan… The chain is only as strong as its weakest link.

It is also important that teams work towards the common goal at about the same time. Otherwise, the work of one team is waiting and there is a great risk of rework because of course everything changes in the meantime.

As far as I’m concerned, these are the two most important ingredients for successful Big Room Planning. Of course, a few seasonings still need to be added, but it’s a sufficient basis to get started.

The Essence of Big Room Planning

The essence of the Big Room Planning is, of course, to divide the work that must be done in the next timebox among the different teams and to map out where the risks and dependencies are. It makes little difference to the concept whether that timebox contains one or more sprints. As mentioned before, I follow the SAFe approach here and that timebox is a PI that consists of a number of sprints.

The division of work largely depends on the nature of the teams. Are they feature teams that can implement new functionality almost independently or are there component and platform teams that will lead to many interdependencies? This topic, how to organize teams, is a challenge in many organizations that I would like to discuss in another article.

Good. The items on the central backlog will end up in smaller pieces on the backlogs of one team (in the case of feature teams) or multiple teams (in the case of component and platform teams) during the Big Room Planning. To make this completely transparent, each team presents their plan to the other teams to promote collectiveness. In addition, items often come to light that require further coordination.

The second output of the Big Room Planning is the ‘board of dependencies’. This board is a visualization of the elements and their sequence to yield the overall objectives at the end of the timebox:

Seasonings

I mentioned it before, a Big Room Planning also needs some seasonings. This applies to physical meetings, but certainly also to virtual meetings. We want everyone to be involved and there are several ways to make that happen.

The first category is (business) presentations. Be careful who you invite to do those because if those are boring and long-winded stories, it does more harm than good. A short and concise presentation about the vision, about the future of the company or about how good the previous release of the product has been and what it has done for the business, often creates pride and solidarity.

The second category is more team-building activities. Use some of the time to do the marshmallow challenge or work out a topic using LEGO^® SERIOUS PLAY^®. Or do a pub quiz at the end or just a drink. And if the meeting is virtual, you can do a scavenger hunt in which, for example, the assignment is to find foreign currency and show it to each other with a nice anecdote about the country of origin.

Finally

It may seem like a lot of hassle, such a Big Room Planning. And that is partly true, but that is no reason not to do it. Many variations are possible and there is enormous added value. In any case, it is useful. Whether it is also necessary depends on how things go without Big Room Planning. If there are no problems, then it might still be useful. But if the dependencies between teams continue to lead to problems, then it might be a dire necessity…

If you got interested and need some help, or if you want to discuss this in more detail, don’t hesitate to reach out to us!