SAFe, Safety and Conversations

For the last couple of years, I have primarily been training and consulting to clients interested in employing Dean Leffingwell's Scaled Agile Framework (SAFe).  In recent months, it has increasingly come under fire from the broader Agile community -the favourite theme being "Is SAFe really safe?".  Whilst in some cases I've felt the critiques simply to be ill-informed rhetoric, in others the criticism has emanated from people I deeply respect.

I've struggled with this, not least because I empathise with many of the concerns about it appearing heavyweight and prescriptive.  To be brutally honest, the scaling model I most admire is that of Spotify.  Every article I read or speech I hear about what they have done fills me with awe.

And yet, I feel SAFe has a very important part to play in the ecosystem.  This feeling is based in the fact that there are two completely different types of organisation considering "scaling agile".  The first has started small, nurtured amazing teams and is working to preserve that culture as they grow organically (with that growth most likely being driven by the success of the amazing teams).

The second, however, is already large.  They live in a heavyweight, heavily governed world.  They offshore, they outsource, they rely on enterprise-grade COTS such as Siebel, Peoplesoft and SAP.  Any real problem demands the involvement of hundreds of people.

This second group wants to change, but the "agile conversation" leaves so many questions unanswered that it fails to penetrate to middle and senior management.  Agile teams which get launched are slowly strangled by the inertia of the apparatus within which they are constrained.  The amazing creation that is something like Spotify just seems unattainable.  Glenda Eoyang puts it well in her book Facilitating Organisation Change:

Unless the vision of the future is grounded in current reality, it will not be helpful.  Vision statements that are disconnected from current reality create a gap that is too large to cross.

This, to me, is the world of SAFe.  It provides something recognisable enough to be be "safe" for the organisation to step into.  It begins a conversation, and most importantly it is a shared conversation.  Time after time, I teach courses where the room contains a mix of senior stakeholders, PMO representatives, middle management, senior architects, operations and infrastructure leads.  The framework provides a platform for a shared conversation about how they will change together.

The responsibility, of course, lies in my hands to focus on the principles.  It looks like a recipe, it carries a very real risk of being treated like a recipe (and being destined for a horrible failure).  But, if the principles can shine through and the energy for change can be built the journey of Kaizen can begin .. taking them towards that future world in which they can peel away the structure of SAFe.

My most recent course involved the IT leadership group of an organisation.  They started the course interested in Agile, but struggling to understand how to apply it to their world.  SAFe had looked recognisable enough to motivate them to invest 2 days in learning it.  As the course progressed, it became clear that SAFe would help with some of their challenges .. but equally clear that it was not a "one stop recipe shop".  We closed the course with 10 minutes for each table to summarise their key actionable insights.  My favourite was a graphic rendition on post-its .. presented here with a couple of annotations to augment a slightly out of focus picture.

I don't think I will ever help a client implement SAFe exactly as Dean describes it.  I've never yet met a client or seen a context where it fits perfectly.  But I love it as a starting point - and will close with the immortal words of George Box:

All models are wrong, but some are useful.