A Critique of SAFe – The Scaled Agile Framework

This is a critique of the Scaled Agile Framework (SAFe).

It’s a critique, so it’s pretty negative! There are some benefits of using SAFe in large organisations, some very good use cases for full or partial adoption as long as it’s considered part of a journey, as long as your eyes are open to the problems with SAFe, and your reasons for adopting it are sound.

However, here I’m describing ten key points emphasising why it’s not an appropriate approach for most organisations looking to scale software delivery.

I’m really interested in your opinion, so please do get in touch if you wish to make a comment or suggestion. Ultimately, we must remember to scale down the problem before scaling up the solution.

In Summary: Problems with SAFe approaches:

  1. SAFe encourages normalisation of batch sizing across teams, incentivises increasing task sizes, and fundamentally misappropriates what story points are for.
  2. SAFe can cause increased localised technical debt.
  3. SAFe creates conflicts with support, operational and SRE functions.
  4. SAFe decreases inter-team (particularly value stream) collaboration.
  5. SAFe uses fallacies in estimation.
  6. SAFe decreases the agile focus on value in favour of “what management wants”.
  7. SAFe decreases the utility of, and the focus on, retrospectives.
  8. SAFe is not Agile – it encourages top-down, large-batch planning rather than small, iterative, feedback loops.
  9. SAFe is framed as a solution, rather than a stage of a journey.
  10. SAFe scales up the solution rather than scaling down the problem.

11 – (bonus point, thanks to Mathew Skelton) – SAFe encourages temporal coupling of teams.

In Detail: a critique of the Scaled Agile Framework:

1 – Nothing in agile suggests that we need to, or even *should* measure work units (i.e. story points) in uniform manners across teams. Story points exist to help the people *doing* the work break things down into optimum batch size, which makes deliverables achievable, less complex, and facilities flow. Indeed, SAFe actually encourages larger batch sizes through front-loaded planning, not smaller sizes planned through more iterative methods.

SAFe tries to normalise story points across teams for various reasons, but there is often a strong desire to measure and compare the delivery of teams and people. This is not what story points are for. Story points do not exist to measure how “productive” developers are.

2 – Technical debt tends to increase in SAFe organisations because the prioritisation of dealing with it is raised to a management level rather than team level. This is counter-productive for technical debt that originates at the team level (which most of it does). Management will tend to prioritise features and functions, delaying the pay-back of localised technical debt, and resulting in slower, higher risk, more brittle systems.

3 – If SAFe is applied to more operational functions, such as technology support, operations, or SRE, conflicts between delivery and support functions arise, because supporting teams typically need to work either responsively, dealing with issues as they arise, or on very short cycles – not the Programme Increment cycle time imposed by SAFe.

4 – Due to the focus on deliverables and accountability through project or product managers, teams may be discouraged from assisting each other, as they are measured by their own delivery and productivity: how much they assist other teams is rarely valued.

5 – The concept of “ideal dev days” is often used for estimating in SAFe. Everyone else knows that ideal dev days are a fallacy. Instead, look at past similar deliverables, and see how long they took. This is a much more predictive metric, and is less susceptible to optimism bias or wanting to please the boss.

6 – The concept of “value” often breaks down in SAFe, through a focus on volume of delivery and meeting the (often arbitrary) deadlines imposed by management in PI planning. As a result, what end-users actually want is often ignored in favour of what management wants.

7 – PI planning includes a small element of retrospective activity, but it’s too little, too late. The retrospective feedback loops need to be short and light, not tagged on to PI planning as an afterthought. Here’s a comprehensive guide to retrospectives that also covers some really useful suggestions for running them with remote and distributed teams.

8 – Agile was created as a response to frustrations felt across the industry from heavyweight, top-down project management methodology that was killing the sector. Trying to scale Agile up by applying heavyweight, top-down methodologies is antithetical. 

9 – Some SAFe practitioners describe it as a transition stage, a process through which organisations can achieve increased capability at scale. I would agree: if an organisation feels the need to adopt SAFe, it should be as training wheels, a structure through which great capabilities can be built, before throwing off the shackles of a rigid, top-down framework. If it was really true that SAFe is a transitionary framework, why does the SAFe model not include anything about the transition away from it?

10 – In reality, most organisations don’t need SAFe. They’re not so big that they need such a big solution. SAFe is a comfort blanket for organisations used to traditional, slow, heavyweight, command-control structures. Your projects and products actually aren’t that big – and if they are, then that’s the problem, not the management process.

Fundamentally, SAFE tends to ignore, or encourages management to ignore the possibility that those closest to the work might be the best equipped to make decisions about it. Scale the work down, not the process up. SAFe fits the delivery model to the organisational structure, rather than forcing the organisation to adopt new ways.

Here’s a bonus point 11, thanks to Matt Skelton of Team Topologies: SAFe, via the enforced Program Increment approach, encourages (or very possibly forces) at least a temporal coupling of teams that isn’t warranted. In fact, any sort of forced coupling is an antipattern for a fast flow of change, and via Conway’s Law, probably introduces architectural coupling too (which is bad). Given that SAFe adopts the PI as the core foundation of the approach, it’s unlikely that any SAFe practitioner would suggest dropping PI when the teams are mature enough to do so… or would they?

2023 update: Here’s a fantastic Creative-Commons document that outlines similar criticisms of SAFe along with case studies and expert commentary from practitioners and researchers alike.

 

Spread the love

Leave a Reply