Multi-team planning, a key practice in agility at scale 

In this article, I'll look at the subject of planning the work to be done. In particular, we'll look at planning for the medium term (a few months). I'll share a very interesting planning practice in a multi-team agile framework, also known as "agile at scale". 

Planning is a practice that I see little implemented in the contexts to which I contribute. These contexts may or may not be agile, at scale or not. There are several reasons for this. 

Why skip planning? 

• Good planning takes time. At the very least, you need the time to identify, even roughly, the projects you want to visualize in your schedule. You also need to see the added value of each project, as well as the estimated effort required to complete it. Many teams don't take the time to do this. 
• Good planning requires, ideally, the right tool. I'm not saying it's a prerequisite; on the other hand, it's a considerable asset. For example, if you don't have the right tool, you may find yourself double-entering your backlog and your schedule. The exercise quickly becomes uninspiring, as well as a source of errors. 
• Some teams don't see the point of planning. A schedule drawn up at a given moment will be constantly changing, and will not remain static. This raises the question of the relevance of building a "deliverable" that will be wrong, at least in part, the next moment. All the more so if the tool used (see above) makes this difficult. 
• The most widespread agile approach to date, Scrum, does not impose planning practices in the traditional sense of the term. It doesn't give advice on how to implement it. Sprint planning does exist, but it remains a very short-term planning exercise. And we don't identify different time horizons for each activity involved in the sprint. 

I have no particular problem with teams that don't carry out medium-term planning. A clear product vision, to which we often refer when scheduling our work, is worth a thousand schedules. In particular, those drawn up without in-depth thought, and without consultation with the stakeholders or those who will be doing the work. 

Planning consumes time and energy. If this investment brings no added value, then, in aLean approach, it's a practice that needs either to be adapted (to make it value-bearing), or eliminated. 

Planning is a rich learning exercise 

However, I think the exercise is very interesting, and should add value in more ways than one. 

• As mentioned above, planning involves asking a number of questions, even if only briefly. First of all, the question of WHAT (which sites). Then the HOW (to get a rough idea of the effort involved) and finally, the WHEN. This means you can't sail by sight. But it does help to keep a medium- or even long-term vision. 

• As a corollary, a clear roadmap is a formidable tool for uniting teams. Knowing what you're aiming for, and by when, helps employees stay aligned towards the same goal, with the same priorities. 
• It's also a great tool for keeping customers and users engaged. Knowing that a much-awaited feature will be delivered in^Q3 2023 makes the wait more acceptable than if we had no information at all. It also encourages us to communicate realistic deadlines. No customer wants to be "pushed around", only to be told every month "well, it'll be next month". 

So when I visit a team or a company that is able to give visibility to its roadmap, as GitHub(see the public roadmap here) or Microsoft(see the Microsoft 365 roadmap here) do, I find it really positive. Provided, of course, that the roadmap isn't completely fanciful when you look back on it. 

The pitfalls of planning, whether or not you're in a scaled agile mode

However, it is vital not to fall into certain traps. 

• Planning can be a complex activity. Especially when we're trying to take into account the schedules of other people, teams or even companies (publishers, subcontractors...). As such, I don't recommend presenting medium-term or even short-term planning as a firm commitment. 
• Even if you don't have any dependencies on other teams or contacts, it's important to remember that planning is still an exercise in prediction.Like any prediction, it can be wrong! An unforeseen absence, the unavailability of a department, an incident that has to be resolved before anything else... and our schedule becomes untenable. Once again, I don't recommend presenting medium-term or even short-term planning as a firm commitment. 
• Planning in too much detail is a waste of time and often doesn't yield much useful information. There's no point in trying to plan the activity of every member of your team to the nearest half-day, or even to the nearest quarter-day. Your planning will be wrong 95% of the time, and so will your indicators(we talked about this here in our series on measuring agility). You'll spend just as much time reworking it, because of the sheer number of activities and people you're trying to get under control. 
• Planning too far in advance is also a waste of time. Even a team or organization with a clear vision and strategy may, at some point, choose to pivot. This is a form of agility, rather than stubbornly following a road to nowhere. Planning three, five or ten years ahead, in most contexts, proves to be neither possible nor useful. 

• Finally, planning is a team exercise. The people who are going to carry out the work must contribute to the construction of the roadmap. They must not simply be given a fixed scope and a fixed deadline. It is not possible to ask a team to commit to a plan drawn up by a limited number of people, disregarding the group's opinion. 

