Friday, December 5, 2014

Moving from belief to action - implementing WSJF for value based prioritisation in SAFe (Part 2)

In my last post, I described the simulation I use to teach Cost of Delay (CoD) and Weighted Shortest Job First (WSJF).  This often provides the impetus to begin, and one of the beauties of the model is that you can adopt it before you’ve even begun to change delivery method.  Beginning your change with a shared definition of value and a rich supporting discussion is a great launch point!

The first step is to make sure you know your vision and overarching strategy.  This need has usually emerged in the debrief on the simulation.  One group will mention how they paused with 10 minutes to go to say “what kind of city are we really building here?”  Every other group will look around and say “aaah, if only we’d started there!”.   Pulling it back to SAFe terminology, we are looking at the workshop(s) to define the strategic themes and portfolio vision.

With a sound strategic vision in place, we look next at adapting the model to the organisational context.  Three key questions need to be answered:

  • Do we use Dean’s components for CoD?
  • Do we weight the components equally or otherwise?
  • What specific factors contribute to each component?

The official SAFe formula is:
Cost of Delay = User/Business Value + Timing Criticality + Risk Reduction/Opportunity Enablement
Typical variations I have seen include:

  • Separation of “Business Value” and “Customer Value”
  • Separation of “Risk Reduction” and “Opportunity Enablement”
  • Introduction of a component for “Alignment to Strategy”
  • Weighting Business Value more highly than the other components.

In practice, I prefer to defer the weighting question.  Revisiting it once you have scored a set of options and gained a feel for how you are scaling each component seems to land you in a better position.

Another key theme that always emerges in the simulation debrief is the importance of getting to a shared understanding of ‘what contributes to’ business value, timing and opportunity/risk reduction.  Groups will discuss how alignment around scoring became easier as they aligned around the definition of value.  They’ll also regularly highlight the fact that once they got to opportunity/risk reduction they realised they had been ‘double-counting’ it in earlier components.

Leveraging this insight, my next workshop after the strategy is defined beings with identifying the contributing factors.  This is fairly easily facilitated with flip-charts and post-it’s, and typically takes 60-90 minutes.  Again, it becomes an alignment tool as it enables a great discussion on what constitutes value and opens up shared understanding among the group.  Below is a (slightly desensitised) example of the definition from a group I recently helped develop a roadmap using WSJF.

By this point you have an overarching strategy, a model people understand how to use, and you’ve filled in and clarified the intent in using it.

The next step is to take your current list of opportunities and get them estimated.  Most groups I work with want to retain the index card/planning poker approach.  This is handy, because every good coach knows how to help people navigate a good planning poker estimation session.  I will also often separate the estimation to one workshop per contributing lever.  The conversation is intense, and with a decent size backlog (25-30 items) allowing a couple of hours per component works well.  It also allows time for homework and clarifications.  We regularly park a couple of items for people to go away and assemble supporting data.  We conclude the series by pulling all the calculated results together and reviewing/adjusting the result.  Once your first list is prioritised, you just need a cadenced working group to evaluate new items or adjust previous evaluations as new information emerges or timing considerations change.

My closing hint is to remember not to be a slave to the numbers.  There are often good reasons to adjust the final ordering.  And naturally you want to put a kaizen approach in place to start to measure realised benefits and use that feedback to improve your initial value estimation discussions.

The true value is not in calculating WSJF to 2 decimal points.  It lies in having a tool that facilitates objective conversations that assists a group of execs or product managers in aligning around a common understanding of value for the organisation.  In doing so, it’s amazing how much they start to understand about each other.

Friday, August 22, 2014

Getting from theory to practice with Cost of Delay and WSJF in SAFe

Recently, I’ve noticed a number of threads on the SAFe linked-in groups indicating people are struggling to get started with the SAFe “Weighted Shortest Job First” (WSJF) prioritisation model.

