Opinion: unSAFe or why SAFe might not be for you.

DISCLAIMER: This piece reflects my personal opinion about SAFe. You are free to have other opinions, in fact, I encourage you to disagree and discuss. That is how we learn from each other towards a better tomorrow.

If you've been around development projects for the past couple of years you've no doubt run across SAFe or Scaled Agile Framework. It pops up in hiring adverts, on learning sites and in posts on Linkedin. According to Wikipedia, SAFe is "...a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices."

Or in simpler words, a set of rules on how companies should manage large, agile projects.

Personally I've, so far, only been in one project that used SAFe and as a contractor I was expected to learn about it, and use it for the projects where I was active, on my own time. So my views might be a bit skewed as I don't have any formal training, just experience. I've also read a lot about it, both from the source and pieces like this one that highlight various aspects of it.

My encounter with SAFe came as part of a project where I worked as a contractor in systems architecture. We had the team together, we had our agile workflow and we were doing sprints. We had begun to overcome hurdles that came from being one of the few projects at the client that were working agile at the time. Almost everything else then was waterfall which caused its own set of problems.

When SAFe was introduced as the new de-facto working method it was sold as the solution to the problems we were having with the waterfall delivery teams. More transparency, quicker turnover and shorter development times with big sync meetings between teams.

New terminology, more micro management and new titles. But all should still be done with a DevOps mindset, something that anyone that knows SAFe and DevOps is more or less impossible if things are run with SAFe. And of course strict adherence to the letter of the documentation and the problems that causes for an organisation and people that are not native in the language and conventions that the documentation is written in. Meanings get twisted and misunderstandings are abound.

SAFe introduces more controls and checks on the teams and with ceremonies taking more and more time from actually producing anything. Add to that, as most were contractors, we were not included in any training initiatives to the adapted SAFe that was run and in parts was missing pieces of the original SAFe framework without introducing replacements for those pieces. Add cultural differences within the team, strict adherence to requirements compared to holistic approaches and end-user discussions, and you have a road map for problematic development.

Not to mention that everyone else that was supposed to work SAFe avoided it for the most part and went business-as-usual.

And this is just what I personally saw, how much else was going on behind the scenes was never divulged. But for all problems that I never heard about, I didn't hear any success stories either. Coming through a PI without having to redo everything and do it again in a week became the big win.

On digging more into the documentation of SAFe and reading articles by people way more into the subject than myself I've reached a few conclusions:

• SAFe is a good idea. It make the process of developing systems or software easier to understand, for management. For the people doing non-managerial tasks it means meetings and ceremonies that distract from producing anything.
• SAFe adds a command, control and check systems in places where you want to be able to turn quickly and places these in the hands of people that don't do the work and thus can create a blocker with simply not being available or understanding the problem.
• In its efforts to include everyone on the team, SAFe has many ceremonies where the majority of the participants don't do anything, or are active for a small fraction of the time of the ceremony, thus wasting time. I'm looking at you PI.
• There seems to be an almost blind adherence to requirements and that brings its own set of challenges. If you don't know why you are doing something apart from a copy/pasted user story, then you don't have the information you need to do good work.
• SAFe is good for products, as in when you already exactly know what you want and how you want it. When dealing with an ever changing world, where the requirements are either fluid or change often, you waste time since your window of maneuver is very small.
• While the way that something is produced is changed with SAFe, there is no demands placed on the support organisation that enables delivery. This applies to finance, people management and other functions. As a practical example: I needed to get some firewall openings done for the project. We needed them quickly since we needed to test if a new API was working. It took two weeks to get it done, since all the support mechanisms had no concept of our delivery model.
• More checks from those that don't know the work means course corrections are harder to do and have to be explained on an understandable level, instead of just doing them, thereby losing time.
• SAFe does not encourage, but doesn't counteract, communication between various teams unless it is during the PI. That way, dependencies are known almost exclusively to those that have them, not those that are meant to satisfy them. I've seen this happen and the frustration it causes can be cut with a knife.
• Since SAFe has a great interdependence in its various processes, an adapted version runs the risk of losing cohesion when expected inputs/outputs come from removed sections.

With SAFe winning adoption, the biggest danger I see is that companies become 'stuck' to it because it speaks to the managerial side of an organization, instead of going for a truer agile approach. The rigid ceremonial structure imposes, in my view, too many points of micro-management without an actual result apart from disrupting the workflow.

In many ways I am reminded of ITIL when I look at SAFe. ITIL has a very structured framework of inputs and outputs, roles, processes and methods, but in difference to SAFe it states very clearly that is should not be implemented as is, but adapted to the organisation. You adapt the organization to work with SAFe... then you're dooing it the wrong way; you're letting the tool dictate how you do things instead of having the right tool for the right job.

In all this doom and gloom, does SAFe have any value?

In my opinion, it does, but maybe not the way you'd like:

• SAFe is first and foremost a framework, it says it right in the name. As a framework it will have parts that are utterly useless to a given situation.
• SAFe can highlight problems like interdependence if used correctly, more on that below.
• SAFe can make the process of development understandable to management.
• SAFe can outline the responsibilities of the various roles.

In all this it is important to remember that SAFe speaks of an idealized world, not reality. So suspend your disbelief when you read anything about it.

And finally, what can be improved?

• There is right tool for the right job, if your organisation uses SAFe for all kinds of development, regardless of size or scope, then it's using a jackhammer to carve clay.
• The ceremonies, like the PI, are time sinks, not only for their length but also for the amount of time needed to prepare for them. The should be tools for helping development, not hindering it.
• Speaking of the PI; It is unnecessary to have the full teams present during it. You're essentially wasting two days where everything stops. Use a representative instead that has authority to make decisions on behalf of the team.
• On the topic of ceremonies, curtail the number of and invited people to meeting to essential, contributing personnel only. If team members are invited because 'it might be good for them to be there' then you are wasting peoples time and causing delays in your development and production.
• Make sure that any support organization outside of the actual project operates on the same delivery philosophy, meaning that if you are running fast release cycles any organisation that needs to be part of the delivery to the users either in terms of actual program delivery or back-end functions must have a quick turn-overs as you. Waiting two weeks for a back-end change is not acceptable.
• Learn what mixes. SAFe does not play well with DevOps for example.
• Make certain that the understanding of the source material is correct. It is more about what is being said, the meaning of it, than the actual words. Also be aware that some concept might not have a translation in your native language, or might translate into something else when you translate it back.
• As SAFe seems to be primarily written for management, role descriptions and their goals go along that route. It follows that these definitions lack clear technical definition of what a role or process is supposed to do.
• Make sure that the output produced by any role or method is actually used. If it is good to have you don't need it. Unused output is a big timesink.
• Shorten the PI from two days to one, maybe even just an afternoon. It is a relaxing two days where you at most present something for ten minutes and then don't do much more apart from discussing within the team, but that you should do on the daily during work anyway. Any velocity or burn down you have prior will just stop days before the PI when everyone has to get stuff prepared for it. And use the representative method.
• If SAFe doesn't work, don't be afraid to toss it out. There were frameworks and methodologies before it and there will be better ones after or are already around. It is not the one-and-be-all solution.

But these are just one person's opinions. I welcome constructive discussion in the comments.