Help! I'm getting SAFed!
SAFe is the worst implementation of “corporate agile” that is out there! Over the last few months I heard this sentence or a variety of it a few times. There is some truth to it, but it is not the whole truth. The SAFe-framework is far away from what I imagine when thinking “agile”, but there are some aspects which are pretty neat. Despite all the critics it is a very popular framework that is implemented in a lot of bigger companies. So there has to be something good in it, doesn’t it? Let’s have a more differentiated look at it!
Getting SAFed
Over the lasts few months I was at the receiving end of a professionally conducted transition to SAFe of a department in a large, multinational company. This implementation of the scaled agile framework was led by an experienced coach from a distinguished consulting company, and I took the opportunity to see experts at work. I was - and remain - quite skeptical about the SAFe-framework, but I decided to take me by own words and help to make transformation a success. That I could get a good look at how this is facilitated by people from the SAFe-machinery was an added bonus. What I got is a hands-on opportunity to see how the SAFe the mechanics work. Which of them are really powerful tools and which are actually counter-productive when striving for a lean, agile mindset. All in all I still remain on my opinion that SAFe is a far from an optimal framework to get on “the agile way”, but it is a possible first step for rigid companies to become more agile in operation and in mindset. The bigger challenge will be growing beyond SAFe.
One dictionary to bind them all
The one absolutely big advantage of SAFe is that it is very, very well documented. Just have a look at the landing page of SAFe. Everything is clickable and there are tons of well written articles, guides, checklists and templates to be used. It even includes a structured way on how to onboard everybody to SAFe and a step by step guide to introduce it. Having this amount of coherent documentation this is a very handy thing, because this is providing a common vocabulary across the organization when it comes to the operating model to be used. Everybody knows the different between “Iteration” and “Increment”, or at least knows where to look it up.
Built for speed when implementing it
Another thing that is very nice about SAFe is that it is built for speed in implementing in an organization. It took only a bit more than three months from the first trainings until the structural transformation to SAFe model to happen which was very fast, considered that company spend almost two years reorganizing itself just a few years ago. Having such a no-nonsense attitude in getting things done is very much admirable. Instead of talking and planning on how this transformation could or would work out, rolling back the sleeves and going at it was much more to my liking.
“Reacting to change over following a plan”? - not so much
One of the more prominent things of SAFe are the big room plannings that are to be executed roughly four times a year. In a nutshell all the people working on the same product meet in a big room for two days and hammer out a plan for the next few months. This is a very powerful method to align people to a common cause and to foster transparency about the “what” that will be done in the next few months. As this plannings happen roughly synchronized and with the same cadence over the whole organization, managing inter-team dependencies becomes much easier. SAFe also stresses that one states and confirms “assumptions” on the spot, so the content content that is generated in such big room plannings is generally of a very high quality. So far so good. But then SAFe just takes it too far and into too much detail. The big room plannings requiring the teams to plan in stories into up to five sprints in advance and then commit to delivering them. While this might be an improvement from the cycle time an organization had pre-SAFe it effectively takes away the flexibility of reacting to change from the teams. Instead of stopping at the point where teams are aware of their goals and dependencies and then setting them to work in an autonomous manner, going into that kind of detail is severely restricting the freedom to operate of the teams. After all you committed to a plan for 5 sprints, so as a consequence deviating from that plan needs quite a bit of justification, which has the potential to encourage teams to rather stick to the plan instead of adapting it to the current situation.
Putting a break on self-organizing
SAFe propagates a layered organizational structure with a clear flow of information, which is very nice as it scales very easily. Depending on the size of the organization you get fewer or more layers added. The downside of this is that these are structures that discourage self-organization and empowerment. There is always one person “above” to coordinate with. Can’t decide on something? Escalate it upwards. Can’t be bothered to get something done? delegate it downwards. Sounds familiar?
Together with a propagated unification of technology and tools across the whole organization[^1] this limits the amount of freedom the people have in executing the production. In such an environment empowering themselves and getting the needed freedom of movement - agility in other words - to the ground is very hard. As the framework requires you to sync upwards, speed of change is very much dictated by the the number and attitude of the people living a layer above you. The SAFe guide actually proposes that this is not how it should work and with the right people it actually could work out, but as the saying go “you lie, like you bed yourself”. My critique to this is that is that it blatantly ignores where people are coming from when going to SAFe. In most cases SAFe won’t be built up from scratch, but put on an existing - and possibly dysfunctional - company structure. So having one set of rigid structures replaced with another is very unlikely to end up with people changing their attitude significantly.
Agile Vendor lock-in
SAFe is sold as a product to managers. And being partly sales person impacts the performance of the coaches significantly. As long as SAFe is in place, additional revenue is generated for them by running trainings and selling certifications. This additional cash is also locking the coaches inside SAFe and preventing them to coach out anything outside SAFe. In agile we often cite the “Shu Ha Ri” concept mastery, but since the coaches are strongly motivated to keep SAFe running as long as possible, their incentive to bring an organization to the “Ri” state where they can transcend beyond the current state is very limited. This is also visible in the sales promise of SAFe, which is advertised as a solution rather than a framework to build upon. For companies that are just starting their agile journey, this does not matter that much at the beginning. The big drawback is that they might miss the opportunity to go beyond what they have learned after some time. The risk of ending up with the same stale-mate of processes and structures that might have caused them to turn to SAFe in the first place is a real possibility.
And now?
All in all I say that while SAFe is not ideal in the long run it is a valid start for organizations just starting their agile journey. Given that these organizations often do not yet have an exploratory mindset they are often looking for some sort of success guarantee and some sense of predictability when doing such a big leap of faith and here SAFe is very strong, so it is pretty obvious why it became so popular. However I remain that most organizations would be better off with being coached smartly and taking some of the nice things of SAFe without committing to actually doing SAFe from the beginning. This probably saves some costs but also ensures a more long-term gain from such a transformation.
Disclamimer: This post is of course heavily subjective and the opinions presented here are purely my own and are born of the situations that I observed. Different circumstances and different people might yield comletely different situations.
– [^1]:As i understood from discussions, this might just be a quirk of the SAFe-coach I witnessed.