Scaling Agile – Big Room Planning

In the first article, Scaling Agile - a real story, I shared a true scaling agile story from a particular program. In the second article Slicing and understanding together, I described how to slice your requirements into potential releasable epics. The third article about Master planning together gave you the steps and how tos of setting the direction for the entire program. And now, finally, we get to the big event – the big room planning.

Before we dig deeper, let’s get the context in place. I am explaining this as a part of scaled planning (you can skip this part, if you have already read the previous articles).

Scaled Planning

Scaled planning, including slicing and master planning, is a pragmatic approach to help you with your scaled planning challenges. Scaled planning uses the organization’s overall strategic objectives (the target in the middle of the illustration) as the starting point, and from there involves four levels of planning:

1. Slicing
2. Master planning
3. Big room planning
4. Sprint planning

While the various scaled frameworks provide a useful framework for the quarterly big room planning, where all teams and stakeholders get together for a couple of days, and while most organizations know how to do sprint planning, many struggle with getting 100% ready for the big room planning. This is where scaled planning with 1. slicing and 2. master planning comes in.

Why big room planning?

There’s a lot of skepticism out there about big room planning. The questions I hear over and over again are “Really? Is it necessary and worth it to have everyone spend two days every quarter to plan? And how can it even function with up to 100 people or more to plan together?”

Once you have tried it, you know the answer to those questions: yes, it works. Very well actually. And yes, it is worth it. I’ve seen this way of planning save programs from big time failure. Several times.

Let me give you a couple of examples.

The first is about the Mifid program that was in deep trouble delivering anything. Then they started to organize themselves differently and they also started to plan in a far more involving way than before. And now they’re back on track. This is the story in the first article Scaling Agile - a real story.

A more recent story is about a program I was consulting with recently, who is developing an app for its customers. The program consists of three teams: Digital, IT and Retail. The program has been working on this for around two years, and have, up until a few weeks ago, only delivered a two-week pilot with 50 customers.

When I started with the program a few months ago, I heard a lot of “but we do not know what they’re even thinking in Retail” – and “are any of the Digital people actually doing anything – I have no idea” – and “how come things take forever in IT – it’s just an app?”

After a couple of months and several master planning sessions with people from each of the teams, people finally stopped talking about all the reasons why we would never make it. They started talking about what it would take, and managed to slice and prioritize some epics, some potential releases.

The teams were still reluctant to prioritize time to talk to each other. They were busy with their own stuff. IT, who is building the app, wanted to stick to their Scrum processes, their sprint goals and not jeopardize their planned velocity. They had no interest in the content of the app, that Retail struggled with, and no interest in the design and the look and feel, that they called “glitter.” They saw these things as someone else’s job. They were building a car without a motor and without a way to get gasoline.

I managed to get them all together for a big room planning. Each of the teams broke down the epics into maximum two main tasks per team, per week. They also created a program board, and discussed the dependencies between tasks and people. Towards the end, someone from IT suggested to meet every morning at 9:15 to hear what the others were working on and to coordinate. Many people were thankful after the big room planning – they had a good time and said how great it was to finally have some meaningful conversations with people on the other teams.

Just two weeks after the big room planning, we were ready.  The app had been submitted to the App- and Play Stores and the customers were starting to download, use and benefit from the app.

So, back to the questions about big room planning: Is it worth it? Can it work?

YES.

One last argument: two days every quarter is 3.3% of people’s work time – no matter how many people you have in your program. So if big room planning gives you more than 3.3% more productivity in delivering value, then big room planning is a good investment.

Big room planning in short

Big room planning is two days of planning together with all program and team members every quarter.

Based on the master plan and the program goals, all teams are talking through how they each will contribute to reach the program goals during the next three months.

They do that by breaking down the epics from the master plan into features, discussing, estimating and prioritizing them and giving their best shot at how many features they can achieve each of the next four 2-week sprints.

Several times during the two days, teams gather by the program board and post and discuss their individual features. They discuss the overall picture, sort out the dependencies and move features around to build the best possible overall plan.

Towards the end of the two days, team and program objectives for the three months are agreed upon, and risks are discussed and mitigated.

Getting ready for the big room planning

As the “scaled planning” illustration shows, you need to get your slicing and your master planning right to get a successful big room planning.

Also – to get completely ready – you need a few more things:

• Agree on who will share and update everyone on the program vision.
• Agree on who will demonstrate the current state of the solution and the overall architecture.
• Talk to the program stakeholders, and make sure that you get the right people in the room. You want to have sufficient knowledge and mandate present at your big room planning.
• Have all the epics of the master plan – with estimates and priorities. I prefer to bring each epic on an A4/letter-size and post them on the wall, so everyone at all times can simply walk up to them and talk about them.
• Gauge the agile & Scrum maturity level of the teams – and arrange for facilitators accordingly.  The lower the maturity level, the more facilitators you need. Up to one facilitator for each team, if they are green on Agile, breaking down epics and estimating them using planning poker. I prefer to have external facilitators who are not a part of the program, and with substantial experience in scaling agile.
• Pack enough decks of planning poker, post-its, markers, red string for dependencies, tags, etc.

Getting the right room and set it up

While this is a part of the above “Getting ready for the big room planning”, the room is getting its own paragraph. The reason is that this is both very important and yet often not getting enough attention from organizers of big room planning sessions.

The physical setup can make or break the big room planning, so please take it seriously:

• Make sure to get a room that is big enough for everyone – and to hold one table for each team plus one table for the other program roles and stakeholders. My rule of thumb is to find a meeting room for the number of participants times two. One room, not two or more rooms close to each other, because the flow of communication between teams and people will suffer if you are not all in the same room.
• Set up the room – preferably the day before the big room planning. Get the tables organized. Hang up the master plan where everyone can see it. Get the team-planning posters up on the walls by the teams’ tables. Get the program board ready, and display relevant program posters – e.g., the program vision, the use case diagram, etc.
• The icing on the cake:
  • Show the start- and end-dates for each sprint on the program board, to make it extra clear that this has been decided up front, and to make it easier for everyone.
  • Get the teams to write the names of the product owner and the Scrum master on the program board to make it easier for all participants. There’s a lot to comprehend and remember; let's make these names not one of the things people have to remember.
  • Have name tags for all participants, to make it easier for people to remember each other’s names which also helps build relationships.

Running the big room planning

The morning of…

Finally, the big day has come. This is the morning of day 1, and you’re in the room at least one hour before the program starts. Maybe two hours, if you did not setup the room the day before.

I suggest doing a final briefing with your fellow facilitators and key stakeholders, who include the program leader, a program architecture responsible person, and business stakeholders (those representing the employees and/or customers, who will benefit from the product developed by the program), to run through the program and the roles one final time.

I also suggest assigning named facilitators to the teams, so each team is only/mainly getting support from one facilitator, so that the support and advice will be more consistent than if they get it from different facilitators.

Make sure that you finish this last-minute prep in time for you and the other facilitators to greet people when they get there and show them to their tables.

The introductions

Start by presenting the purpose and the agenda for the two days – something like this:

This above agenda is inspired by, but not identical to, the SAFe® PI Planning suggested agenda. Some of the above steps are fairly straight forward, and I will not go deep into those. Others are trickier, and I will share some tips for those steps:

1. Purpose

We’re here to make a plan for the next three months, where the program wants to achieve XYZ.

If this is one of the first big room plannings in the program, then I recommend making it clear that most things will probably go well, and that there will most likely also be some hiccups during the 2 days. And that you hope that everyone will be forgiving and see those as learning opportunities – something to improve for next time.

The XYZ is the helicopter view on what’s in the master plan for the next three months, not just the individual epics, but also the purpose and a brief description, the essence, of what is planned. So this is reminding everyone of “the big why”, which is the purpose of the program as a whole). And equally important, sharing “the smaller why”, which is the goal for the next three months.

2. Program vision

Present/remind people about the (updated?) program vision

Here we want to get a key business stakeholder to give a pep talk, to remind us about why we’re here. To explain why the program strategic objectives are (still) important for the business and for the company as a whole. Storytelling is better than Powerpoint for this, and even better if we can get the stakeholders to tell his own story about “why this is important to me personally.”

3. Solution & Architecture

Remind everyone how far we are with the solution, by giving a brief live demo of the actual product, or by having a visual overview over what has been delivered, and what  is still missing. Also repeat the architectural guidelines, and share the newest changes of the technical foundation.

4. Master plan

Have everyone get up, and “walk the master plan” together while explaining it. Spend most of the time on the next three months. Also cover the following quarters, just to remind people about what we’re not working on now – but spend less time on that.

5. Teams and epics

Which teams have stakes in which epics

The best way to explain this is by repeating a small part of the first article in this series “Scaling Agile – a real story.” We enter the story at the 2nd big room planning, where we’re trying a different approach than at the first big room planning, where each team chose the epics they thought belonged to them, with little or no discussion with the other teams about it.

