Unlike many team-based agile methods, such as Scrum and XP, which have little to say about how to manage concerns beyond the immediate product development team, SAFe attempts to turn the whole organisation Agile and Lean in a structured way.

This article focuses on the debate around SAFe, so gives only a brief description of the method – for full details you can consult the official SAFe guide.

In brief, SAFe operates on 3 key levels:

SAFe's Big Picture - from www.scaledagileframework.com

Portfolio: Kanban and Lean techniques are used to map value streams, inform a Roadmap and assemble a prioritised backlog of Business Themes and Architectural Epics to focus investment. These Epics are long-lived and span different releases.

Program: The Portfolio Roadmap informs a Program-level prioritised backlog that also includes non-functional requirement (NFR) considerations and defines Potentially Shippable Increments (PSIs) for each solution. Development is based on a regular cadence with Delivery on demand via an Agile Release Train. Mixing our transport metaphors, an Architectural Runway is progressively built-out to support the solution.

Team: Each team has a prioritised backlog and uses Scrum with a dollop of XP and Agile practices to deliver product increments through a series of Sprints and Spikes which, in turn, are combined with other teams to form product releases delivered as required.

There’s a ton more to SAFe than all this, but that will do for a brief tour.

Criticism of SAFe

So does SAFe deliver on its promise?

I’ll give the disclaimer now: SAFe does bear a striking resemblance to similar structures that I’ve helped create for large organisations. So either both SAFe and I are on the right track, or we’ve still got much to learn. Perhaps both!

There’s been a lot of criticism of SAFe. Many people are upset and don’t like it, I’ll focus here on three key reviews which you can read at your leisure:

SAFe is a re-manifestation of RUP: “The boys from RUP are back…building on (its) profound failure”

The RUP criticism is often mentioned but any similarities it has to RUP (which I find limited) are mostly those that are found in any large enterprise. In other words, SAFe has more structures than something like Scrum because it is working at a bigger scale: it has a different aim.

Like it or not, large businesses have thousands or tens of thousands of people that need to work together effectively to deliver products and services. I’m not just talking about software development here – there’s a much bigger picture and larger group of people who need to work together. Scrum can work well with dozens or a few hundred of (typically mainly) software people, but beyond that? – and it doesn’t say anything about wider issues beyond team-based product development.

There’s a key choice here: do you believe in large businesses or not? Those that don’t will always advocate methods suited to small and medium-sized groups. But those that do need something they can use and SAFe is trying to fill that role.

SAFe is over-complicated and comes with a tool (Rally) and consultant dependency

Is it over-complicated? The articulation of the Big Picture on a single slide suggests not – it actually tells a relatively simple story with considerable detail.

Does it build a dependency on a tool vendor and consultants? Well, I’ve yet to see an agile team of any size that didn’t have a dependency on tools and consultants or coaches. Whatever your opinion of Rally (mine is mixed), this is a red-herring.

SAFe is a one-size-fits-all solution

SAFe can indeed appear as a one-size-fits-all solution.

But that’s because it is providing a template, a starting point that people can relate to. That’s necessary.

Experienced Agilistas who are so familiar with Agile values and principles, often forget that they started out following someone else’s template of how to do something – like Scrum – before they learned how to apply context, innovate and iterate their own methods.

Every SAFe trainer I’ve listened to (including Dean Leffingwell) always stresses that SAFe is supposed to be customised to fit each organisation.

SAFe is Processes and Tools over Individuals and Interactions – so is incompatible with the Agile Manifesto

I don’t see the incompatibility with the Agile Manifesto. There’s nothing in SAFe that directly conflicts with those values and principles, indeed it promotes many practices consistent with them.

Yes, it does talk about Processes and Tools, but that tends to happen when you are organising such a large number of people. The Agile Manifesto explicitly says that processes and tools are to be valued – just not over individuals and interactions.

