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
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
- Geographical distribution.
- Team size.
- Compliance requirement.
- Domain complexity.
- Organization distribution.
- Technical complexity.
- Organizational complexity.
- Enterprise discipline.
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 (theNot Agile/Not Agile Enoughargument) and for being too much/too specific change (theYou can’t impose recipesargument). 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
Latest posts by Martin Burns (see all)
- Colocated Teams, Distributed Organisations - January 20, 2018
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017