5 tips for scaling delivery using SAFe

Earlier this year, I upgraded my SAFe certification to SAFe 5.0 to take into account the change of the framework to encompass business agility and the need for businesses to transform the way they work so that they can adapt rapidly to the market and environmental factors.

The introduction of new competencies and other changes around customer centricity is well worth a read if you haven’t already done so (link in the comments below). As Mik Kersten says “Those who master large-scale software delivery will define the economic landscape of the 21st century.”

Whilst Scaled Agile publishes an adoption pattern for implementing SAFe (link in the comments below) it is still very challenging as you need to change an organisation’s culture and ways of working. I’ve experienced the challenges that organisations have in moving from pockets of agile delivery to having the right culture, leadership, delivery approaches and organisational models to deliver high-quality innovative products and services of value to their customers.

It is often useful of course, to marry the theory from a framework with practical guidance built on experience. I had the pleasure in attending a business change and agile transformation event recently where the experience of scaling to SAFe at Vodafone was shared, and I took away the following five tips.

1. Have a good Agile delivery base to move from when you recognise your “Go SAFe” moment. You need to already have agile delivery teams who are using Scrum / Kanban, have good software engineering practices, have a single common backlog and standard roles around delivery and product management. For Vodafone, they already had agile delivery teams and their tipping point came for one particular project which took 2 years to get through Gate 2 in order to get budget approval.
2. Lead from the top and create an “umbrella of safety”. You need, from the senior leadership level, establish, communicate and truly believe in the future vision of moving to scaled agile delivery in order to win “hearts and minds”. Senior leadership will need to act as change agents and a number of people will need to undergo the Leading SAFe training. Vodafone sent all their leaders and product owners on training as the first part of their adoption of SAFe. Their agile teams additionally did the Implementing SAFe course. They also recognised that they needed to protect the first project moving to SAFe from the existing traditional hierarchies and processes through creating a bubble of separation to allow things to work differently.
3. Balance the need to prepare for the ART and actually getting into PI Planning. Getting the Agile Release Train (ART) ready involves a number of different activities including planning, setting up the teams, training them and assessing whether you are ready for launch. For Vodafone, building the single common program backlog was key to establish what features, NFRs, and technical work was needed. However, they also balanced the need to get this perfectly right ahead of actually launching the ART through the PI planning event and getting started with delivery.
4. Invest in tools and coaching. Planning, delivery and engagement across teams, business owners, product management and vendors requires a number of different delivery and collaboration tools. One of the lessons learned at Vodafone was that they needed to put a lot more effort into Jira, for example, in terms of governance and process to really see the benefits of moving to SAFe. They also recognised that for they needed external help in the form of coaching from a SAFe Program Consultant (SPC) to get ready for the ART and the first PI planning event.
5. Break the rules but keep key ceremonies. SAFe is a knowledge base and repository with lots of guidance on what to do when implementing the approach. As Vodafone started their journey to implementing SAFe over 3 years from the single project that kicked it all off, they recognised that they could break the rules and adapt what worked for them organisationally. However, key aspects they never changed were the PI planning event, releasing on demand, and doing demos of value that were integrated across the teams.

I hope you found this useful, if you have any tips you’d like to share please do so in the comments below.