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

SAFe Release Planning Tip 2 - Avoid "Death by Powerpoint" on the first morning

The suggested agenda for the SAFe Release Planning Event runs the first morning as follows:

• 08:00-09:00 Business Context
• 09:00-10:30 Vision and Prioritised Features
• 10:30-11:30 Architecture Vision and Development Practices

It's a sound 'scaled facilitation' approach.  Spend time as a large team establishing strategic motivation and context before fragmenting into smaller breakouts.  But there's a catch.  You're starting your high energy release planning event with three and a half hours of trying to keep 120 people awake through a series of powerpoint presentations!

Before tackling the temptation to sleep, let's sidestep for a moment to talk about this series of briefings.  The purpose of the release train is aligning a group of teams to a common vision.  The purpose of the PSI planning event is to produce an aligned plan.  The foundation of the House of Lean is Leadership, and the first morning is the opportunity for the leadership team to lead by example with an aligned vision.

By the time you work through the entire briefing, you probably have 6-8 people contributing.  It begins with the executive delivering the business context, progresses to the sponsor of the release train delivering the vision then travels through the various product managers, the system architect and the development manager.

When a team prepares a major presentation to a group of stakeholders like that, they prepare a skeleton, create individual contributions, come together for assembly and rehearsal, critique flow, polish and polish.  They're desperate to ensure a logical progression, cohesion, a clear start and a clean end.  On this morning, the stakeholders are the teams and it's the leadership group preparing the presentation.  The teams deserve no less care and attention from the leadership group than vice versa.  Don't fall for the temptation to divide up the time, work individually and delegate an executive assistant to stitch the submissions together into a single deck the day before the event!  Make sure you demonstrate your alignment in the briefing.  Don't overlap with each other. Don't give conflicting messages.  Don't follow context with context.  Make sure the briefing has flow!

Now let's talk about sleep.  The key here is to think about interaction.  Craft the briefing as an interactive event.  Build in question and answer time to each feature.  Think about how to bring it to life.  Just as a team preparing for a Sprint review does not simply want to demonstrate their software but create space for feedback and clarification, you should think of the briefing as a review of your strategy.  Think about how to bring in something other than powerpoint.  Can you capture videos from your user interviews?  Can you demonstrate competitor features?  Could you do it entirely without powerpoint?  Should you break it up at some point with an agile game?

Don't get me wrong - this tip is not "kill the briefing".  I know I've heard numerous people suggest just going straight to the breakouts, but that would sacrifice something essential.  If you want your release train to feel like a "self-organising program" rather than a bunch of "self-organising teams", you need collective ownership.  This is nigh on impossible to achieve if teams don't know what other teams are building and why.  It's also a chance for everyone to get feedback on how users/customers are responding to what the train is shipping.   Finally, surprising synergies may emerge, to seed great conversations once the smaller breakouts begin.

I'll close with one final hint.  If you have too many features to talk about each one in depth, you have too many features!!

What's Next?

• Tip #3 - Apply Lean Principles to the Planning Event - Plan with Flow

SAFe Release Planning Tip 1 - Execute your launch as an Agile Project for the Leadership team of the Train

When it comes to launching a train, the SAFe material talks a lot about the "Quick Start".  It's the 1 week "all in" launch process, which basically looks like this:

• Monday and Tuesday - all teams trained together in SAFe ScrumXP
• Wednesday and Thursday - Release Planning Event #1
• Friday - Specialised Breakout training for ScrumMasters and Product Owners.

This is the packaged, high energy launch week Dean and the guys at Scaled Agile have rolled out again and again over the years as they launch trains.

What's not really covered, however, is the pre-work that goes in to making sure that week will be successful.  At SPC training, a whole day is spent on the launch process .. but still, the material there is heavy on how to run the quick-start and light on how to prepare for it.  This, of course, is the space in which the experienced consultants are meant to shine :)

The pragmatic reality is that (in my experience at least), there is 6-10 weeks of solid work to prepare for this.  Whilst the first PSI planning event is really what gives birth to the ART, I think of this time as the gestation period.  Some people may do it faster, but the most recent train I helped launch did it in 6 weeks and they were very very hectic.

My personal belief is that this is the perfect time to start to lay the foundation for success, and the foundation of the Lean House is Leadership.   It's an ideal opportunity for the new train's leadership team to conceive and execute on the launch as an agile team delivering an agile project.  This post from a couple of years ago covered some of the fruits that emerged the first time a team I was coaching took this approach.  I believe the benefits are three-fold:

• The success of the launch is owned by the leadership team rather than the consultant
• The leadership team gets to learn Agile by doing it themselves
• The leadership team gets Fast Feedback on their project as challenges and triumphs emerge at the PSI Planning event

The approach is predicated on the following sequence of events once you have "found your train":

• The leadership team of the train does the Leading SAFe course together
• This is followed by an inception or visioning workshop where the launch backlog is created
• The leadership team executes on the launch backlog over 3 to 5 2-week sprints
• PSI Planning occurs

Leading SAFe

This is the 2-day SAFe course designed for the leadership group of a release train.  There are two ways of approaching it.  The temptation for many is to bring the IT leadership group in for training, then have them "evangelise to the business".  However, for me this misses a golden opportunity.

Agile success is predicated on strong cross-functional collaboration.  Traditionally, we look at cross-functional as "devs, testers and BA's" - at scale, our cross-functional leadership team involves sponsors, product management, architecture, operations, delivery and other stakeholders.  Learning together is a powerful kick-start to shared understanding, take the opportunity to bring your cross-functional leadership team together for the Leading SAFe course.  The discussions will be far richer, and early alignment far stronger.

I also make a slight variation to the course in this context.  I like to finish with 30-45 minutes where the group works together to generate a set of key insights and ways in which they are convicted change needs to start.