When I first heard +Dean Leffingwell teach the model I thought “wow, this fantastic.”  His use of a proxy model for Cost of Delay (CoD) seemed inspired.  +Don Reinertsen  had provided compelling arguments for the power of fully quantified CoD.  On the other hand, all too many people abandon all attempts to have a value discussion because it’s “just too hard to quantify”.  The 3-part proxy in SAFe seemed simple enough to enable people to begin.

The problem, I learned, was one often encountered in people digesting Don’s principles of product development flow.  It sounds like fantastic theory but the complexity makes it challenging to find a starting point.  My first breakthrough came in early 2013.  I was teaching a public Leading SAFe class, and had 5 people from one company on the same table.  While most people tackle the WSJF exercise as individuals, this group had a shared list of features and attacked it as a group exercise.  They made up planning poker cards from post-its and started voting.  As I listened to the conversation, I got inspired.  Not only did I hear a great discussion, but I could hear what they had misunderstood from the theory.

My next step was to take their example and turn it into something every class member could experience.  They’d had the benefit of a list of features all of them recognised, but this is rarely true.  For an answer, I decided to feed every group a recognisable set of things to debate for Cost of Delay.  The result was a simulation I call “SAFe City”.  The setting involves a property developer building a satellite city and evaluating the Cost of Delay of various housing estates, shops and other developments.  Initially framed at the Epic level, every group receives a list of 9 Epics to evaluate along with a good supply of planning poker cards.

I started to run it for every class.  And the results astonished me.  Not only did it become apparent how confused people became in interpreting the theory, but I also started to understand the true beauty of the model myself.

Sample Epic

If you’re interested in the simulation, it takes roughly 1 hour to run and debrief and all the required materials can be found at SAFe City Epic Prioritisation.  It runs perfectly well standalone, and I’ve run it with groups up to and including C-level.

The activity gives groups both the confidence and interest to take it back into their own context.  I’ve now seen numerous groups elect to adopt the model irrespective of whether the initiatives are being delivered through waterfall or agile.  In my next post I will tackle the first steps as we take it out of the classroom and into reality.

Wednesday, July 2, 2014

Self-selecting teams with SAFe

Whilst the energy surrounding the launch of an Agile Release Train is immense, there is an all-too-real risk that our new teams will be more facade than reality once the hype dies down.

Forming around the delivery of value, we draw a "kidney shape" that inevitably cuts across significant organisational boundaries.  In so doing, we ask both line management and team members to take a major leap out of their comfort zone.

Whilst as agilists we love the mantra of "embracing uncertainty", it is far too easy to gloss over the human impact this creates.

For line management, it involves a significant amount of release.  No longer will they determine the day to day priorities of those they manage.  Much as we rail against traditional performance management, it does not disappear overnight.  How will they address this in a matrixed world?  How will they address their duty of care with respect to career progression?  How do they deal with a situation where some of their people are embedded in a train and some not?  What happens when they lose their "go-to" problem solvers to an agile team?  Do they really understand what "dedicated team member" means?

For team members, the upheaval is even greater.  No longer will they be surrounded by others with a similar skill-set and conversational language.  In many cases, their new team-mates will be people they have literally thought of as "the enemy" for years.

There is a pattern I have been guilty of and heard from fellow coaches many times around the design of teams for a new train.  Full of passion to create "self-organising teams", enable decentralisation, and change our language from "resources" to "people", we fill a room with leadership.  Wanting to be agile, we bring lots of post-its.  We put flip charts on the wall (one per team), put people's names on color-coded post-its (blue for devs, red for testers, green for BA's etc etc).  Then we allocate them.  Who goes where?  How do we get a balanced team?  Can we stick to "100% committed" and avoid "shared resources"?  Full of our triumph at our "agile team selection process", the workshop concludes with a moment to form the "Comms plan" for announcing the new team structures.

Do the leaders in the room really understand what they're committing to?  Do they feel safe to voice their concerns?  Do we know the personalities and personal histories of the people we are teaming up?  Are we discussing people or post-its?

Any hesitation in answering the questions above in the affirmative will likely undermine our train.  But beyond that, doesn't this feel like a very management-centric approach to creating "autonomous self organising teams"?

I've felt for a long time that there has to be a better way.   I've been reading for years about the power of self-selecting teams.  I've loved it not just from the "team effectiveness" perspective but also when thinking about the psychology of change.  Every Agile coach knows that people dislike having change forced upon them, we should be trying to create the conditions in which people can be part of choosing the change for themselves.  But I just haven't been able to bring it to life.

Then last year I read a blog post by Sandy Mamoli of Nomad8 about "squadification", and I was in awe.  She had convinced an entire IT department to throw their current structure into the air and hold a 1 day event which enabled all their people to organise themselves into new Agile teams (or squads).  She had been generous enough to share her facilitation design, and as I read it light bulbs started going off in my head.

Her premise was that the job of leadership was to design the teams, their missions and the skill-sets they would need available to fulfil them.  So far so good, this is what we're doing when we commence the design of a release train.  Then, you  hold an all-day facilitated event where candidate team members self-organise themselves into the teams whose shape you have defined.  What a replacement for the "people as post-its" workshop!

I was fortunate recently to be coaching a train with a courageous leader.  They had originally formed with component teams, were looking to re-organise into feature teams, and he shared my excitement about Sandy's thinking.  In the spirit of servant leadership, he did not want to thrust it upon his leadership team but invited me to facilitate a series of workshops with them to explore it.

Three weeks and many nervous moments later, we embarked on a "Team Fair".  He has shared the story on his blog, and I have to say the result was amazing.  The vast majority of our "What if?" scenarios about things going wrong did not eventuate, and some very surprising and creative outcomes did.  In designing it, we had the chance to explicitly redesign the role of line management in the new world and give them the time to walk their people through the upcoming change and involve them in the preparation.  The fair itself became a symbolic moment as leadership "released" their people into the freedom they had designed.

With every train I help to launch, I take away some new learnings for the next one - backed by the conviction of experience to give me the courage.  Facilitated team self-selection through a "team fair" is now firmly in the kitbag, with thanks to +Sandy Mamoli for the inspiration and +Andy Kelk and his team for the courage to experiment.

Sunday, May 4, 2014

SAFe Release Planning Tip 6 - Scaled Planning needs Scaled Facilitation

Watching a great facilitator in action can feel like being in the audience for a magic show.  You cannot understand how they're doing it, but somehow they invite people to be present and give of themselves while creating the safety and energy for true creativity and alignment to emerge.

It's been a large part of my work for many years, and I know that for a long time when people asked me to explain my secrets I was unable to answer.  Eventually, as I spent time with amazing facilitators like +Jean Tabaka, +Gerald Weinberg and +Esther Derby I started to understand the science and recognise why some of the things I did worked.

A facilitator's first desire is for every person in the room to have a voice, and to be engaged from the moment they enter the room.  Their second is for the workshop to align these divergent voices, enabling them to leave the room with both shared insights and shared commitment to the outcomes.

The SAFe Release Planning event is both the dream and the nightmare of the facilitator.  As a dream, it provides the canvas of 100 or so people and 2 days to work.  As a nightmare, it asks that you keep 100 people fully engaged in tough often contentious work for 2 days.  The first secret of facilitation is to create the safety for every participant to be heard, understood and valued - incredibly hard to create, observe and address in large groups.

Draft Plan Review

So, how do we do it?  The good news is that it begins with basic technique rather than "art".  When coaching facilitators, I return again and again to the message that you do half of your facilitation before you ever enter the room.  You do so by creating a structure to facilitate to.  How will you use the space?  What tools (or activities) will you use for each phase of the workshop?  What supplies will you need?  How will you "set the scene" visually to engage them when they walk in the door?  What will they see?  What will they hear?  How will you create movement?  With the right preparation, you can focus on observing, inviting and steering with minor interventions.

The really good news is that the SAFe Release Planning Facilitation guide in every SPC's toolkit provides you with a fantastic starting structure.  The influence of +Jean Tabaka  (the "Queen of Collaboration") in +Dean Leffingwell's formative work at BMC is readily visible, as is the polish applied through the dozens if not hundreds of events in which it has been applied since.

