SAFe: How I learned to stop worrying and try the Scaled Agile Framework

New Thinking 19 October 2015 Jacob Creech

The Scaled Agile Framework (SAFe) seems to be one of the hot topics in the Agile community these days. Love it or hate it, everyone is talking about it.

There is a huge range of opinions in the community ranging from Ron Jeffries’ ‘SAFe: Good But Not Good Enough’ and Ken Schwaber’s ‘unSAFe at any speed’ to Lyssa Adkins’ ‘The Agile Coaches’ Coach Shares Her Views On SAFe’ and Al Shalloway’s ‘Why Net Objectives Supports The Scaled Agile Framework’. 

I won’t enter into the debate, but I will share some of my experiences as a practitioner who has helped introduce SAFe (or at least some practices recommended by SAFe) in multiple organisations with hundreds up to thousands of people (including some of the largest SAFe transformations to date), in collocated and distributed environments.

Suffice to say, I have a reasonable perspective on SAFe in real life, which I prefer to the typical theological debates that arise when SAFe is discussed. I also have experience with LeSS and the Spotify Model which I’ll address in a future post.

In the interests of transparency, I’m a SAFe Program Consultant (SPC) and a candidate to become a SAFe Program Consultant Trainer (SPCT). I’ve also spent probably half of my time over the past few years working in SAFe environments. However, entirely superseding this, is my pragmatism and belief in finding the right tool for the right job. It’s from this perspective as a pragmatic (rather than dogmatic) Agilist that I’ve approached this blog post.

The current situation

Agile has been growing in popularity for a number of years; Scrum, Kanban, XP and other Agile methods – while still not necessarily the default methods for managing and improving software projects – have certainly risen in popularity and application of these methods is continuing to grow at a rapid rate.

There are now over 300,000 Certified Scrum Masters (just one indicator) listed in the Scrum Alliance member directory, up from 100,000 in 2010 and just 3,907 in 2005. It’s safe to assume there are many more Agilists out there who haven’t undertaken certification or chosen an alternative like ICAgile

Problem: Lack of alignment (particularly as we scale)

Solution: We start with a group of senior leaders who define strategic themes – specific, (but large-scale/long-view) objectives for the business. Based on the priorities we have as a business, we develop lightweight business cases (essentially portfolio epics) which we then prioritise and validate through a Kanban system.

Once we’ve validated these ideas (and bearing in mind there is a great talent in being able to say no to avoid wasteful work), we then feed them to our delivery teams, arranged in teams of teams, known as ‘release trains’. The great thing about these trains is they work on a regular cadence so, if we miss the current train, we can always hop on the next one.

When the work reaches our release trains, we break it down into ever smaller pieces from Epic to Feature, from Feature to Story and Story to Task. However, the relationship between these smaller pieces to their parents and grandparents will always remain. For the senior executive, they can see the progress of the overall Epic, simply rolled up from all of the smaller pieces below it. This is incredibly transparent for all of those involved.

As work is introduced into our release trains, there is also a briefing from the senior executive responsible for the Epic, as well as the product management group that guides it through to delivery, explaining the ‘what’ of work to completed and ensuring the delivery teams have the context surrounding the work, that they can understand the purpose of what they are delivering and understand how it fits into the bigger picture of what the business is trying to achieve.

Problem: Lack of management support

One issue I’ve frequently encountered is resistance to change from (middle) management. This stems from a range of different issues, but the most common reason is they don’t see how they fit into the Agile model and are often told they’re no longer needed.

Solution: The role of a (good) manager is essential in Agile. However, their role and responsibility may be different to what they may be used to. SAFe mandates training of and guidance for ‘Lean-Agile Leaders’, who – with some support – should exhibit the following:

  1. Lead the change: Act as a change agent, explaining the value of change and helping resolve issues that prevent teams from achieving success
  2. Emphasise life-long learning: Creating and fostering a continuous learning, continuous improvement culture. Enable people to solve their own problems. Support teams if/when they make mistakes so they can grow and learn
  3. Develop people: Help develop the skills and career path of your team. Help the team realise that they fail or succeed as a team. Enable great people and they’ll achieve great results
  4. Inspire and align: Minimise constraints. Give people context. Then get out of the way and empower them to achieve great results
  5. Decentralise decision making: Take responsibility for the decisions that need to be centralised and communicate that information. For everything else, enable the team to make the right decisions locally at the right time
  6. Unlock intrinsic motivation: Based on Daniel Pink’s work, motivation comes from three key areas – Autonomy, Mastery and Purpose. Create an environment that supports this, gives people context and enables them to develop, improve, learn and achieve great results