The Visioning/Inception Workshop

Ideally, this should occur within a week of the Leading SAFe course.  The objective is to create a vision and a backlog for the launch preparation activities.  Participants should be some or all of the leaders who attended Leading SAFe.

My first recommendation here is to live by the SAFe mantra "Fix the date, float the scope".  Set a Big Hairy Audacious Goal for the launch date.  If it doesn't feel slightly uncomfortable, it's not ambitious enough.  Whether you take 6 weeks or 6 months to launch, the train won't really start learning and growing together until they're all in the room for that first PSI planning event.

In terms of how to structure this workshop, it really depends on how you like to facilitate.  Every SPC gets a "PSI readiness checklist", and one approach would be to use this as a foundation.  Personally, I'd rather the team generates the plan themselves.  My latest (and favourite) structure for the workshop progresses through a series of questions:

• Where did we leave off?
• What will success look like?
• What could go wrong?
• What needs to be done?
• How will we do it?
• When will we do it?
• What are the next steps?
• What did we learn in this workshop?

The material for "Where we left off" is a recap of the final take-aways they generated in Leading SAFe.  For the rest of it, it's flip charts, post-its and your favourite facilitation techniques.  I keep a big picture of the PSI planning "inputs/outputs" visual on the wall, and inject 4 framing themes into "what needs to be done?"

• Program Backlog
• Team Formation/Preparation
• Operating Model
• Logistics

You should exit the room with a vision, a well-formed backlog prioritised into sprints, and an agreement for leadership team cadence executing on the backlog.

Executing on the launch backlog

You now have a backlog full of stories about booking venues, grooming the program backlog, forming and training teams.  Hopefully, you have a leadership group excited about working together as an Agile team to deliver those stories.  Most likely very few of them have ever actually done so.  Now it's time for them to learn Scrum by doing, ably served by the Release Train Engineer acting as the scrum-master.  Sprint planning, stand ups, backlog grooming, showcases (to the teams of course), retrospectives and a kanban wall are the order of the day.

Some of the things to look for:

• Shared understanding forming across leadership silos as they plan, execute and retrospect together
• The team understanding the way a backlog "responds to change" as they learn the flaws and gaps in their launch plan as they execute against it
• A real understanding of "MVP" emerging as the PSI planning date nears and the team makes hard priority calls about "what really has to be done to be ready" versus "what would have been ideal".
• The team understanding the value of dedicated teams as they struggle to make headway against the distractions of their "BAU work".  This is often demonstrated by a near zero velocity in the first sprint.
• Transparent lean leadership in evidence as the team showcases their results to the teams on the train-to-be.

PSI Planning

The event itself is the subject of many posts to come, but in the context of the "launch project", I have one extremely strong recommendation.  Very soon after the Release Planning occurs, the leadership team needs to run an "Inspect and Adapt" against their launch plan.  This sets the scene for the preparation for Release Planning #2.

What's Next?

• Tip #2 - Avoid "Death by Powerpoint" on the first morning

Launching your Agile Release Train - Preparing for the first Release Planning Event

You've decided to adopt SAFe, found your first Agile Release Train and are embarking on the launch journey.  You have a bunch of Safe Agilists who have completed "Leading SAFe", and an SPC who has done the certification but never actually launched a train.  What comes next?

If you're like most, you're now feeling a mixture of excitement and trepidation.  The maths most people do looks like this:

• 100 people in a room for 2 days = $150-$200K
• A bunch of senior stakeholders present = a huge opportunity for a very public embarrassment

You've been over the agenda in depth in your SAFe course.  You've read some case studies or talked to some people and been convinced it works.  The question running around and around in your head is "how do we make it work for us?"

One answer might be to go and guest at somebody else's event to glean experiential learning.  As a fresh SPC, it was certainly high on my wish list.  But I had two problems.  The first was that I was in Australia and the only people I knew doing it were overseas.  The second, of course, was that these events often deal with very sensitive information and it's hard to get an invite.  Despite my repeatedly offering to fly myself anywhere in the world to get first-hand learning, I eventually just had to learn by doing.

This is the first of a series of posts in which I'm going to share some of the lessons I've learnt along the way.  It's a mix of the things I wish I'd known, and the things I knew in theory which were emphatically reinforced in practice.

The first insight I'd offer is this:

It really is magical how much energy and alignment happens when  100 people with a common purpose collaborate for 2 days.

To be brutally honest, I'd lived on the trepidation side for a long time.  The first train I helped launch (documented extensively in previous posts) frustrated Dean no end by not adopting PSI's until well after I had moved on from coaching them.  There were lots of very good reasons.  They got an immense amount of value from "SAFe without PSI's".  But I still hadn't seen the "magic event" :)

In the meantime, I researched it, talked to people about it, and taught SAFe to hundreds of people - and the release planning component was always theoretical.  I believed emphatically in the theory.  But when I actually facilitated my first one, I staggered out at the end of it completely and utterly blown away by how powerful it was.  I have facilitated hundreds if not thousands of groups and workshops over the years, and I have never felt such a powerful movement into alignment.  A comment from the Commercial Manager footing the bill for the event sums it up pretty well:

Mark, I reckon we've just saved about 8 weeks

What's Next?

Eventually, the series should cover about 10-15 posts.  Following is the series to-date:

• Tip #1 - Execute your launch as an Agile Project for the Leadership team of the Train
• Tip #2 - Avoid "Death by Powerpoint" on the first morning
• Tip #3 - Apply Lean Principles to the Planning Event - Plan with Flow
• Tip #4 - Consider Feature Breakouts as well as Team Breakouts
• Tip #5 - Know your Capacity Constraints
• Tip #6 - Scaled Planning needs Scaled Facilitation