Executive Summary

When development organizations are large and not able to deliver to delivering software on a frequent basis, a full two-day planning event that decides what to work on for the next 2-3 months may make sense. But at small scale, doing this is far from Agile. This article describes different ways of running planning events. The following methods are one’s that we’ve seen work really well in the situations discussed. They are given in approximate order of being more desirable.  The key is to try what appears to be best and then adjust as you learn.

I. Making Teams Independent of Each other by Having Cross-Functional Teams

The ideal situation is to have teams be independent of each other and each be able to have their own backlog with no dependencies at all.  The advantage of cross functional teams is that having them reduces delays and handoffs as software is being built. In this case each team will have its own product backlog and, if doing iterations, iteration backlog. Teams should communicate with each other when dependencies are found. This might happen during the planning process if Scrum is used, or any time backlogs are refined.  See Cross-Functional Teams: Improving Communication Between People who Work Together for more.

Achieve Cross-Functional Teams to the Greatest Extent Possible. Cross functional teams are teams that have the capabilities of building the software they have committed to with no outside dependencies. This is fairly rare in development/IT organizations that have more than 30 people. The larger the technology group gets the more difficult this becomes. Having cross-functional teams makes teams both more creative as well as more efficient because of fewer hand-offs and common knowledge.

II. MBIs can be mostly done by one team

In this case each team likely already has their own product backlog (and iteration backlog if doing iterations) and it can be kept that way. If dependencies aren’t already mapped a planning event can be held to make them visible and get agreements between teams on how they will be handled.

If teams are doing Kanban there should be a cadence for validating plans for the next agreed upon time. If some teams are doing Scrum then the timeframe for their sprints should be the cadence.  All teams should have their cadences aligned with each other.

Dependency management can either be done throughout the time between cadence points (e.g., sprints if using Scrum) or at the beginning of a timeframe/timebox. If done throughout the timeframe then the “planning event” may be more of a validation that dependencies have been made visible and a plan for meeting them has been agreed to.

III. MBIs are usually small and can be done by one team but sometimes require multiple teams to work on them

If teams are specialized and it’s either not financially advisable or desirable to the team members to have stable, cross-functional teams, a good solution here is have a backlog of large items in addition to each team having its own backlog of things it can do on its own. In this case, the big items are pulled first by a group of team members that can finish an item on the big backlog. As many of these are pulled as capacity is available. At that point any unassigned team members can pull items from their own backlog. When a multi-team piece is finished, the next one should be pulled if the dynamic team just created can do it. This may require stopping someone who is working by themselves on a small item to join the team. This technique can work well for either teams doing Kanban or Scrum. See Dynamic Feature Teams for more detail.

 

Dynamic Feature Teams: Creating Small Mobs Within a Large Group (Case Study). This article describes a case when the team’s demand for expertise bumps up against the needs of the feature team to handle the complex “Big Rocks” in the portfolio. It is a case when cross-functional teams are simply not possible or feasible. Guided by Lean-Agile thinking, one solution is to use a dynamic feature team.

IV. MBIs require more than one team to build

This can be managed in one of two ways mostly depending upon whether teams are doing Kanban or Scrum. In both cases there should be a common product backlog of MBIs that teams pull from. This backlog should be refined so that MBIs are broken up into small vertical slices which can be validated quickly. These slices can be further sub-divided into parts that will be pulled from individual teams.  See Aligning multiple teams with Lean-Agile thinking for more.

Aligning Multiple Teams with Lean-Agile Thinking. Three key principles of Lean Thinking for software development. This article describes how they apply to the value stream (the name Lean gives the workflow from “concept” to “consumption”). It also describes three disciplines Lean-Agile teams will need to follow to keep value flowing. Finally, it illustrates how Lean Thinking guides Agile enterprises in addressing challenges in their context. Lean-Agile lays out a different, more disciplined approach for scaling Agile. (Al Shalloway. 11/2016)

See Running Effective Planning Events to give more information about the opportunity they represent.