Not every manager is a natural fit for this new way of working, but when they can understand how they fit in, they’re certainly more open-minded. Giving them some context and providing the support to help them develop makes for a lot more supportive environment – not just for Agile but, more importantly, to develop truly high-performing teams.

One example of this I encountered was on a large (3000 people-plus) transformation. The senior executive had decided Agile was the way to go and the development teams were very keen as they’d been frustrated with the previous waterfall process. However, the middle management weren’t consulted on, or even involved with the process. They were simply told ‘Tomorrow we will become Agile. But don’t worry, it doesn’t involve you…’. For the team members, it was very confusing as they ended up reporting to multiple different managers – people managers, dev managers, QA managers etc. And for the managers, they couldn’t see or understand how they could fit in.

We employed a combined training and coaching approach – first, introducing the new role of ‘Lean|Agile Leader’ in SAFe, and then working with the managers on a regular basis to help them understand how to fit into this new role and how they could maximise the value that they delivered. We introduced them to a roadmap that they could then use to help their teams on a path to mastery. We helped them discover the larger picture that their work fitted into and share that content with their teams – providing context and purpose for what the organisation was really trying to deliver.

With this new focus on mastery, with freedom to deliver great work and the purpose of what it was trying to achieve, great results quickly followed. The vast majority were very excited with the new role and the impact on the team members was significant; staff turnover was greatly reduced and team engagement increased but, more importantly, people were happier and the quality of the work delivered was higher. A great result.

When good managers see the results they can produce, buy-in can be very rapid. My real life experience shows those managers who feel disenfranchised are particularly quick to get on board because they can see that these changes make a real impact.

Problem: Confidence in methods for scaling Agile / concerns about the ability to scale Agile

Solution: Love it or hate it, SAFe has produced some pretty compelling case studies that make it much easier to bring into large (political) organisations.

I’ve seen first-hand where organisations increase quality (defects down by 80%), speed (delivery time down from 3+ months per release to daily or even continuous releases), staff engagement (as shown by NPS scores) and all-around mojo (based on an intangible, happy feeling).

SAFe is (relatively) simple to understand, provides enough guidance for large enterprises to feel comfortable to try, has enough of a track record that isn’t career suicide to adopt and is widely enough spread that they can find the people with the right skills to help them scale up successfully wherever they are in the world. All of that helps provide confidence in the approach.


SAFe is a highly configurable blueprint that can be used to educate at all levels of an organisation and give confidence to introducing Agile at scale. With scaling at its core, it exposes common anti-patterns and helps resolve commonly encountered dysfunctions and problems.

Given that every large organisation has different challenges and opportunities, there will be inevitable tweaks that need to be made to achieve optimal results – but SAFe is, at the very least, a very helpful starting point for scaling Agile and, for many organisations, a very useful step on the path to mastery that provides strong guidance on how to begin achieving great results.

In order to get started with Agile though, many organisations I’ve worked with have found great success starting one team at a time. Work with that team until you get it to a good level of performance and solve the kinks that get in its way. Once you reach a good level, add a couple more teams and see how having a few teams works for you. Again, solve any issues that pop up. Once you reach this level you can then start looking at SAFe. It may be, in your circumstance, that adopting one or two SAFe patterns will get you where you need to be – release planning or a system team are often very helpful at this level. Do what works. Let it scale organically and bring in SAFe when it makes sense for you.

To quote Dean Leffingwell, don’t scale crappy code. The same is true with Agile teams. You need to get the foundations right in order to scale successfully. Be prepared to address systemic issues and have hard conversations with different people in your organisation. Remember, good things take time; put in the hard yards, build a solid foundation and you can achieve great results. One step at a time.

Find out more about our Agile services.