It doesn’t help to say: “let the people figure out a simpler way to work themselves” because in practice they won’t: they lack the skills and awareness needed and are operating in an environment that can’t support this. These organisations are not start-ups. It’s not realistic to rock-up and want to blow-up their whole world. People need to go on a journey that starts from a place they can recognise.

Don’t forget SAFe is covering much more ground than a single agile team method: value-stream-analyis, value-based prioritisation, business and architectural themes, flow-based decision-making, cross-team-coordination, on-demand release trains, architecture, system issues, spikes and much more. Of course there’s more process and practices than alternatives.

SAFe is a bunch of context-sensitive Practices instead of Values and Principles which truly scale

If I was being flippant, I could say that Scrum is a “bunch of context-sensitive practices instead of values and principles which truly scale”. All methodologies are. And people don’t implement values and principles at scale; they implement specific practices that flow from them.

SAFe is simply setting out a stall: “Do these practices in these kinds of situations”. Then learn and iterate from there.

SAFe lets management suffocate workers with “How” when the workers are best placed to figure that out

Ken’s last criticism is the one I agree with the most.

There is always a danger that SAFe is interpreted as a top-down solution to support traditional management thinking – that people pay lip-service to Agile, adopting its language and some rituals but not its values and principles. That is a risk that needs to be actively managed.

However, implementing SAFe is most definitely not business-as-usual: the changes it forces are pretty radical to most large organisations and it can serve as the start of the Agile journey – but not the end.

Neil Killick's Criticism

Neil Killick obviously feels strongly about SAFe:

“(It is a) money-making bastardisation and Frankenstein of Scrum, Agile and Waterfall for companies too afraid to really change”

I don’t think large companies fear the change that simple methods like Scrum, XP, or Kanban provide – it is much simpler than that. It’s that they cannot see how a simple team-based method could possibly replace all the systems and structures they currently have to coordinate delivery across their portfolio.

And they are right: because none of these methods tell you How, they just tell you to “figure it out”. That’s just not good enough – and neither is it credible to say they don’t need coordinating.

In my experience fear comes in later, once they’ve started on change and begin to see changes to their own roles and responsibilities that can seem threatening. Then fear can be a barrier. But at the start it is simply about credibility. SAFe scores well on this front because it makes a credible attempt to provide an Agile template for the whole organisation.

SAFe may well make money and for some that might be reason enough to resent it, but I disagree. We should be applauding anything that helps advance the cause of Agile through commercial success. One example of SAFe doing just that is how it’s popularising useful tools like Cost-of-Delay.

SAFe bypasses the concept of iterating over a product by simply incrementing features

I disagree that SAFe ignores the product: rather the reverse – it provides a structured way to capture business and architecture themes into epics, prioritise and group them into a products at the program level where they are further broken-down into small items and prioritised against other work.

Because of this SAFe is more product-driven than team-based Agile methods which tend to focus only on the next few stories. I’ve seen many Scrum teams who don’t even have a Sprint Goal, just a collection of disparate stories and expect a hero-PO to just fix it.

In a large enterprise, continuous delivery into production is rarely a simple matter, particularly if there are SLAs (unlike the Facebook world). So the fact that SAFe includes release planning sessions is a good thing.

This is often overlooked in Agile. I’d like to see people place as much focus on Migration Ownership (including user training and operational loads / curve planning) as there is on Product Ownership. Agile can be highly destructive for end-users if they are bombarded with unnecessary changes thrown over the wall.

SAFe includes an unnecessary “Hardening Sprint” for bug-fixing/deployment issues which is symptom of its problems

Hardening Sprints are a sensible reality that may not been needed in theory but usually are in practice.

They are also a sensible contingency. Releasing only “when it is done” is not practical when hundreds and thousands of other people depend on a predictable date for operational needs, marketing campaigns, customer credibility, staff and user training, market opportunities – and a host of other reasons that matter in an enterprise world.

SAFe is deadline-date-driven based on estimations of of how long features will take to build

