Why I Don't Like The PI
Probably the most iconic feature of the SAFe model is the Program Increment (or PI). The PI (for those who have never seen SAFe before) is a larger, release level timebox, usually 4-6 sprints long starting with a 2 day, all hands planning event. The PI is also the feature of SAFe that I like the least. Proponents of SAFe will, quite rightly, point out that the PI planning event is a highly effective way to plan a release and is great for getting a large team of teams aligned and motivated around a goal. And indeed it is. I still don't like them though. As effective as they are, the PI planning session, and the PI in general, have some unintended consequences that far outweigh the benefits.
The goal of agile is to enable organisations to respond to changing conditions quickly and at the team level, for teams to get stuff out to customers as fast as possible. The PI breaks this in a number of ways. It breaks flow into batches, encourages queuing and reduces the ability of teams and the organisation to respond.
The SAFe model has features - a deliverable chunk of functionality - loaded into a release train backlog. Essentially this is a higher level backlog that feeds a team of teams. The teams take items from the feature backlog, break them down into stories and deliver. So far, so sensible. Any reasonable scaling framework will have something similar. The problem with SAFe is that this breaking down of stories happen as a batch. Every quarter (or thereabouts) the whole team of teams stops delivering and spends 2 days planning the next 3 months worth of work.
Why is this a problem? Imagine a new feature that gets added to the queue. It's super important so it gets added right up the top. But no one starts working on it. No one even looks at it. For 3 months. Why? Because they have just started a PI and they only plan features on a PI boundary. So a team may have a number of much less important features in their PI backlog but they have already committed these to the organisation at PI planning so they can't pick up the new one.
This batching of features encourages batch thinking across the whole organisation. In theory, the business should be getting features ready for the next PI during the current one. In practice though, the PI backlog stays empty till a week or so before the next PI planning event, then we scramble to get things ready because we treat the planning process as a batch. No point planning features that won't be started for 3 months so we leave it till the last moment.
Because we are batching, making the PI becomes a big thing. People will fight, lie and cheat to get into the next PI because if they don't, their feature waits at least 3 months for the next one. This brings all sorts of bad behaviours.
The delivery organisation also tends to treat the PI as a delivery batch. Rather than release each feature as it's ready, we batch them up for a delivery at the end of the PI. In fairness, many organisations don't have the technical maturity to be able to release outside of a large batch anyway, but the PI and its associated batch thinking reduces the desire to improve the technology to enable single feature releases.
The batch release mentality percolates down to the team level and gets in the way of the team, limiting its own WIP. How so? Imagine a team with 3 features to deliver for the PI. If we were releasing feature by feature, the incentive would be to start one, finish it, then move to the next, but because we are batching everything into a PI, the temptation is to start all 3 at once and get them all ready for the last sprint of the PI. With the result that we end up with three half finished features instead of one or two finished ones. Because we have made a committed plan a number of sprints ahead, the team is also encouraged to produce what was planned rather than to adapt and produce what is needed.
The PI encourages batch thinking and up front planning. Batch thinking is bad. Up front planning is bad. They are however very familiar activities to large companies. SAFe with its batch planning feels very familiar. The mechanism of planning is a bit different (an all hands 2 day event) but the activity being performed is a familiar one. Familiar or not, it's not something we want to encourage. What we want to encourage is flow.
Fortunately we can. If we allow teams to pull the top item from the feature backlog as soon as they have finished the feature that are working on, and if we limit their WIP to one (or maybe two) features at once, we end up with a system that flows work. The business is encouraged to keep the backlog maintained because things can start at any time. The teams are encouraged to work on one thing till its done, and to produce what is needed, not what was planned in advance. The business can react to changes faster by re-prioritising the feature backlog. By showing that features are done but sitting waiting for a batch release, we start to make a good case for enhancing our technology to allow feature by feature release.
What about the good things we get from the PI event? The alignment, the motivation? These are important and we should keep those parts of the PI. If every quarter the team of teams has an all hands session to hear the vision and strategy from senior stakeholders. If they use that session to get overviews of some of the major initiatives coming down the pipeline, and had the opportunity to workshop some of those major initiatives into features ready to start delivering. And if that session is used to build a backlog of features rather than make committed plans, then we keep the alignment and motivational aspects of the PI but get rid of the batch aspects. The features they workshop on the day go on the backlog to be flowed through the system as normal.
So, let's stop batching and start flowing.