“That’s SAFe!”

In the TV quiz show Bullseye, at the climax of the show, contestants had to choose to gamble the prizes already won on a chance to win the big prize.

It was a big decision under pressure, but in order to reassure the contestants, every week Jim Bowen (the host) would say to the contestants “The money you won earlier, that’s safe!”

In this blog we will look at how the gains you’ve already made adopting Agile practices can be kept safe, while scaling up those same practices to make your organisation truly agile.

At Microlise we are using Scaled Agile Framework (SAFe).  SAFe is one of several frameworks now starting to gain ground. In my first blog I talked about how Agile has moved from a fad to established engineering practice. We now have large organisations with hundreds of engineers all working to Agile practices and we need a way to co-ordinate their efforts. This is what Agile scaling frameworks all try and achieve, whether its Disciplined Agile Delivery (DAD), Large Scale Scrum (LES) or SAFe (These are the current market leaders, there are many others out there).

Before I go on I would like to draw your attention to the Agile manifesto. The first line is “Individuals and interactions over processes and tools”. Scrum, SAFe etc are all processes. The Agile manifesto values personal interactions over processes. But it doesn’t say no process. What it is saying is it’s important that we don’t value our process over personal interactions but rather our process enables these interactions. This enablement is what any scaling framework should be offering.

But why do we need to use SAFe, LESS, DAD etc at all? In our ideal Agile model of an organisation we don’t. Mike Cohn would maintain we just need to do Scrum well and Allen Holub goes further to suggest that even Scrum is anti-agile. Many of the leading proponents of Agile believe it is pointless trying to scale and the moment you do, you introduce friction into your process and you are no longer Agile.

But our organisation is on a journey to true Agility and right now we have multiple teams working on the same product, we need to co-ordinate our efforts to achieve maximum business value. Organisations undergoing transformational change programmes  need a safe (not SAFe) way to move from where they are now, with Agile practice localised to engineering, to a truly responsive Agile organisation responding to customer need. That’s where SAFe for me in particular is useful. It provides reassurance to the business because SAFe, on the surface, looks like what they already do.

SAFe is the framework we are using here at Microlise. It allows for organisations to spread Agile practice beyond engineering throughout a whole business. As with Scrum, SAFe is a framework and how we use it is up to the organisation. We must use this process as a way to cement truly agile ways of thinking not just in development, but across all parts of the organisation. In fact SAFe, for those who are struggling with organisational changes, offers a great implementation framework for moving to an Agile release model focused on value.

For me, one of the powerful elements of SAFe, as with the TV game host show, is it provides a reassurance. Yes this is hard, Agile transformation is always hard regardless of the size of your organisation. But SAFe out of all the frameworks looks a lot like what many people outside engineering are already doing. SAFe explain how you can progress your Agile journey. Training centres on how to introduce Agile practice in to an organisation, not just SAFe. It talks about a kaizen mind (restless improvement) and becoming a learning organisation. All of these will help you move beyond any framework and move to a truly Agile mind set only doing things that deliver value to your customers. In the meantime your current practice is in the words of Jim Bowen “SAFe“

Foot note: Mike Cohn himself outlines a scaling framework we might not want to follow, LAFABLE (Large Agile Framework Appropriate for Big Lumbering Enterprises) It is a good example of how a Framework can get out of hand and quickly lead to anti-Agile ways of working. If this looks like your current process then you have some work to do.

 

Share this: