I just attended the SAFe training “Scaled Agilist”. In this post I’ll describe my first impressions. To start off I need to say that I was skeptical about SAFe before taking the training. I wasn’t very impressed about what I had read about it on blogs/twitter and hearing about it in short presentations. But I wanted to learn more about it as I think it is something we will need to get used to in the agile community. I wanted to give it a shot – perhaps it was something in there that was really useful that I just hadn’t seen.

Positives

I’ll start with the positives about the training.

• It went through a lot of nice basics with flow theory, how to treat knowledge work, lean, queue theory, feedback, decentralized decision making, agile values, early value delivery, WSJF etc. To me this was all good but also a clear way to build ethos. “Yea, we are pals with all these cool agile kids.”
• It goes through a lot of things considered “best practises” in the agile world like:
  • Using Kanban to handle the portfolio level.
  • It talks about sound code quality practices (XP) in the teams.
  • How to manage the balance between business driven work and architectural driven work (on an epic level).
  • Replacing projects with continuous work.
• The “Hardening Sprints” have been replaced by a “Innovation and Planning Sprint”. I really disliked the old concept of reserving two weeks for integration and bug fixing. To me that just seemed very waterfall. Now there is that but also room for innovation, hackathons etc.

Alright, so those were the good parts but to be honest, didn’t we already know about all of that? It is not like SAFe came with anything new – it just re-packaged what we already knew. I guess that the value SAFe adds is that it is now a model that can be “sold” to management… well, since it’s a model.

Negatives

To the negatives. Since many others have already bashed SAFe (see the first slides in this presentation) I’ll just stick to some particular things to the training I attended. (A disclaimer is that this was the first time this trainer taught this class so all things might not be according to what others are saying.)

• It feels very much like RUP with a lot of stuff (artifacts and processes). Some might bring value to your context but others won’t. I see a big risk of people searching for a quick fix or a silver bullet will want to “install” SAFe into their organizations as is. Without understanding why they do it or how they should take it further.
• In the two day release planning session you lock down in detail what everyone is going to work on over the next ten weeks. Whatever happened to “responding to change over following a plan”?
• The release planing sessions sounds like it could have been useful to someone in some context. But is it useful to all? I don’t think so. To me it sounds like something you could blog about, for others to draw inspiration from and tweak to their context.
• So, grouping up a bunch of teams and looking a dependencies is generally a good idea. But instead of trying to break those dependencies to create autonomous teams the direction SAFe is taking is to accept the dependencies and spend a lot of time working around or managing them.

At the end of the course I asked the trainer what companies would really benefit from using SAFe. It was an honest question since I really couldn’t see it. The answers sort of made me fall off my chair. According to him it needed to be really big multinational corporations. In Sweden (this is where I took the training), he said, we only have one of those and it is Ericsson… So why on earth would you then sell this training/model in Sweden to people who are not working at Ericsson? Is this just a new moneymaking machine for trainers to sell certifications? In this case I guess the answer is yes. Since the trainer was also selling his own model for scaling in mid-size corporations I would like to get a second opinion on that statement. Also, if you are already delivering value more frequently and are actively working towards having autonomous teams SAFe (according to the trainer) isn’t for you. Your organization should be pretty messy and would benefit from a hard reset.

So a conclusion is that if you like me is living in Sweden and not working at Ericsson – spend your money elsewhere.

Wrap up

To wrap up I’d like to quote Don Reinertsen in his foreword to Dean Leffingwells Agile Software Requirements (that describes sort of a first version of SAFe).

//…// I suggest paying attention to several things. First, try to understand the reasons why certain of these approaches work, not just what they are. If you understand why things work then you can more easily adopt them to your own unique context. Second, treat these ideas as a portfolio of useful patterns rather than a rigid set of practices that must be adopted as a group. //…//

Unfortunately these wise words are all lost in SAFe. It is taught as a “do all or it will fail”-process. Very similar to the way Scrum is taught in many places. But we all know that you shouldn’t do only Scrum by the book – it is  a starting point. And that is what use I see for SAFe – a starting point if you have a really big messed up organization it could serve as a replacement and a starting point when replacing your process. If you don’t have that – consider it a patterns book. And very much like when you use a design pattern when coding, make sure that you understand what problem you are trying solve and also understand the thinking behind the pattern you are thinking about applying.