The Scaled Agile Framework is the leading framework for, well, scaling agile; that is getting more than a single team to “be agile”. Beloved by some, source of all evil for others. Is it for you?
- A complete agile pattern library with high quality documentation available for free on the Internet!
- Provides a common vocabulary, pitched in enterprise terms to reassume enterprise adopters (SAFE aims to get agile to cross the chasm). If you work in a PMO, you will find SAFe has a very reassuring tone. It reaches the parts that many of those long-haired, sandal-wearing agile coaches can’t.
- Structured training is available and an increasing number of SAFe coaches/consultants can be brought in ready to go
- The agile dream of single-handed delivery of customer value by single team is in reality elusive as ever in most contexts – SAFe aims to be a pragmatic compromise and considers the programme (team-of-teams) to be the core unit of value delivery – not really the single team. Programmes (teams-of-teams) will exist anyway. Might as well structure it using SAFe as the pros outweigh the cons
- There are lots of case studies of organisations having got value from SAFe adoption. Moving from funding projects to funding teams-of-teams is by itself a massive driver of value, even if you don’t do anything else
- Deciding to adopt SAFe provides visibility and momentum to agile transformation that ad-hoc adoption of scaling practices does not, particular good at mobilising middle-management (who don’t really have a role in most other frameworks)
- Its flexible, you can choose the bits you like
- Is getting better all the time
- Only my personal experience, of course. When I met the creator of SAFe, Dean Leffingwell, I was impressed by his genuine agile vibe. He struck me as a pukka agile dude with his heart in the right place.
Why not SAFE?
- Contains lots of hidden compromises with the true agile spirit in order to pander to “this is what management can cope with right now” e.g. lots of middle-management roles, accepting that multiple teams are required to deliver value, …
- There is actually little need for the overhead of a framework like SAFe, individual scaling practices can be adopted by skilled practitioners when needed
- Organisations tend to take the things they feel comfortable with. Because SAFe contains so much, it is way too easy to take all the comfortable stuff and miss the real agile principles and culture that underlie SAFe
- SAFe is grounded at the team level in practices that have been broadly adopted across many organisations (Scrum, XP). SAFe is more experimental at the team-of-team level (Program Increment) and is not much more than a sketch above this (Portfolio/Value Stream Level). Adopters desperately seeking to show everybody they are drinking the agile kool-aid often miss these differing levels of maturity
- Adopting SAFe takes energy away from what really matters in agile adoption at a team level like mastering Scrum and XP.
- Case studies of value got from SAFe are not all entirely convincing. There are also examples of companies having abandoned SAFe. All very context dependent and impossible to validate the results scientifically (this could also be said of any other agile approach too – scrum is still scientifically unproven too)
Recommendation – SAFe or not then?
On the whole, it depends!
In my limited experience (which might be 20 organisations or so), organisations are often best served by first focusing on mastery of Scrum and XP for single teams. Get good at replicating this. Walk before you run. Don’t scale what ain’t working. Management should work out what systemic impediments there are to having these individual teams perform and remove them – this is often enough change for the next 5-10 years or so – it’s a really big ask. Some of those impediments are really tricky.
For scaling, adopt scaling practices when needed and do absolutely steal with pride from SAFe. SAFe has great formulations for say, aligning on quarterly planning, team-of-team retrospectives, what it means to build quality in and so on.
A SAFe rollout might be useful in certain contexts. In some organisations, it’s the only way to get management attention for agile transformation because as the rest of agile has not really crossed the chasm (some would argue this makes agile transformation doomed to failure in this organisation anyway ).
A brand new programme with people who had never worked together would also probably benefit from experimenting with a SAFe rollout to start with. Even then, be careful not to take management attention away from setting the individual teams up for success. On a similar note, SAFe might be useful in rebooting a failing programme, and provides a ready-made template for redefining roles, expectations etc. (although if the underlying issues which cause the programme to fail in the first place are not addressed then failure is certain whether SAFe is used or not).
In short, its still early days for scaling agile beyond a single team. Nobody has all the answers yet, including SAFe. Exciting to see how this will evolve in the coming years!