I understand why Neil is opposed to estimates, he’s a prominent member of the #NoEstimates campaign.

But there’s a big difference between estimating tasks and forecasting release dates. Task estimation is something you can move beyond when you have a predictable velocity and maturity in breaking work down.

But it always makes sense to forecast when you’ll be done – why wouldn’t you? In the enterprise world there’s a host of other people who have important work to do that is date-sensitive. Or do you only care about the software teams?

It pains me when people interpret Agile to mean that “we can’t have a release date” – of course you can if you want, you just can’t fix the scope. Equally, you can forecast a release date that might move. Agile just makes it easier to do this because you have real data on team progress.

SAFe is unnecessary: Scrum scales perfectly well just using product and program backlogs

It isn’t Scrum per-se that scales but the things built on top of Scrum. People build a whole host of practices on top of Scrum to support portfolio considerations, prioritisation, value, architecture and much more. That’s how they scale.

SAFe is simply a template for many of those scaling practices – a starting point. And guess what, many people like having a starting point rather than simply being told to “figure it out”. SAFe’s starting point isn’t perfect but at least it is giving an answer.

I understand the argument that people will not become truly Agile until they have the ability to create their own practices based on knowledge and judgement and context. But many people will never go on that journey – that’s what Agilistas struggle to understand: not everyone shares their passion. Yet all those people still have a role to play and SAFe helps them do it.

There’s a fundamental misassumption: “You’re large, therefore you need to ‘scale’ in this way”. Most organisations are only “biggish” and most projects are relatively small and can be done by a single or a few Agile teams

That may true if you limit the scope to technical product development.

But most organisations these days are delivering services made up of a whole bunch of products that are a mix of people and processes of which IT is only one part. In reality the number of people involved in each project is far greater.

The true opportunities for benefits with Agile lie in end-to-end change of the whole organisation, which means taking a much wider view of Agile. That’s where a framework like SAFe can offer benefits that a team-based product development methodology cannot.

That doesn’t make SAFe the best answer – but it is at least an answer.

SAFe isn’t Safe: It appeals to today’s managers and executives who don’t understand agile and won’t learn and embrace the detail – there’s a real risk of successfully adopting SAFe and never becoming truly Agile

That’s a real risk.

However, SAFe’s appeal means it stands a better chance of adoption, so it is at least creating an opportunity for change where it didn’t exist before. It’s up to those assisting with implementations (consultants and coaches) to do all they can to make sure that SAFe is a catalyst for further change and not the organisation’s first and only step.

The Elephant in the Room

It may well be true that the heart of Agile is simply the principles in the manifesto plus some team practices.

Many feel passionately that this is all that is needed, plus a few team-to-team coordinating practices such as Scrum-of-Scrums and Communities of Practice. Some will simply never accept that any more is needed and reject out-of-hand anything that arrives with a bigger and more complicated structure.

SAFe recognises that large organisations who are used to a very non-Agile and traditional way of working need a structure to help them change.

Many of these organisations simply won’t go on a change journey without a structure that they can understand and relate to – even if that structure up-ends many of their traditional practices. Unless you have an international reputation and can pick clients who are willing to simply do whatever you say, then many people will only buy a solution that offers them something they can recognise.

For that reason, SAFe is creating an opportunity for Agile change where it previously did not exist.

That doesn’t mean that SAFe is a silver bullet: there are risks that organisations only implement SAFe as a static framework using traditional management thinking, miss the point and most of the benefits.

So, while I have a natural distaste for anything that is “Agile-in-a-box” on principle, I can see the point of SAFe and why it (or similar frameworks) are needed. Like Ron, I can also see a lot of good elements included in SAFe that will benefit most organisations.

It’s up to us in the Agile community to ensure that these methods become launch vehicles for spreading and growing knowledge of the Values and Principles behind them.

6 Comments