“Then the teams gathered around the epic overview board, and this time we asked them to think about all the epics in which they played a role, even if it was a small role. We then got everyone to put a small colored sticky note representing their team on those epics (see illustration Epics & teams II). After one hour, we had an overview of which teams were primary drivers on which epics – and which other teams were also involved in each epic.

It surprised us how powerful this was. There were a lot of people standing by this board, coming and going throughout the two days, and it was usually people from different teams having a discussion about what they needed from each other. How they could help each other?

6. Team breakout intro

Explaining the specifics of the teams breaking down epics into features, and estimating and prioritizing them

Reminding people about the remaining agenda for the two days, and presenting all the details of the process. I usually include things like:

1. For each team – who will be your main facilitator
2. Have each team get an overview of the team’s capacity for each of the next five sprints. An example: you have a team with six people including the Scrum master and the product owner. One person has one week vacation during the 2-week sprint. Each person counts 4 points per full week. So, on this team, the capacity for this sprint is 5x8 + 1x4 = 44. Get the teams to write this on their team sprint posters and on the program board. A couple of comments:
   1. If this is one of the program’s first big room plannings, then I usually get all teams to do only this step, and share their team capacities with the other teams.
   2. Why not five points per person per week? History has proven, that people have always been too optimistic when we’re planning. Counting only four points per week (sort of equivalent to four days per week) is a mechanism to make up for the optimism.
   3. Why include the Scrum master and the product owner in the capacity? Because building a product is far from only “putting it together,” e.g., writing and testing the code in software programs. It also includes a substantial amount of business discussions, decisions, coordinating etc. In other words, the work of the Scrum master and the product owner.
3. Next, explain how we want teams to break down their epics in 3-5 features per epic (with fewer features you’re only scratching the surface – with more, it is impossible to get the overview at the program level).
4. We want the features on Post-its. For each feature, ask for a short name, a description, a reference to the epic and an estimate. See Validate pincode example.
5. When the estimation starts, start by finding a feature, that can be achieved by one person in one week or by two people in 2.5 days. Give it a 5, and estimate other features relative to that.
6. Other than that, the teams can just go ahead and break down into features – just like they would break down into stories in a Scrum sprint planning session.
7. Repeat that teams with regular intervals will be asked to share the results of their planning with the other teams by the program board.

7. Team breakout

Simply let people follow the instructions from the Team breakout intro. Make sure, that the teams get the right amount of attention from the stakeholders and facilitators. Not too much to disturb them, and also enough to give them the guidance they need.

8. Program board

Teams post their initial plans on the program board and start coordinating with other teams

Give teams a 15 to 20-minute warning before the first gathering at the program board. Ask them to write a Post-it for each of their features, but for the program board without the description in order to create a cleaner and better overview.

When the time is up, get everyone up by the program board, and get one from each team (probably the Scrum master or the product owner) to place their features in the sprints where the team thinks it belongs.

You might need to encourage a discussion about dependencies between the teams and features, but chances are that the teams will start discussing this without your help, when they have it in front of them.

Help visualize the dependencies by connecting features that are dependent on each other with red string. Encourage teams to finish discussions about dependencies on the side once the dependencies have been identified, unless it is a dependency that involves all teams.

A tip: have the first gathering by the program board earlier rather than later- no later than a couple of hours after the first team breakout starts. You will probably get some resistance from the teams, because they do not feel ready yet. If you wait too long, you will not get the cross-team collaboration you get if you do it early. It is amazing to see how teams are cross-pollinating a lot more after the first program board gathering.

9. Repeat

Team breakout and program board discussions are repeated – typically 1-2 times before the final program board gathering. Remember to gently force them to meet by the program board every 1-2 hours – even when they’re not feeling ready in the individual teams. It will nudge them to collaborate and coordinate more across teams.

10. Team breakout

Continued from day 1, while teams are encouraged to coordinate with other teams and stakeholders

After this team breakout, you should start to see the outline of plans for each team.  If they have not put their features up on the team planning posters yet, now is a good time to get them to do that. It makes it easier for the teams to understand what the other teams are planning, when they visit each other.

11. Program board

Finalizing the program board with all teams’ features and dependencies. Remember that the plan just needs to be good enough. It will be revisited every day, and details will be sorted out later.

12. Risks

