The below article is adapted from our recent PI Planning webinar.
PI Planning is a core mechanic within SAFe; it’s one of the few things that SAFe does that is unique to it amongst all the other scaling frameworks. This series of articles explores how to approach PI Planning in a way that preserves agility and empowers the teams.
The first article covered Principles and Preparation. The second article looked at the PI Planning Event, part of which involves retrospecting and adapting the process…
Retrospect & Adapt
No process will be perfect, retrospection and adaption is a necessity; but here be dragons!
Be wary, it’s very easy to inspect and adapt away from the fundamental principles if you don’t understand the principles that form the foundations of PI planning which is why they were covered in the first article.
Too much preparation
Too much preparation is bad.
Figure 1: Positives and Negatives of More or Less Pre-Planning
The reasons shown here are taken from an exercise in a recent RTE course. To summarise…
If an Agile Release Train over prepares, if the problems posed in the Features have been solved before PI planning, then the teams will stop thinking for themselves, they’ll just sequence the work and complain that planning is boring. Team will struggle to ignore sunk costs, the effort involved in developing the plan upfront, they’ll defend their plan rather than accepting change when other teams come along with requests for help. Finally, all the upfront preparation is happening at a point in time where it’s eating into the delivery of the existing plan and happening at a point in time where it’s hard to collaborate with other teams because the teams aren’t all together in one place.
If we under prepare, if the problems aren’t well described then this will result in more conversations during planning; the very interactions we’re trying to encourage. As long as someone from Product Management can explain the business need then PI planning will work, and I have participated in planning events where the features are nothing more than a few words on a post-it and a very knowledgeable product manager. The plan is being made in-the-moment, there is little to no sunk costs, changing it is considerably easier.
In reality it’s not a simplistic over-preparation or under-preparation, it’s doing the right preparation. That left hand diamond of design thinking is our guide, Features are business challenges to pose the teams that then come up with the engineering solutions. From the perspective of the Business represented by Product Management, the right preparation is understanding the business need to be able to explain it to the teams, to help them understand when they’ve created a sensible solution. From the perspective of the Teams the right preparation is to ensure that they have the skills, or can plan to gain the skills, to be able to solve the problems being posed to them by the business, the competence pillar from David Marquez.
Why pre-empt?
The desire to over prepare is a symptom. Doing more preparation is a solution and we might be solving the wrong problem, we could break out the old “Five Why’s” technique to try and find a root cause…
Figure 2: Why Do People Want To Pre-Empt PI Planning?
Why do teams want to over prepare?
Trying to pre-empt planning?
Why are they trying to pre-empt?
Scared of uncertainty and want to have solved all the problems in the features in advance.
Why are they scared of uncertainty?
Historically they may have been punished for being wrong, that needs to change, psychological SAFety is a key part of the generative culture we’re trying to encourage.
They may lack the knowledge often because despite being employed as engineers they’ve traditionally been treated as glorified typists and expected to just enact the solutions handed down rather than learning how to solve the problems themselves.
There may be the desire for the perfect plan. The aforementioned historic punishment might be one reason for that, another is often that there is no slack. Demand significantly outweighs supply and to be in with half a chance of meeting the management’s unrealistic expectations the plan has to be perfect.
Why the unrealistic expectations?
Lack of management understanding, either in what the processes are capable of or perhaps sensible data to show what teams are actually capable of. Lack of understanding is one reason the right metrics aren’t being gathered. Lack of investment in infrastructure, process and tooling due to a lack of understanding about the necessity of maintaining the machinery of development lest it seize and then nothing is delivered.
Sometimes the desire to pre-empt planning is because of a desire to squeeze planning into a single day.
Why do you want to squeeze it into a single day?
Often PI Planning is not perceived as valuable; but just a single day of executing a bad plan will cost more than an extra day of planning.
Squeeze planning into a single day and you lose the time for negotiation, the management also lose their steering point that is the management review. They no longer have the ability to influence the planning, to provide feedback before the final plan review.
Why?
Probably a lack of understanding. Not just of the process but why the process does what it does.
You Can’t Get Ahead Of A Cyclic System
Figure 3: You’re eating your tail
You can’t get ahead in a cyclic system, you’re just chasing your tail.
Teams forget they are in a cyclic situation. Trying to pre-empt planning and solve things upfront is just eating into the delivery of the current plan and making it unpredictable. Why not use the planning process to plan how you intend to solve the problems. It’s getting over that perception that the plan has to be perfect and contain all the answers.
Need a big architectural discussion, stick a story in the plan, negotiate one into the system architects plan. Discover the answers as you go.
Need to do some research, build a prototype, stick a story in the plan to get the answers.
Need to gain new skills to prepare for the future, stick some stories in the plan.
You’re planning to solve the problems,
don’t solve the problems in planning,
or preparation for planning.
Close the retrospective loop
Retrospectives turn bad very quickly when you don’t see anything come of them therefore it is necessary to close the retrospective loop. Make sure that at least some of the retrospective points are enacted.
Some are easy, “the coffee in this hotel is awful” was fixed by the senior Business Owner turning up with two Nespresso machines and a bag full of capsules at the next planning event.
It is more challenging when the changes are happening behind the scenes away from the eyes of the engineering staff on the train. An example of this would be “better formed features”, this is often done by the Product Management, Product Ownership team away from the eyes of the engineering staff. It might be necessary to take a little time at the next planning event to let the engineering staff know that the product management have “tried to improve features, please give them more feedback.”
The retrospective loop has been closed, the hidden changes made visible.
Maintain Synchronisation
All the planning events happen in parallel. This is important, it allows one train to negotiate work into another just by calling them up and negotiating it into the other train in real time.
Sometimes there is a desire to stagger the planning so that stakeholders can attend more than one planning, but this causes problems when trains interact. The trains that plan first end up imposing their commitments on the trains that plan later, and those latter trains have no way of negotiating back because the planning has been done and the plan committed. All the latter trains can do is suck it up and deal with the imposed work.
[click]
It doesn’t promote autonomy and it gives SAFe a bad reputation because the empowerment SAFe promised hasn’t been granted, although that’s not the fault of the framework but the fault of a bad implementation.
Line everything up and learn how to decentralise decision making.
Dispersed and Distributed
Dispersed and Distributed planning a is a big topic in it’s own right. It has it’s own serise of articles that approach it from the perspective of the probems that need to be solved, before suggesting potential solutions.
Conclusion
15 years of accumulated experience at PI Planning distilled down into a few short words. Hopefully the series of articles has peered behind the “What to do” and seen some of the “Why it’s done” so that when you come to interpret the process to suit your particular environment you know how to interpret them sensibly.
PI Planning is neither Agile nor un-Agile, it’s as Agile as you want to make it.
Planning is after all, a human activity, done by humans for the benefit of humans, and Agility is a human behavior not a process.
Interpret the processes wrong and you will compromise the ability of the individuals involved to display those Agile behaviors.
The processes have to be left open to interpretation because every organization and the challenges they face are unique and those process need to be adapted to that uniqueness.
Finally, remember that this is our interpretation, you may interpret PI Planning differently and still maintain agility, there is no right way to do PI Planning.
Acknowledgements, etc…
There’s a list of people as long as my arm that should be thanked, most obvious being my fellow consultants at Ivar Jacobson International who have either directly, or indirectly, provided insight and assistance at PI planning events, notably my co-trainers Ian Spence, Keith de Mendonca, and Marika Zep, and fellow facilitators Michael Flynn and Averil Franklin Stewart.
I also need to acknowledge a debt of gratitude to all the participants in PI planning events over the years; it’s been a constant learning experience, both good times and bad. Somehow, PI Planning has always worked, it’s always produced a plan, the credit there has to go to the participants. Was the plan what the business wanted? Sometimes the business didn’t know, but you can’t blame PI Planning for a businesses lack of vision.
Training & Support
If you’ve never done PI planning before it’s a daunting task. There is training to explain what’s happening, but for many some guidance to steer them through their first PI Planning event is very useful. You want people that have done it before, seen the situations, that know how to read the room. There aren’t many consultancies with comparable length and depth of experience.