Using Big Room Planning to Help Plan a Project with Many Teams
Many people think working in an agile manner means doing little or no planning. Agile projects actually require as much planning as any other project—it’s just all about trying to minimize wasted effort. While this is simpler in a very small project with a close-knit, highly effective team, for larger projects, it becomes problematic.
What about if you have multiple teams working on a project, as is often the case? This is where we use the big room planning technique. It sounds simple but is rather complex to facilitate and manage.
The principle is to have all of the planning take place in a single, large room. The aim of the release and the various functionalities is explained to each team at the same time, so everybody can discuss their teams' needs, identify conflicts or dependencies, and discover how each team may affect other teams based on their approach and responsibilities.
Once the entire group understands the objectives of this release, the group breaks out into separate teams to plan the features and stories they will be working on. When they have completed this initial planning stage, the entire group comes together and each team explains their plan to everybody else. The other teams have the opportunity to ask questions, identify issues, and otherwise ensure a single vision in moving the plan forward.
When issues are identified, each team once again meets and determines how best to mitigate any problems or dependencies. This frequently requires two or more teams to work together to develop a cohesive approach to the release. Once more the entire group convenes, and the refined plans are shared with everybody. Should there be no further issues identified, these individual team plans become the project release plan.
During the iteration planning cycle, it is useful for teams to reconvene in the big room planning setting to briefly share their iteration plans with each other, again to ensure that issues and dependencies are identified and plans to mitigate these issues are developed between teams. I call this “the bake sale,” as typically the iteration plans are displayed on the wall or on tables so each team can see—and suggest improvements to—the other teams’ plans.
Similarly, during the daily stand-up, I find it useful to the development effort to have team members travel to other teams occasionally so the link between these teams is maintained. This is especially useful if an item is discovered during a stand-up that may delay or affect another team. The person who discovered this issue should attend the other team’s stand-up and explain the issue. The affected team then has the opportunity to take action to mitigate the issue.
With sufficient planning, you can scale agile to large programs with several teams and multiple projects or work streams.
