SAFe Release Planning Tip 3 - Plan with Flow

In Tip 2, we covered the first morning of the SAFe release planning event - establishing the vision for the PSI and starting the whole train on the same page.  Our objective for the remainder of the day is to produce the draft plan.

I believe a crucial aspect of the release planning mindset is to view the event as an investment and execute with a view to maximising value delivered.  The primary value to be delivered by the draft plan is to reveal the challenges in the vision and support effective trade-off decision making in the management problem solving session.

We know from Reinertsen that the key to maximising value is flow, and that the key enablers for flow are:

• Reduce batch size
• Get fast feedback
• Actively manage queues
• Limit WIP

Now let's travel to reality.  You're at the first PSI planning for your new release train.  The following is almost certainly true:

• You have "newly formed" teams, which have not yet gelled
• You have an optimistic "wish list" of features to be delivered
• Your features are not particularly well elaborated
• Your teams are almost certainly a blend of "nearly feature" and "component" teams
• You have 100+ people in the room who are not entirely certain how it's all meant to work
• You've created a "program board", and everyone understands the theory of what it's meant to be but nobody is really sure how it's going to come into being

You're entering 3 hours of "team breakout" time.  The overwhelming temptation is going to be for each team to enter the "silo zone", nervously attempting to create their own plan.  They're going to be worrying about the herculean task of breaking out and estimating all their stories in the time box. Any attempt from other teams to interact with them will be viewed as a distraction killing their "planning velocity".   In essence, you have every possible ingredient for killing flow.  Minute by minute, the queue of unresolved "inter-team assumptions" will grow.  The "Batch size" for integration of planning outputs will become herculean.  Feedback will be measured in hours not minutes, despite the fact they're all in the same room.

The risk you run is that all plan integration will occur in the last 30 minutes before the draft plan review.  The review is in peril of becoming a litany of "we haven't yet validated our assumptions regarding our dependencies on component team x".  The reality is that this period is meant to reveal your integration bottlenecks.  If all your teams were capable of working independently, they wouldn't need the Release Train construct in the first place.  How can you facilitate effective management trade-off decision making if you don't understand the inputs to the tradeoffs?

The answer is to "apply flow".  Create a feature planning kanban with explicit WIP limits.  Support your teams in creating integrated plans "feature by feature".  Create a visible pull system.  As a team pulls a feature into active planning, they can summon the domain experts to their table to support the breakdown of the feature into stories.  Your plan will naturally evolve consuming train capacity to implement your highest priority features first.  Plan integration will become "small batch" as teams look to validate their dependency assumptions and populate the program board feature by feature rather than in a massive "end of day rush".

Below is a sample Feature Planning Kanban board.  As a feature is pulled into active planning, it enters the "Writing Stories" state.  Teams on the train each have avatars (indicated by the coloured circles on the diagram), and teams involved in the feature attach their avatars to it.  This provides a living view throughout the event on which features are where in the planning cycle and which teams are involved in planning each.  The "Adjusting" and "Finalising" states are utilised for Day 2 planning adjustments.

The result will almost certainly be that you haven't broken down all your features into stories at the end of the first day.  But you will have high quality integrated plans for your highest priority features.  You'll see where the bottlenecks are.  In essence, you will have planned the "big rocks".  Management problem solving can then focus on how to select the best value "pebbles" to fill the gaps.

Along the way, you will have limited the number of features being planned at once (Planning WIP).  Your queue of unvalidated integration assumptions will have been actively kept small by ensuring features are fully planned before pulling new ones.  Feedback will be fast.  And you'll have avoided the "end of day scramble" to populate your integrated plan.

What's Next?

• Tip #4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams