Contact

Preparing for PI Planning - Saying No to Waterfall Thinking

Part 1. of the Preparing Features for PI Planning Series.

by Ian Spence - IJI’s Chief Scientist, SAFe® Fellow and SPCT

The Danger   -  Waterfall Thinking versus Just Enough, Just In Time Is Actually Very Little

A lot of work goes into the continuous refinement of a product’s backlog. This is true as much for Feature Backlogs as it is for Story backlogs.

When using SAFe® if it often seems that too much work goes into preparing the Features and getting them ready for PI Planning.

PI (Program Increment) Planning

PI Planning is the key event in encouraging true agile behavior in SAFe®.

It is a whole team event where the whole program - the set of smaller agile teams working closely together as a single team-of-teams - come together in a big room (hence it is often referred to as Big Room Planning) to agree a plan for the next 8 – 12 weeks.

The goal of the event is to create alignment, encourage collaboration, enable self-organization, eliminate waste and exploit the synergy between the teams.

It is the beating heart of the agile release train and any SAFe® implementation.

PI planning is intended to be a highly collaborative event where teams take ownership of the suggested Features and work with their Product Owners to identify, estimate and elaborate the Features and their Stories.

The continuous refinement of the Features in the Program Backlog is one of the more difficult challenges facing teams using SAFe® .Priorities are constantly changing, and new customers and new Features are emerging everyday all whilst the existing Features rot, progress, morph and run their course. The classic INVEST (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable) acronym and 3C’s (Card, Conversation and Confirmation) technique apply as much, if not more, to Features than they do to User Stories. The time-boxed nature of the Program Increment means that Features that are too large have to be sliced so that they 1) will fit within the PI, and 2) will flow properly through-out the PI’s iterations and not all be delayed to the end of the time-box. The Features themselves need to be clear, feasible and testable.

Bearing all this in mind one of our favorite Product Managers went into his first PI Planning session with literally just a set of cards each of which briefly described one of the hoped for Features using the format shown in the images right..

He was happy to negotiate the scope, stories and acceptance criteria for each Feature on the fly, with the teams as the Features were pulled.

The end results were high levels of collaboration, empowered teams taking full responsibility for the delivery of their chosen Features, a robust plan, and ultimately the delivery of the team’s first viable release. At the end of the PI they achieved over 80% of their agreed objectives; a fabulous outcome for any team-of-teams’ first Program Increment.

Compare this with what happens when teams invest a lot of time in the up-front preparation of their Features; creating long lists of Stories for the teams to do, and consequently high levels of expectation about who will do what and when. If you go down this path it is easy to put the team into a downward spiral where the problems reinforce themselves and lead to everyone falling back into their old ways-of-working.

If they are not careful, they will end up on the “downward spiral of waterfall thinking” - see the image to the side and make sure you don’t recognise your teams here!

Waterfalling your Features can cause on-going team problems

Examples are:

  • Pressure to conform: the team immediately feels that their job is to just accept the stories as written and deliver them all, even if they think they are wrong, un-needed or just plain stupid. Alongside the list of Stories comes someone else’s estimate of how big the Feature is. The team now feels under even more pressure to conform delivering exactly what has already been defined exactly when it was predicted. This pressure compromises any plan that they produce and prevents them from truly committing to the plan as it feels like someone else’s plan.
  • Lack of ownership: when presented with what appears to be the definitive set of Stories for a Feature the teams don’t take any ownership. They feel that their job is to just do what they are told and implement all the stories regardless of whether or not the Stories identified for a Feature make any sense at all.
  • Disengagement of team members: When teams take full ownership of a Feature and brainstorm the stories with their Product Owner everyone is energized and involved. When the stories are presented to the team as a polished pre-defined list it appears as a ‘fait accompli’, which leads to the team disengaging and just going through the motions. The planning events quickly become boring administrative events that the team members would like to avoid. A clear signal that this problem exists in your teams would be if teams suggest in the retrospective that it would be ‘more efficient’ if the whole team no longer attend future PI Planning events.
  • A handover mentality; The product management team turn up with a list of related stories that they handover to the teams to be implemented. The teams then go off and work in isolation until all the stories are done and the completed features are handed back for acceptance. This mentality affects both the planning event itself and the development Sprints: Features are treated as all or nothing elements where every story must be completed before the feature can even be demonstrated, let alone accepted.
  • Predictive rather than adaptive planning: one consequence of pre-defining all the work to be done is a regressive tendency to fall back on predictive planning with teams being assigned work to be completed at specific times rather than adaptive planning where teams pull the work and do just enough planning to be confident in making their own commitments
  • Dependency rather than collaboration: one of the goals of PI planning is to get the teams collaborating to increase the program’s flow and their own effectiveness. Where the stories are defined up front teams generally collaborate a lot less, often accepting pre-defined dependencies rather than working things out for themselves.

……..In our experience it is actually better to be (slightly) under-prepared.

Allow the teams to work through any problems during the planning event rather than trying to pre-empt them.

Over-preparation will leave the teams wondering why they have had two days of their lives stolen to listen to other people present their work and their plans, and to tell them what they have already committed the ‘empowered’ teams to deliver.

The classic mistake is to hang onto the waterfall mindset and think that by doing more and more preparation you can make the planning event itself more effective.

Even if you get the whole team involved in choosing their Features and then preparing Stories before the PI Planning event - you still won’t avoid all of the problems outlined above. At best all you are doing is moving work out of the planning event to sometime before it, at worst you will end up compounding the very problems you were trying to prevent. In either case the potential improvement is negligible and out-weighed by the risks of doing damage.

It may seem counterintuitive but one of the secrets of SAFe® is that the better you get at SAFe®, and at PI planning, the more you can trust the teams and the less preparation you need to do.

In this first blog posting we have described how and why you should resist the temptation to over-centralize detailed analysis, or the temptation to complete a detailed preparation of stories prior to the PI planning session. In the next blog posting we will specifically focus on the seven deadly sins of feature preparation.

Preparing Features for PI Planning Series

Part2. The Seven Deadly Sins of Product Management

Contact Us