Critising SAFe for ‘scaling agile’ is missing the point. It’s about using means that Agile has developed to improve Product Development Flow in an existing context of significant complexity factors

Chris Matts gives a great summary of this context:

GIVEN you have hundreds… thousands of developers (programmers and testers),
AND you have more than a few dozen product owners

Scott Ambler lists a whole load more.

8 Product Flow Complexity Factors

  1. Geographical distribution.
  2. Team size.
  3. Compliance requirement.
  4. Domain complexity.
  5. Organization distribution.
  6. Technical complexity.
  7. Organizational complexity.
  8. Enterprise discipline.

Scott Ambler

Claiming that these complexity factors don’t matter, or that you can ignore them, or that the response is to do more of what doesn’t address them is a bit like dinosaurs arguing that global ice ages shouldn’t exist. It’s wishful thinking, trying to control reality without paying attention to feedback loops. Isn’t that what we’re trying to get away from with Agile?

All of these factors impact Product Flow. If you face some or all of them, by what means are you trying to improve flow that acknowledges this reality?

It strikes me that you can summarise SAFe (and possibly other approaches to ‘Scaling Agile’) as a sincere attempt to take Don Reinertsen’s Flow Principles seriously, and come up with some practical ideas to put them into operation in the context of some or all of these factors, by means of implementing Agile Disciplines and Mindsets throughout the value stream.

I find it interesting that SAFe is criticised for being both not enough/not specific enough change (the Not Agile/Not Agile Enough argument) and for being too much/too specific change (the You can’t impose recipes argument). And sometimes both by the same people.

This is really the Kanban principle of ‘Start from where you are now’ – it accepts the context reality of target organisations and gives some principles that will help, along with some experimentally-derived ideas for how to put them into practise. Those ideas aren’t gospel by the way, nor are they guaranteed. They’re some ideas that have worked well enough in other organisations facing similar complexity factors to be worth a try, because a success with them would mean a very much faster time to getting up and running combined with a strong influence on organisational ways of working.

The most significant dimension to Scaling Agile is not in the increasing the product size. It’s scaling the organisational scope of Lean/Agile thinking to improve end to end product flow, from concept to cash.

  Recommend this post
Follow me

Martin Burns

Transformation Consultant at CA Inc (formerly Rally)
Previously: Leader of software delivery portfolios in large scale orgs.
Specialism: Transforming complex delivery organisations to be more Lean/Agile.
Mindset: Continuous Improvement Obsessive
Follow me

Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 Scaling Agile: You’re Looking at the Wrong Thing by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.