This is something that I’ve been thinking about over the last several years. After experiencing / running some of these events and having seen them played out with various clients I had an instinctive reaction as to the waste behind PI planning. I haven’t had the full language to express exactly the problems with this and how it fits into the overall organisational maturity and growth up until now. Recently, I attended an Okaloa flow simulation on multi-team flow and after stewing on the insights from that for a week or so, whilst planning an inception (I didn’t want to use the PI planning words), I realised a number of connections that I’d like to share with you.
Firstly, as if to contradict what I’ve just said above, even though PI planning is ultimately waste, it can be a useful stepping stone for chaotic / lower maturity agile implementations. I think this is similar to many things in SAFe – some of the practices are useful to begin with, the painful part is when they get hardened and become the norm rather than looking to rise above and find better ways to work. Let’s consider some of the useful points of PI Planning first:
- It gets alignment (across leadership and teams)
- It gets the teams to think about their capacity
- It can help bootstrap the upstream (described below)
Bootstrapping Upstream
This is worthwhile expanding a little. For some teams, they haven’t yet developed or seen emerge Upstream Kanban. The PI Planning event can actually help bootstrap this if it isn’t there. However, often many agilists (yes, even those who consider themselves coaches!) don’t have knowledge of Upstream Kanban, so they miss the subtleties that occur upstream and how it is different to delivery. What is important to understand is that work flow through your overall system – some aspects prepare work for delivery and discard poor options, whilst others build / deliver it. Where flow doesn’t exist, the PI planning event (being large and expensive) creates an impetus to make sure “features” are prepared enough to run through during the event. Often what happens is that during PI planning teams commit to features to deliver, but also determine which features they want to “shape up” for the next event for delivery. This is one of the downsides if you’re not careful – it locks you into a 6 month lead time for features (is this agile!?!). But importantly, teams are concurrent thinking of getting items ready whilst they’re delivering other ones.
Where PI Planning comes unstuck
One of the key parts of where this comes unstuck is that this is usually held every three months. That’s problematic because what occurs at this time is that teams align and commit to a number of work items every three months. The result is that you essentially only get 4 of these per year. Is 4 points per year to plan / change course agile? This is really a large batch transfer that get’s underway and it undermines the continuous flow that was starting to emerge through bootstrapping upstream mentioned above. Agility comes from fast feedback and having only 4 pivot points per year where you can adjust the work based on feedback is the opposite of what I believe the agile manifesto authors were trying to achieve.
Other examples of where I have seen waste with PI planning is when an assumption during planning turns out to be false. I’ve seen this happen within 2-4 weeks of the PI planning exercise and teams in those instances dove back into a PI planning process. There’s a lot of cost involved in getting these PI planning events up and running – when a few assumptions learned down the track causes the whole process to come unstuck, I’ve got to question whether it is the right process.
Whilst working within a “train” is part of the PI Planning, if you have to synchronise work outside of your train then more coordination is needed. I think this comes down to the mechanistic nature of SAFe itself that denies the complex and somewhat organic nature of the organisational network. Although you may be able to predict the nature of interdependencies and organise around that, there’s always going to be new demand that will create new connections in the organisation that you have to deal with. Now we’re talking about pre and post PI planning events to ensure items are synchronised across streams. Again, these are often large events with a multitude of people involved. A couple of problems with that are that, once again, plans can change and you need an intervening process to keep things aligned once underway. Is there a way to achieve the outcome without the large cost of these events?
One key theme from all of this is that we’re committing too early. Whatever happened to the lean thinking that talks about committing at the “last responsible moment”? Now I’ve heard arguments that PI planning isn’t about “committing” but about planning and that plan will change. However, I don’t think that’s in practice what most people take away from it. Particularly so when teams do the “fist of five” – it seems like they’re “committing to the plan” (although the usefulness and safety of this technique is questionable). Alternatively, this perhaps could be argued to be a reversible commitment – that things later in the planning can change. But what’s not readily apparent is the abort costs and other potential waste of this behaviour.
If we were instead to defer commitment until we have capacity to be able to fulfil the order / option, then we have greater flexibility to deal with unexpected events with greater clarity for all. Oftentimes, we see urgent work enter the system after PI planning – this causes other work to either be paused, postponed or even aborted. All that time we spent planning and now we have to replan for this new item. We also have to reset expectations about when those other items will get delivered. Perhaps we shouldn’t do such detailed planning for items down the road, perhaps there’s another way to schedule / commit to work.
Alternatives
Replace “Plan” with “Forecast”
I think that the word “Plan” inherently has issues with it. When people hear the word “plan” the often associate it with a commitment. This gets the expectations around the event confused and misunderstandings will arise. Instead of using “Plan”, use the word “Forecast” and give a likelihood of something being done. For example, say something along the lines of “on average our features take 65 days to deliver, and we can deliver 90% of them within 110 days”. Note the difference between the average and the 90th percentile – it allows for the potential that an urgent item might slip into the flow and delay it – and there’s also a chance that it can take longer. This also requires teams to capture some basic flow metrics – again something else that might need to be bootstrapped through the process before you can rise to this next level. However, this gives stakeholders a much clearer understanding of when something will actually come their way.
Enable flow
Once the upstream has been bootstrapped, you can start to move away from the “stop/start” nature that tends to occur with PI Planning. This tends to be more of a batch transfer than flow and will start to impact the organisation’s real agility. Start to look at your flow and impose some WiP limits around the parts of the process – batch transfers happen when there are no WiP limits around those parts. Doing so will create a more sustainable pace for your teams and allow you to defer commitment until you need to make those decisions.
As your deployment practices mature, you’ll find that you’ll be able to start to deploy on demand. It begs the question why you can’t replenish on demand in the same way. Why would you want to wait for the 3 monthly cycle to pull new work in? The answer is that you probably shouldn’t – the problem is that the transaction costs of replenishment via PI Planning are now too high, so it’s probably best you avoid those costs and find a better way.
Continuous improvement inherently built in
One of the other problems with PI planning cycle is the “Planning and Innovation Iteration”. This totally goes against the ideas of flow and continuous improvement. Using the last iteration of the PI for this is inherently bad. What tends to happen in practice most times is that this gets left out when initiatives run into risk / dark matter expansion and have to fill it with work anyway. Also, leaving all innovation to one single point in time seems contrary to how innovation actually works.
Instead, plan in time along the way to do the preparation of new items and to include innovation as a matter of course – part of the weekly workload. At the team level, you can allocate capacity to intangible class of service items on the board to cover off innovation items as they’re needed (usually it’s own card colour or swimlane).
Tokens guide capacity
An alternative that was made clear to me through Okaloa flowlab simulations, was that you can use tokens to guide capacity and commitment. Teams understand how many features they can build concurrently and offer that many tokens. Let’s say it’s 4 concurrent features. They work on 4 features and when one is done, they have a free token. This token is then available for new commitment. When a new feature is ready that requires the token (usually it needs tokens from a few teams) that new token can be allocated to the feature and it can be started (once tokens from all teams required are available).
This is a simple solution to allowed deferred commitment and reduced transaction costs from PI planning and will ultimately help the agility of the organisation. Oftentimes, teams in SAFe style arrangements don’t have a very good understanding of their capacity – or they have to do lots of estimation and need other details to understand it. The tokens provide a simple way to understand capacity without the need to go into detailed estimation.
Conclusion
PI Planning builds in large transaction costs and creates batch transfers which are waste. Both of these effects can impact your organisation’s agility in the long term. These events can be useful in the short term to provide alignment and help bootstrap flow. You should avoid hardening in such costs and anchoring your agility and instead take it to the next level by concentrating on how to enable real flow in your organisation. There are other alternatives and you should look at how they can be implemented to help your people, your customers and your organisation’s strategic objectives.