Tuesday, January 21, 2014

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?

1 comment:

  1. In vain I hesitated for a long time about looking for a teaching assistant, because if I had decided earlier I would have found a price that would do my job, a place where any written work that I need is done.