Teams are bringing up risks, and they are discussed and mitigated in the plenum. Some risks result in a mitigation activity, which we want to go on a team’s plan and/or on the program board, so we do not just talk about it, but actually do something about it. Other risks are just accepted. Spend most of the time on the top 3-5 risks, and just list the others for now.

13. Program objectives

Teams formulate their essential business objectives and then the program objectives for the 3 months are agreed upon.

In a program with many teams, opinions, epics and features, people often need help to navigate and remember what the overall purpose is.

To help with the navigation we get teams, guided by the product owner, to describe a few overall goals for the three months. Then we ask the product owners to get together with the business stakeholder(s) to discuss and agree on a few program objectives for the three months. The fewer and shorter the objectives are, the stronger they are in order to help the entire program navigate towards a common goal.

Here’s an example of a program objective from a program, that really struggled to go live:

“Run on live data”

14. Confidence vote

On a scale from 1-5 – how much does each team believe in their plans

As a final test, we can get the Scrum masters for each team to ask the team members about how much they believe in their team’s plan, and possibly also how much they believe in the plan for the entire program, by a show of fingers up to 5.

I suggest that you only do this if you follow up with a discussion about why the numbers are not higher, and most importantly, how the plans or circumstances can be changed, so that people can believe more in the plans. A good question is: “What would it take to get you closer to a 5?”

15. Next steps

Usually the next step is for the teams to make a sprint planning, and then get going on the work.. Also talk about which other things will happen in the near future, and remember to thank everyone for their time and corporation.

16. Keep & try

Reflecting over the two days of the big room planning

Remember the opening comment about potential hick-ups during the big room planning?

This is where you gather input for how to make it better next time. My personal favorite is asking people to write the following on a Post-it:

• A number from 1-5 (5 is best) for what they thought about the two days
• One thing to keep for next time
• One thing to try to do different next time

Get people to put them on the door on the way out. Take a picture when everyone has left – maybe read them, but wait until you prepare your next big room planning before you think much more about it. At this point in time, after two days of big room planning, your brain is probably fried, not able to reflect rationally anyway.

After the big room planning

If you want to harvest the benefits of the big room planning and keep up the good cross-team collaboration, then I suggest that you have a Scrum-of-Scrums by the program boards every day after the teams’ standup meetings.

The agenda is the same as the standup meetings, except at the Scrum-of-Scrum the sharing is for each team rather than each team member.

As the facilitator or program leader, you might want to end each Scrum-of-Scrum meeting with one of my favorite questions:

What can I or others do to help you achieve our program objectives faster?

But only ask that question if you’re willing to gather those impediments and get them out of the way. I like to refer to this as impediment busting, because it sounds more cool and powerful than stakeholder management and risk mitigation.

Conclusions

Big room planning provides an overview of all the work to be done in the next quarter. It’s two days of planning together with all program and team members every three months.

Ensuring there is a common understanding of the overall direction using a master plan is a must in order to realize the goals of the big room planning.

Facilitation plays an extraordinary role in the success of the planning. Make sure you have skilled facilitators and a room that is large enough to hold people, tables, planning boards and all the materials needed to make the plans and dependencies visible.

Finally, as with any agile practice, pausing to reflect on what went well and what to improve in the next big room planning is invaluable.

Call to action

Next time you find yourself in a program with more than 2-3 teams, try this out. Set a date for a master planning and a big room planning a few weeks ahead, and then invite people and start getting ready. Set it up as an experiment, if there’s too much resistance.

And if you have already tried a big room planning and been disappointed, give it one more chance. If you follow the tips of this and the other articles in the series, I am sure that you will have a better experience next time.

Maybe you will even end up like Martin, a program leader on a CRM program in a bank I am working with at the moment. After a master planning and a big room planning that we ran the last couple of weeks, he said “I am in love with scaled planning. Before we were wasting millions supporting processes that the business didn’t care about. And we didn’t even know. Now we are aligned and creating value for our customers again.”

And then he added “We should have done this sooner.”

The series

This article concludes the series about Scaled Planning, consisting of the following articles:

1. Scaling Agile – A Real Story
2. Scaling Agile – Slice and Understand Together
3. Scaling Agile – Master Planning Together
4. Scaling Agile – Big Room Planning

I hope that you will share your thoughts about these articles, try out the tips and tricks – and finally, that you will let us know how it goes.

About the Author

Ole Jepsen is an Agile transformation advisor working with organizations looking to lead change. Using his expertise in Agile methodologies, Intent-based Leadership™ and facilitation, Jepsen works with companies and leaders to create development organizations and workspaces where people thrive and deliver value.