I’ve been on a SAFe course. I was very interested, because like many people I’ve heard much about this, had opinions on it but haven’t experienced it first hand.
The context of the training was that it was given for my client. Not as “let’s get started with SAFe” but rather to align and give us all a common understanding on nomenclature and concepts.
I wanted to share a few thoughts in this post. If you were looking (or hoping) for a SAFe-bashing by a Kanbanista… Sorry - I’m not that guy. I’m also in way too good mood to bash anything right now.
The course
Your first time learning something has much to do with the teacher. I was in the expert hands of Carl Vikman that both were very knowledgeable, had a pleasant way and most importantly understood the main reason for us being there - gain a common understanding (rather than learning SAFe)
The course is really good. The first part on lean and agile principles is very good in fact. There was a lengthy part on the SAFe principles too that was informative but not as interesting. To me at least.
Many of the practices described is not news to anyone that have been doing lean or agile within system development. The big planning meeting, Program Increment is a novel feature that I think could be very beneficial to a larger organization where dependency resolution is imperative to be able to get momentum.
The more prescriptive the practices became the less interested I grew.
The conversations we had in our team was the best I’ve been involved in at this client since I got there. And maybe at any client, when it comes to communication between IT and business (brrr… hate that distinction).
Many great ideas and clarifications where brought out in the daylight and we have many small initiatives that we think can help us going forward. We are not adopting SAFe - just as intended.
SAFe… and prescribed processes in general
Because there’s of course nothing wrong with SAFe. It’s a good packing of many agile practices in a well thought-out form, battle tested and tweaked over several version (we are now on version 4).
But there’s an issue here, right in the middle of the whole prescription thing.
In SAFe and throughout the course it’s repeated that “this needs to be tweaked and adjusted to your need”, “you might not do all of that” or “this is something that maybe you don’t need”.
The problem is: how can I know what is needed? How can I know what to skip?
The answer, of course, is: you need experience and knowledge. Meaning that you cannot know before you have some knowledge… which you get by doing it. (Or hire consultants, like me, whose experience you then trust).
Well, to be frank; a prescribed process could also say: “do it our way, only our way or it will never work.” Scrum actually says that (last time I checked the Scrum Guide, check the last paragraph). eXtreme Programming was also very detailed in it’s prescription.
SAFe is not. Nor is the Kanban Method. Nor was RUP. And many others.
At this particular client I have been saying: “we’ll see how this will work”, “we’ll change it as we go” and even “I don’t really know what will work for this situation - let’s try something”. And I see that most people are uncomfortable with this.
And during this course I realized that SAFe (and other) gives the structure, hand-rails and answer to the question “How is X going to work?” that is so often asked for.
The problem is that after awhile (in all honesty I have not heard this about SAFe yet) people will start to say things like1: “but that’s not true SAFe”, “we are doing waterfall with some agile on top of it” or “that’s Scrum-but - of course it will fail”.
Remember RUP? What was the thing that people hated about RUP? All the documentation and stuff “we have to do” according to RUP. The only thing was the RUP also said: “Pick what you need, adjust as you go”. But companies didn’t.
My guess as to why is that it’s easier to have a prescribed model to hold on to and the lure of getting a jump-start in progress is in play: “they told us that if we only did it according to XP it would work”.
Summary
I don’t think there will ever be a prescribed process that works for all. XP was not it. Scrum was not it. SAFe is not it.
Start where you are today, make work visible, decide on what the overarching strategy is2 and continuously evolve towards that goal. Little by little, in short iterations.
Pick and choose practices from whatever method or process you think will help you. Try it small at first and if it works do more, if not try something else.
Be relentless in your communication about the goal of your process (flow over resource efficiency) and support the initiative from the top. Let the details on how be flexible and worked out as it fits the needs of the people involved. People are generally very smart when it comes to solve problems that concerns them.
Let the record show that I have nothing against SAFe, but I don’t think that it’s the answer. Either.