First of all that’s a really good and comprehensive post!
Before I get into details of where I disagree with your points regarding SAFe criticism let me just mention that I see system in the core of SAFe and thus not product. As a result devs are detached from product stream a typical waterfall flaw. There agile ways to scale and one may check them before turning his efforts to SAFe adoption. More comprehensive version of my point you may find here

1) SAFe is a re-manifestation of RUP: “The boys from RUP are back…building on (its) profound failure
Well your point has form of one must choose SAFe when there are thousands or more people working because Scrum won’t deliver. I don’t see a positive point though why Scrum can’t do it? Of course if you read Ken’s book on scrum of scrums you may see it as a naive attempt to scale scrum (And I fully agree with such point). But there are other attempts to scale Scrum like this of Bas Vodde and Craig Larman which has been used in large organizations mainly in Asia and proved to be working there. SAFe is not agile because it focuses on top-down portfolio and program management and as I said before cuts linkage between devs and product. That’s what you cannot find in BV and CL approach.

2) SAFe is over-complicated and comes with a tool (Rally) and consultant dependency
Oh come on – that’s a world of difference between having 100k various consultants and 10-20 systems and one system and one type of consultants. There is up to now no Prince2 or PMP company within agile movement and SAFe is on the way to change it. I believe in variety and not in monopoly. Just two factors Agile is trendy + there is no control style agile framework makes Rally + SAFe teams great candidates to win managers’ harts.

3) SAFe is Processes and Tools over Individuals and Interactions – so is incompatible with the Agile Manifesto
“It doesn’t help to say: <> because in practice they won’t” Yeap but in the very core of agile is belief that people can do it once they have proper knowledge and experience. SAFe takes this option away regardless of great people are working in a company

4) However, implementing SAFe is most definitely not business-as-usual: the changes it forces are pretty radical to most large organisations and it can serve as the start of the Agile journey – but not the end.

I disagree with this. Managers and business leaders love to push devs to deliver while not make much effort themselves with respect to changes. SAFe does not stress this point as scrum or lean does.

Hi Aleksander, thanks for all of your comments and taking the time to put them down.

1) I’m not at all saying SAFe is the only option – everyone is free to use what they like. But I don’t consider vanilla Scrum an equivalent because it simply doesn’t say anything at all about how to handle issues wider than a team or team of teams.

That doesn’t mean you can’t build on top of it (like Vodde & Larman do) but that’s not the same thing – the point of things like SAFe is to provide a more comprehensive starting point. The point of that is adoption – some organisations ignore Scrum because it doesn’t even try to answer some important questions.

I don’t agree that SAFe “isn’t agile”. When you have a large business with complex products you can’t just have the devs execute – you need more. SAFe doesn’t cut the link – that’s dependent on how you apply it. Nothing to stop you involving devs throughout. In fact, it explicitly attempts to make the upstream portfolio more agile – whereas vanilla Scrum effectively says “the PO sorts this out”.

2) SAFe adds to the variety. It will only get a monopoly if succeeds – and it will only do that if it works (because it is far less resistence to implement PRINCE2). Nothing to stop anyone using anything else. Winning manager’s hearts is a good thing if you want to change them – and in a large organisation you need to take managers on the journey with you if you want to succeed much beyond a single team.

3) I don’t follow you here. Yes SAFe provides processes and tools (as do most methodologies – even Scrum) but nowhere does it say these are valued over individuals and interactions. That would be a bit like saying Scrum isn’t agile because it is dominated by inflexible ritual processes like stand-ups and sprint planning sessions.

4) This is my point about adoption. If you want people to change then they need a path they can follow. For large organisations that needs to include managers, business leaders and the very large number of people outside IT who are key to delivering and supporting products and services (and working with smaller, faster, more frequent releases). Scrum doesn’t try to change any manager’s behaviour outside the dev team.

Don’t get me wrong – I love Scrum too – but comparing them is a bit like comparing musical notation (Scrum) with a complete opera (SAFe). Yes, people could self-organise and use the notation to write and perform their own – but most big groups will struggle and fail to achieve it. Now, you might not like that particular opera – good for you, go choose something else.

