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:
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?
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.
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:
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:
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.
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.
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.”
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.
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.
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?
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:
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.
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.
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.
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.
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.
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.
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”
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?”
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.
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:
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.
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.
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.
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.”
This article concludes the series about Scaled Planning, consisting of the following articles:
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.
Pragmatic Agile support aligning purpose and ways of working to anchor change.