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 :)

Coaching, Training and Change

I train, I coach and I facilitate.  At any time all three skillsets are at play, but the blend and balance varies.  Over the past year, I have become increasingly focused on mindful selection of that balance to suit the context.

In 2011, I delivered roughly 70 agile courses for an organisation embarking on an agile transformation.  Whilst it was rewarding to help so many embark on their agile journey, I became increasingly frustrated with being unable to accompany them.

Eventually, one of the groups I had trained engaged me as a coach.  It was amazingly fulfilling to journey with people, but I started to gain a new appreciation for the training room.  Whilst coaching enriches insight through context, breakthrough thinking occurs at a very different pace and magnitude.

In recent months, I've been balancing both training and coaching.  I've realised that I enjoy both and want to pursue an ongoing balance, but it's also provoked much thought about their respective roles in learning and change.  The recurrent themes are questions, answers and context.

For me, coaching is all about questions.  My coaching motto is drawn from Jerry Weinberg's "Secrets of Consulting":

"Your ideal form of influence is first to help people see their world more clearly, then let them decide what to do next"

This leads to a life of questions.  Questions for myself regarding the best models and visualisations to reveal new insights for my customers.  Questions for my customers provoking new perspectives as they seek answers.  Questions from my customers about when I'm going to start providing answers instead of questions :)

Training, on the other hand, is generally about answers.  My focus is providing answers and helping my customers internalise them.  The goal is to provoke questions about how they will take these new insights back to their own context.

As a coach, I constantly have to remind myself that no matter how clearly I believe I can see "the answer", the only answer that matters is the one my customer can see and believe in.  My hunt must inexorably be for the right question to which they can provide their own answer.  Being able to just pour new thoughts out in the training room is almost cathartic, but it can feel like a guilty pleasure as you know that most students are just not ready for all those answers.

This duality felt quite incongruent for a time, but Jerry Weinberg's experiential learning series helped me come to grips with it.  Repeatedly, he expounds on the fact that your goal is not to teach "the twenty things you believe your students must learn".  Instead, by providing a rich learning environment you give each with the opportunity to deeply comprehend the three or four ideas that are most relevant to them.  

Whether coaching or training, the innate goal is to provoke meaningful change.  All change, however, involves loss.  To take hold of something new, I must let go of something old - in many cases something I created and felt pride in.  Part of the magic of the training room is the change of context.  Solving a problem through the application of new techniques requires only the loss of the belief that I can copy my existing practices into the new setting.  I thus learn something more easily, and can then choose to bring that new insight (or some portion thereof) back into my own context.

A secret to learning, then, seems to be a simple cycle.  Step out of context, gather new insights, then select which to bring back into context. The change of context often also provides greater safety for shared learning.  A team will generally find it much easier to discuss how they might have worked together to solve a jigsaw puzzle than how they might have collaborated better in a stressful work situation.

This cycle can be utilised either training or coaching.  The difference lies in the depth of the step out of context.  As a coach, you tend to purchase an hour at a time as opposed to the two days you typically have in the training room.  My observation has been that the longer you are out of context the deeper you can journey into new territory.

In the excellent "Switch: How to change when change is hard", Chip & Dan Heath suggest that it is "essential .. to marry your long-term goal with your short term critical moves".  They go on to say "When you're at the beginning, don't worry about the middle, because the middle is going to look different when you get there.  Just look for a strong beginning and a strong ending and get moving".

Through providing many new answers in a new context (the community of the room), I believe training provokes the questions that establish the vision of the future that might be - the strong ending.  Coaching then begins where training leaves off, providing the "in-context" questions that help to find each strong beginning.