What Do We Need to Think About When We Go From a PI Planning Approach to a More Continuous Planning Approach?
Or “How do we go to release planning?”
I’ve been in a number of organizations where a set of Teams, after setting up to make things work through SAFe PI Planning events with all the trappings, they decide that this is not the best approach from them. Reasons include:
- Too few Teams. There is a significant cost to the overhead of PI Planning (and related) events. In some circumstances people will realize that with say 2-4 Teams, you could handle alignment and coordination simply by having Teams talk directly to each other.
- Work not plannable for a quarter. For some Teams, such as support and common services Teams, it is not possible to determine what will happen over a quarter since work is mostly breaking in. Trying to plan in this situation could be seen as wasteful.
- No real dependencies between Teams. The PI Planning approach is really aimed at working dependencies that exist between Teams that are delivering to a common multi-team value stream.
Just because you have decided not to do a PI Planning event it does not mean that that’s it. You will need to think through what it means. The best way to think about this is to think about the purposes of the various events supported by SAFe / Scrum, think about why we are doing them, and then decide “if we don’t have this event how do we get to the ceremony’s outcome?”
For example, the purpose of PI Planning is to get have multiple Teams get to alignment on the priorities for the next quarter (and keep roadmap up to date), work dependencies, and work risks. If we don’t have PI Planning, what do we need to put in place to get that outcome. We could decide, for example, that “we will have a biweekly feature refinement session attended by the POs (or their proxy) which will prioritize upcoming work, and update the view of expectations for the next couple of quarters. While this meeting will discover dependencies, it is expected that Teams are expected to work dependencies directly between them as they work the item.”
Then, when we say “we won't do PI Planning” then there are a number of execution events that we still need to work:
- Scrum of scrums: the purpose is to work execution issues across multiple Teams. What do we need to do to ensure we are addressing execution issues.
- PO Sync: is this just the refinement meeting?
- ART Sync: is it worthwhile to combine PO Sync / Scrum of Scrums?
- “Why” Meeting (note: not part of standard SAFe but something I’ve found useful): purpose is to help people understand where we are going / what is coming up? How do we do this?
Then we also need to make sure we are responding to our values:
- We value innovation and learning: This is where we do things like like hack-a-thons etc. What are going to do to ensure we have space for innovation and learning?
- We value continuous / relentless improvement: The events we use to drive this are things like retrospectives / inspect and adapts. What are we going to do to ensure we have space for improvement? Assuming each Team does this (OK, perhaps not a great assumption but you get what I mean), how do we surface cross team / more systematic and organizational improvements.
- We value working solutions (and finishing): The event where we surface this for this is the Iteration Review and System Demos, which also helps ensure we have good understanding of what we are doing across all the Teams. What are going to do to ensure we have / see working solutions.
By the way, this type of thinking applies to complete Kanban Teams as well. While Kanban doesn’t say “have a Retrospective” if we value continuous improvement then we need to make this happen. One way to make this happen is to set up the event on the cadence.
Want To Know More?
- Why Do We Establish a Cadence of Events? for a discussion of how cadences help in many situations.