Sometimes I get this disconnect with people who say “all you need is Scrum” – it is never, ever true in my experience. There’s always a big pile of stuff that is built on top, especially for an enterprise organisation.

About “SAFe is not Agile”. You can’t evolve a big complex something directly you need to break it down. In the IT context this big something is mostly system or product. Agile chooses the latter while SAFe the former – (just check this on SAFe pages it’s a system-level incrementation what teams do). Each choice has profound consequences. With the system there is no more real attachment to what company is earning money from (unless your company builds systems for money). If you leave behind the idea of team executing product incrementation and move it to the higher level you raise exponentially risk of getting software which is organized orthogonally to company’s / user’s needs. It’s not true as well that SAFe encourages getting devs to the higher levels. Check for instance – http://scaledagileframework.com/team-demo and what it says about the system demo.
I bet Google realized that a link between their devs and real product is substantial and thus their people worked (at least two years ago) around product focus groups where cross-system development was left as an important but purely technical (and thus cross product groups) concern.
Historically companies loved the idea of separation between technical and business part with no real good mapping between them. Agile was a revolutionary approach because it said: just get rid of the mapping itself. This idea has been picked by modern software architecture styles like Domain Driven Design which says that both business and devs must use the same language which is reflected one-to-one in the names of code building blocks.
But the old easy to grasp system orientation and separation is pretty deep entrenched in management minds so they find SAFe approach awesome.

2) Coca Cola is the winning soda but does it make it the healthiest soda ever? Check scientific studies by Ilan Yaniv “Exploiting the wisdom of others to make better decisions…” on how people make decisions. Namely people by default take the option which resembles what they already think and not what by all (known to them) means must be better. The same goes to managers which pick system oriented top-down supportive SAFe approach because it sounds, feels and smells like yesterday’s morning coffee & croissant.

3) Sorry wrong typing. Well it’s not important anyway so let’s leave it

4) Scrum puts the new ways of collaboration between devs and managers – just check Ken’s “Agile Software Development with Scrum” – in its very core. SAFe follows good old fashioned separation and that’s the issue regardless of numbers of managers.

About the musical notation and an opera. That’s why one of the greatest projects (not necessarily most ethical ones) in the history of mankind “The Manhattan Project” valued face to face interactions at all cost and removed complex management structures. They understood that great specialists are way better then managerial overhead.

And of course I don’t mind companies use SAFe. I just don’t see the efficiency which you get from a massive cooperation of specialists focused on product goals there as I do find in Agile.

1) In most companies that are not software companies, there’s a wider system of work beyond IT delivering products and services. The “product” is much more than just a technical solution and so is the work that needs to be organised in its delivery – there are always both systems and products (and ecosystems around them). That all needs mechanisms and we can argue about the merits of SAFe’s but at least it proposes some.

I don’t think we’re going to agree on this point – the claims you make about what SAFe prevents I don’t find to be true in practice, though of course there always bad implementations (just like the dozens of bad Scrum implementations I’ve seen – none of which prevent me thinking Scrum is a good thing).

2) It’s still all about adoption. You can take the purist’s approach but then you’ll have very few companies of scale that embrace it. The managers that pick SAFe are not going to pick the purist alternatives. Is it better to move a large number of people a small way or a small number of people a large way? Why not offer and do both, I say.

4) I’m not sure I’d advance The Mahattan Project as a justification for Agile, but it is brave to do so

1) Sure so does Vodde’s framework as his system has been used in electronic companies in Asia on a massive scale

And yes to settle this one should have an empirical proof which I don’t have But I bet there is a greater chance to bias towards the goal then otherwise and when the goal is product then the architecture reflects this

2) Sure but such setups shouldn’t use name Agile and instead something different like MickeyBYB or ZZGreat or whatever