The Scaled Agile Framework (SAFe) has come in for a lot of criticism recently. SAFe is rising in popularity and succeeding in the marketplace. But are the critics justified?
I explore the main arguments over SAFe and draw my own conclusions on the usefulness of this approach.
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.
SAFe borrows from Scrum, Kanban, Lean, XP and a host of other areas including Don Reinertsen’s work on Principles of Product Development Flow for prioritisation using a form of Cost-of-Delay with Weighted-Shortest-Job-First (WSJF).
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:
There’s a ton more to SAFe than all this, but that will do for a brief tour.
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:
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.
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 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.
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.
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.
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 obviously feels strongly about SAFe:
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.
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.
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.
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.
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.
Ron actually thinks SAFe contains a lot of good elements:
Clear levels, focus on lean, leadership, developing people, value streams, limiting WIP at the top, themes, epics, program/product clarity, release planning, cadence for development / demand for delivery, release trains, hardening sprints, team practices, code practices and more.
But he doesn’t like the overall result for some good reasons:
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.
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.
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.
Licence and Terms of Service