When is a SAFe PSI not a PSI?

Over the last couple of months, I have delivered the Leading SAFe course half a dozen times to a diverse set of companies and audiences.  Whilst some groups had already been investigating SAFe and some were seeing it for the first time, common areas of confusion emerged.

The 'Big Picture' is both a blessing and a curse.  It is wonderful that the whole Scaled Agile Framework can be distilled down to one compelling graphic.  It's also evident from discussion after discussion both online and in the training room that this graphic anchors people's understanding.  Much of the underlying flexibility in the framework is not evident in the graphic and thus missed by those considering implementation.

There is no case where this is so evident as in the concept of the PSI.  It suffers not just from the preconceptions established by the graphic, but from an often misleading name.

The PSI, of course, is the "Potentially Shippable Increment" at the heart of the program layer of SAFe.  It is conceived as a fractal on the team-level sprint, replicating the sprint lifecycle of "prioritise, plan, commit, execute, demonstrate and retrspect" on a program-scale of 8-12 weeks rather than the typical team scale of 1-4 weeks.

What many miss, however, is the motto of "Develop on Cadence, Deliver on Demand".  The PSI is intended to provide a mid-range planning and alignment cadence, not a delivery cadence.  Whilst the principles driving the planning cadence are grist for another post, I'd like to delve here into the delivery cadence.

There are three core delivery models for the PSI:

• Deliver after multiple PSI's
• Deliver each PSI
• Deliver when ready

Deliver after multiple PSI's

Whilst every seasoned agilist shudders at the thought, the reality is that many scaled solutions run 12-18 month cycles prior to delivery.  I often encounter this with solutions involving multiple enterprise-grade COTS applications (eg Siebel, SAP, Amdocs).  Reaching the technical maturity required to economically deliver incrementally on such a technology stack is quite a journey.

In this context, the PSI serves three main purposes:

• Avoids the feedback delay inherent in deferring integration testing by ensuring the features developed in each PSI are fully integrated and collectively represent a "potentially shippable increment" of functionality
• Provides a cadence for mid-range plan re-alignment through the collection of objective, fact based metrics on the PSI boundary
• Provides teams with a middle ground for the size of their backlog.  More than 1 sprint worth and significantly less than 25-30 sprints worth :)

I saw one major project emerge from severe and protracted pain simply by introducing PSI's.  With over 200 people involved, all new to agile, they had run for over a year rarely able to see more than 1-2 iterations ahead and with a massive accrued integration debt.  Further, lack of alignment between team level priorities caused constant rework and delays.  The introduction of 10 week PSI's gave them a vehicle to achieve aligned mid-range planning and progressive integration testing.  Whilst it was still no panacea, the tension level within the program changed significantly, collaboration went up, and they successfully deployed 3 PSI's later.

Deliver each PSI

This is the initial interpretation I see people most commonly make of SAFe, although in reality I've never actually known a train that implemented it.  At this point, of course, the PSI acronym begins to break down.  It is no longer a "potentially shippable increment", because it is in fact a "shipped increment".

The 'big picture' translates perfectly to this paradigm.  I select the features for my next (perhaps quarterly) release, plan, execute, harden and ship.  This model could be quite useful as an alignment tool for companies running enterprise integrated release cycles.  For example, the final sprint of the PSI could be utilised to perform cross-train integration testing before final enterprise deployment.

Deliver when ready

Everybody I speak to at least aspires to this model, and it is certainly the closest to my heart.  The delivery cycle is completely detached from the planning cycle.  Features are released as and when my business/customers are ready.  Of course, at this point the PSI is no longer a PSI.  We are now simply running a planning increment.

Inherently, deployments are something we plan for as much as anything else.  PSI remains a vehicle whereby the top priority features for the train are planned across the teams.  The deployment hardening and packaging activities and their alignment to planned delivery dates simply form a part of the planning.

Your delivery scenario can then be as complex or simple as required.  I know numerous trains wherein some features can be deployed weeknights, some only as part of planned weekend outages, and some only through integrated enterprise releases.

Conclusion

I like to begin with the end in mind.  In this day and age, regardless of scale and technical platform continuous delivery should be the aspiration.  For most scaled scenarios, however, the majority of companies cannot initially do so economically.

SAFe inherently provides the tools for all to move toward this model.  Every PSI, or every train, it should become more possible.  Start with "Deliver when Ready" as your mindset.  You may find another acronym interpretation for PSI helpful to reduce confusion with this - "Program Sprint Interval" has been a useful translation for many I train and coach :)