A practice to be experimented with in multi-team mode: "scaled" planning 

At a time when more and more large organizations are trying to embrace agile concepts, I'd like to highlight a practice that I find excellent in terms of multi-team collaboration for planning purposes. 

This involves the construction of what SAFe calls the "Planning Board" (or, until recently, Program Board). Ultimately, this is a large board enabling different teams working together to carry out joint planning. This enables them to visualize the dependencies between them (which, I would remind you, should be reduced to a strict minimum, notably by organization into cross-functional, autonomous teams). 

This is medium-term planning (a few months), which is a good level of granularity in most of the contexts I've come across. In the SAFe vision of this table, which I personally find very practical and clear, information is structured as follows: 

• The first line is a reminder of the main milestones you need to be aware of over the next few months. These may be important events from a business point of view (trade shows, seminars, launch date of a new offer...). They can also be technical (end of support date, etc.). It can also be regulatory (implementation of new legislation affecting us, for example). Clarifying this information for everyone gives all teams the means to make informed choices, particularly in terms of scheduling activities. 
• The following lines correspond to each team involved in joint planning. Each team will place here the work it plans to do over the coming months, staggered over time. 
• The bottom lines (here "Needs UX help" and "Needs Sys Arch Help") correspond to external contributors who are not part of the teams and intervene on an ad hoc basis. They may be involved in, or in charge of, some of the work that needs to be done to enable the teams to move forward. 

• Each column corresponds to a fixed period (timebox). This can be sprints for teams working in Scrum. For teams not working with Scrum or SAFe, it could be months or quarters. It all depends on the level of granularity required. 

At each intersection between a row and a column, each team will position the topics it plans to deliver over the given period. Remember the pitfalls outlined above. The aim is not to fall into the trap of fine control, but to give visibility on what's to come. It is therefore unnecessary, and not recommended, to break down activities too finely. They can remain at the "features" level, if we use the SAFe vocabulary. 

These are the blue and red rectangles in the previous image. The difference between the two is that the blue subjects are not dependent on any other subject. 

Any dependencies between subjects will be marked on the table. These are the red curves linking some of the previously positioned elements. This visualization makes it possible toquickly identify the sticking points between different teams. It should enable you to ask yourself the right questions. 

For example, is it really relevant for Team B to plan its subject for the month of April, when it depends on a subject from Team A, also scheduled for delivery in April?

Isn't there a risk in doing so? How can we eliminate this risk?

This usually involves communication between the teams, led by the Product Owners, in order to solve this headache, notably by modifying the prioritization of subjects in one, the other, or both teams. 

In the context of agility at scale, the fact of carrying out this planning exercise all together, with the players from the different teams working together, is an enormous time-saver. It allows decisions to be taken very quickly, without endless exchanges of e-mails or "instant" messages. And it facilitates communication and collaboration. This is the practice of "Big Room Planning". SAFe later renamed it "PI Planning" (for Planning Interval Planning, or, until recently, Program Increment Planning). 

In brief 

Planning may seem like a tricky business, but it's not as tricky as it sounds. As long as you don't try to "get it right" at all costs. Planning is an exercise in prediction: the prediction can be right, just as it can be (more or less) wrong. The important thing is to learn from each experience, and to improve from one to the next. 

Giving visibility to planning can reinforce the feeling of moving in a direction shared by all. This contributes to the transparency and collaboration that enable an agile team to function properly.  

In multi-team agility, or agility at scale, the risks associated with a lack of transparency, collaboration and communication are even greater. A team working under the radar, slipping up without anyone noticing, failing to communicate, can impact on the progress of several other teams, or even an organization as a whole. 

Building a common roadmap is an excellent exercise in alignment and mutual understanding. The "Planning Board" and "Big Room Planning" are two possible ways of doing this. Be careful not to fall into certain traps that can make this exercise impossible or meaningless, and thus disengage the people who have to carry it out. 

To find out more about agile planning, we're organizing a webinar on Thursday June 22 from 11am to 12pm: "Agility at scale, how to equip yourself properly? Focus on Jira Align". It will be co-presented by our colleague Thomas Serre, agile coach and trainer, and Youssri Abdou, Atlassian consultant (Jira Align agile company).

To register, click here :

And if you're not available, don't worry, register anyway and we'll send you the replay at the end of the webinar.