LeSS is the Large Scale Scrum Framework. It’s an approach to organize large product development around customer value. LeSS is less descriptive than other frameworks like SAFe. Therefore it’s often not adopted by organisations that prefer control and that want to adopt a comprehensive set of rules. LeSS focuses more on practices than on rules. That’s why I would like to introduce to various practices that I find important in a LeSS adoption and that can reduce the fear of organisations to enter this journey. This article is about the Multi-Team Planning.
Feature Team Adoption
When working with many teams on the single product in LeSS, you will set up the teams as feature teams. That means that one team can work end-2-end on a customer value features. If your backlog is organized by customer value, than in the ideal scenario every team can work on their own. In practice this is a perfection vision. There is the feature team adoption map in LeSS, that describes the growth of teams towards this vision.
LeSS is supportive with practices that help these teams to develop themselves. They should learn from other teams for example about new components or domains expertise. So it’s obvious that from time to time one team cannot provide end-2-end customer value alone. The help of another teams is needed which requires coordination.
Dependencies
In traditional development you would call this a dependency. Other frameworks like SAFe are successful because they apparently solve the problem of inter-team dependencies. In LeSS the number of dependencies is reduced because the development is organized by customer value. Overall there are less dependencies when you work with feature teams rather than component teams. But as I mentioned, this is a perfection vision. Infect in the LeSS Rules, the majority of teams must be feature teams, which also means that there are still a few specialized teams.
LeSS welcomes the work together across teams. It’s called Opportunities for Shared Work rather than dependencies. It also brings the focus of teams from working on their own to collaboration with other on the overall product.
Multi-Team Planning & other Meeting
Besides other coordination techniques, LeSS introduces multi-team meetings to support shared work.
- Multi-team Product Backlog Refinement
- Multi-team Planning
- Multi-team Design Workshops
How these multi-team meetings are embedded in the LeSS framework, you can see in the following video created by my colleges from Valtech.
Although the multi-team meetings are part of the framework, there is no simple rule to run them. It’s a decision that must be taken consciously in the Overall Refinement or Overall Planning. That also means that it must be learned and practised to become a organisational habit.
Overall Planning
Multi-Team Planning happens directly after the Overall Planning. In the Overall Planning the Product Owner runs with all the teams through the backlog for the next Sprint. Teams ask for clarifications and pull items into their Sprint Backlog. All teams get an overview about the work of others. Hence it also possible to identify coordination needs and opportunities for shared work. I have introduced a practice to visualize the coordination needs between multiple teams using a matrix. This is also known as the dependency matrix. This matrix is only a transparency technique to make coordination needs visible. It’s transient and is not maintained afterwards. Using this information two teams can identify the need to have a multi-team planning after the overall planning. Also other coordination techniques can be triggered, e.g. joined design workshop.
Formats
In general the Multi-Team Planning is happening in one room. Teams occupy different corners in the room and perform the Sprint Planning activities. From time to time a team may shout out and request other team’s help. This is the simplest format of a Multi-team Planning. If the teams already know the items on which they want to work together, they can also have a joined session or create a smaller joined group out of team representatives to create the sprint backlog items for the shared work.
Shared Work and Shared Backlog Items
I have made good experiences with providing product backlog items for the teams to share. One customer value feature requires the work of multiple teams. All teams get the same backlog item for this feature and plan out the tasks together. Although this may not be according to the LeSS Rules, it can give the teams a shared goal to get something to done together. The tasks are defined per team. This planning is done in a Multi-team Planning on which both teams are participating. In the Sprint Review the same teams show the work done and gather feedback on the feature.
Shorter Feedback Cycles
Compared to the dependency management in SAFe, the practices suggested by LeSS lead to shorter feedback cycles and are more specific to the features. In SAFe the PI Planning happens every 2–3 months for all teams. In LeSS the coordination on inter-team opportunities for shared work happens every Sprint. But it’s a practice that must be learned to become an organizational habit. The more feature teams you have in your organisation, the less often you need to coordinate around dependencies. On the journey towards perfect feature teams, you can use the multi-team meetings to deliver customer value features agross.