The agenda sets the scene for an orchestrated dance of scene setting (vision briefings), divergence (breakouts), convergence (plan reviews), check-ins (scrum of scrums) and closure (confidence vote).  The Program Board and Team Breakout setup guides provide a visual structure to facilitate to, as do a number of the additional tools such as a Feature Planning Kanban that I've suggested earlier in this series.

Program Board

However, there's a catch.  Once the dance starts, the most important tool in the facilitator's arsenal is observation.  They must be able to see and hear the moments when intervention is needed, and observe them clearly enough to intervene effectively.  You can do this for 20 people, but how do you do it for 100?  

Additionally, a typical workshop breakout would be measured in minutes and intervention can occur when the groups converge back from the breakouts.  But we have breakouts that last for hours.   Our overarching structure requires supplementation at a more granular level.  Those long breakouts themselves need to be designed and facilitated.  

Team Breakout Space

If you spend any amount of time with Jean, you will learn the importance of facilitation planning.  Personally, I generally allow 1-2 hours of planning/prep time for each hour of the workshop.  Jean generously reviewed this post for me, and observed that her team at Rally have found that very large workshops tend to take even more than 2 hours per hour of the meeting. This is not "logistics, invites and powerpoint" .. it's facilitation design.  And if you're working with a facilitation team, it needs to be shared time.  

The reality is one facilitator cannot do this, no matter how heroic their skills.  You need a team.  And that team needs the fundamental skills to enable an amazing event.  The chance that your brand new Release Train has a ready made team of facilitators is near-zero - you need to create one.   My recommendation would be that your team consists of at minimum the primary facilitator and one per team (ideally your scrum-masters) for the breakouts.  Ideally, you'd also have a secondary facilitator dedicated to folks such as stakeholders, product managers and architects who are at risk of becoming disconnected or lost during the breakouts.  This team needs 2-3 days workshopping together to prepare the facilitation plan for the first event.  

As you create the plan, make sure the whole team owns the whole plan.  At no time should a facilitator be thinking "I'm off-stage now" and signing out.  It's a synergy.  If the objective of a particular "whole train" moment is going wrong, the small group facilitators can rescue the day through adding the right powerful question from the crowd.  Likewise, the main facilitators should be roaming constantly during the breakouts.

A rough plan of attack is to look at each segment of the agenda and ask the following questions:
  • What is the objective of this segment?
  • Who is "on stage" for facilitation?
  • Who is "off stage" and how might they help?
  • What does success look like?
  • Who are the main players?
  • Who is likely to be less involved, how can we keep them connected?
  • What facilitation tools will we use?  Do we all understand how to use them?
  • What materials and preparation do we need?
  • How will we capture the key takeaways?
  • What is likely to go wrong?
  • What is the ideal time box?  What's the minimal time box?

Once the event arrives, make sure the facilitation team has an open/close for each day and a retrospective after the event to support their own inspect & adapt cycle.

Like much of this series, the tips offered here are lessons learnt through failure.  For my first event, I took the "heroic facilitation" approach.  I worked with the RTE to create the facilitation plan.  It was a great plan, and we were very proud of it when we shared it with the scrum masters so they were clear on their responsibilities.  And I started writing this post in my head about 10 minutes into the first breakout.  We survived it, the energy was great, and the stakeholders were blown away.  But it could have been so much more if I'd remembered Agile 101 - "the team that's going to do the work should be the team that creates the plan".

Saturday, March 29, 2014

SAFe Release Planning Tip 5 - Know your capacity constraints

One of the magical side-effects of building stable teams is the fashion in which it simplifies capacity planning.  No longer is it a question of project managers wrestling with "resource-levelling" in MS Project to ensure maximum utilisation.  Instead of the "resource" being our fundamental unit of capacity, the team replaces it.

SAFe takes this to the next level by composing a group of teams into a release train - allowing us to move beyond team capacity to train capacity.  Traditionally, this view of rolled-up capacity is impossible since team capacity is measured in story points and different teams use local definitions of a point.  Albeit contentiously, SAFe resolves this by suggesting the adoption of normalised story points - allowing us to roadmap based on a "Points per PSI" capacity for the train.

The selection of feature mix to take into a PSI utilises the following elements:

  • Train capacity (how many/how big)
  • Capacity allocation (proportions for different feature types)
  • WSJF (prioritisation of features within each class of capacity)

To illustrate using the "GeekBooks" online bookstore metaphor from the Leading SAFe simulation, picture the following:

We are employing three classes of capacity with allocation based on our opening business strategy:

  • B2C (Purchasers of books) (50%)
  • B2B (Suppliers of books) (25%)
  • Architecture (25%)

Following relative sizing and WSJF assessment of the features in the Program Backlog, we might have the following:

Assuming a train capacity of 500 points for the PSI, the following would be selected for PSI planning:

  • B2C (Flexible Search, Book Browsing, Shopping Card) (240 points)
  • B2B (List New Title, Alter Pricing) (120 points)
  • Architecture (Active-Active, Internationalisation (120 points)

But there's a catch.  This wonderfully clean formula only works if the train contains nothing but Feature teams and any team can pull any feature.  In a world with multiple flavours of feature team you now have capacity constraints based on feature flavour.  If you further complicate it by having component teams, you must also factor in component capacity constraints.

Imagine that the release train has the following makeup:

  • 2 x B2C Teams (capacity 100 points each)
  • A B2B Team (capacity 100 points)
  • A middleware component team (capacity 50 points)
  • A "Back-end" component team (capacity 150 points) 

Whilst the initial strategy assumed 3 classes of capacity driven purely by economic strategy, in reality we have 4 flavours of capacity constraints.  We can still "roll the dice", enter PSI planning and wait for the management problem solving session to apply tradeoffs between economic priorities and real constraints.  I've been there, and the power of the event is that it helps you navigate exactly this situation.

But ... we can also smooth our life out with a little more up front feature refinement.   If we know we actually have 4 types of capacity constraint, why not take our feature-level estimation down one layer of granularity.  Applied to the first example, we might see the following:

We now know our previous feature set requires the following:

  • 150 points of B2C capacity (under by 50)
  • 90 points of B2B capacity (under by 10)
  • 70 points of middleware capacity (over by 20)
  • 190 points of back-end capacity  (over by 40)

At this point, there are various ways to respond.  Deferring the active-active feature is obvious.  Finding a small "client-side only" feature would make sense to take advantage of our spare B2C capacity.   In reality, the management problem solving session at the end of Day 1 deals with a scenario this simple easily.  However, we still have no idea what other problems will be exposed during the draft plan preparation process.   Additionally, teams will have wasted breakout time that could easily have been avoided.

Conclusion Part 1

When preparing for Release planning recognise your underlying capacity constraints.  Whilst avoiding the temptation to go too far with up-front estimation, find a middle ground such as illustrated above.  It should well and truly be above the level of "individual specialists", but deeper than "train story points".  Further, recognise that in the presence of numerous component teams normalised story points are of limited value.  They're a very useful tool (and worth the danger) when you have fungible feature teams, but almost irrelevant with a heavy component team mix.  Your real need is "rolled up capacity by class of constraint".

Conclusion Part 2

Whether you have composed your people into feature teams or component teams you will almost certainly have these constraints for your first PSI.  You are most likely starting with a group of specialists who have not yet begun to generalise.  The key difference is this.  As long as you have component teams, you will live with the constraint as your specialists will remain specialists.  If you make the effort to move to feature teams, they will gradually erode the constraints as they take shared ownership and learn from each other.

Sunday, March 23, 2014

SAFe Release Planning Tip 4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams

SAFe proposes a number of team flavours.  All are cross-functional insofar as they are able to "Define, Build and Test a thing of interest".  The suggested "things of interest" are:

  • Features
  • Products
  • Components
  • Subsystems
  • Interfaces

Realistically, the flavours can be further condensed into either  "Feature" or "Component".  A "Feature team" can fully deliver a "Business Feature", whereas a component team can typically only deliver "technical components of a Business Feature".  On the other hand, component teams can quite often fully deliver "Architectural Features".

Countless books, articles and speeches have been devoted to the benefits of Feature teams, but the reality is many if not most trains will launch without them.  Most will contain a mix of "psuedo-Feature teams" which can nearly deliver a business feature and supporting component teams.  Typically, 3 factors contribute to the presence of component teams:

  1. Insufficient people with a given specialisation to provide one for each team
  2. Technical and environmental constraints 
  3. Lack of conviction of the benefit to aligning at the team level around valued outcomes rather than technical proficiency

The net result is that the vast bulk of features will require contribution from more than one team.  Typically, the "pseudo-Feature" teams will take ownership of business features and look for contributions from the component teams.  The component teams, on the other hand, will often take ownership of architectural features and expect to provide contributions to the business features.

In the context of SAFe release planning, this can all too easily create the following scenario when the Team breakouts start on the afternoon of day 1:

  • From 1:00-3:00 the "psuedo-Feature" teams work with their product owners and managers to understand the business features they are tackling and break them down into stories.  As they work, they identify needs they'll have from the component teams and assumptions as to what form they'll take and they place these in a pile ready to hand over.  They may visit the component teams during this time, but are likely to be given short shrift as the component teams are deep inside "their own features".
  • From 1:00-3:00 the "Component" teams work with the architects on the architecture features in the program backlog and break them down into stories.
  • From 3:00-4:00 the feature teams land on the component teams with a pile of stories they need estimated and scheduled.  The component teams, with little understanding of the context, look at the stories and say "they're wrong, we're going to need to rewrite them" .. while the feature teams say "but we need you to estimate and schedule them so we can lock in our plan".
  • At 4:00, the draft plan review exposes a litany of unvalidated assumptions and bottlenecks around interactions between the feature teams and the component teams.
  • On Day 2, the feature teams and the component teams work together to translate the feature team needs into technical stories for the component teams to deliver .. with the product managers and owners relying on the feature teams to represent their needs as they've "already conveyed the business context and don't understand the geek-speak".

What I suggest is to both leverage flow-based planning as described in Tip #3 and different types of breakouts.  As part of your program backlog preparation, identify the features which are heavily interdependent across teams.  When choosing the priority order for planning, consider planning these features first.  Inevitably, you will wind up with a plan where the scheduling of these features dominates and the more contained features are scheduled opportunistically into the gaps left.

When breakouts commence, rather than going directly to team breakouts go to feature breakouts.   Your "pseudo-feature" teams pull features, and collect representatives from each component team to join them for the initial breakout.  The focus of the feature breakout is then:

  • Establish shared understanding of the feature
  • Elaborate any further feature acceptance criteria as necessary
  • Break the feature down into team-based stories with high-level acceptance criteria
  • Identify key dependencies between stories that cross team boundaries.

Once the heavily interdependent features have each been through their feature breakout, return to team breakouts - with team members taking their stories with them.  Once back in the team breakouts:

  • For each feature from a feature breakout:
    • Members share the stories created during the feature breakout with the rest of the team, obtaining further clarifications as necessary
    • Estimate as a team
    • Load stories into sprints in-line with inter-team dependencies
    • Close the feature out on the program board
  • Progress through feature breakdown and planning for remaining features team owns. (Those with little or no dependencies on other teams).

Personally, my experience with trains containing a mix of feature and component teams has been that you wind up with features which are "rocks" and "pebbles".  Those features which span multiple teams for delivery tend to be the rocks that dominate your PSI plan.  Once you have these, you find the more contained "single team features" become the pebbles that are slipped through the gaps in your PSI left after the rocks.  Making sure you bring a mix of "rock and pebble features" into the PSI priority list is the first enabler, and adjusting your breakout structure can become a huge time saver both within PSI planning and execution.

What's next?

Sunday, January 26, 2014

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?

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?

Saturday, January 11, 2014

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?

Tuesday, January 7, 2014

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: