If your definition of safe, is like “no one has even been fired for choosing IBM”, SAFe may be safe. Though, you really need to consider, will it help your organization improve? I hoped that Scrum would help the world discover iterative and incremental engineering practices and principles. It seems to me, it has failed. Maybe SAFe can be different; I don’t know.
I have not spent any time looking into SAFe. I cannot make an informed opinion. I would make my opinion based on the message of SAFe and how it is being adopted. Generally, I am critical of what most Agile adoptions have become, Agile in name only (AINO). AINO adoptions leave developers feeling like they are being micromanaged and pressured to do poor work.
I used to think there were two halves to Agile, the technical half and the business half. I was having dinner with some people after a conference and I claimed that most organizations only do the easy half of Agile.
My colleague asked me what’s the hard half? I replied the hard half is a technical half.
He replied the hard half is a people half! I immediately realized, there are three halves! I’ve always kind of ignored the people half and focused on the engineering and planning halves. My colleague’s reply reminded me again of what Gerald Weinberg said: “no matter what the problem is, it’s always a people problem.”.
Does SAFe and do SAFe adoptions help organizations progress with the three halves of agile? Or, is SAFe repackaged command-and-control? I don’t know I have not looked that closely.
My interest is really the engineering side. You know, problem solving. The practice and attitude towards development is what attracted me to Extreme Programming (XP) in 1999, especially the engineering practices. In a way, Agile and XP are about continuous improvement. Improving the product, improving how we work and improving how we interact with co-workers.
It seems Scrum adoptions get stuck in the 'DO' cycle, iterating without the reflection and improvement.
Will SAFe have the same end?
As an engineer, I want to know what problem SAFe is supposed to solve. Is there is a logic chain from my problems to the solution? Even if it seems weird (like TDD at first) Is there a good explanation? If so, then SAFe might be a good direction for a company to take. This means people adopting SAFe can’t just be adopting SAFe because they want to scale agile. That’s not a reason. What problem led you to SAFe? Did you first get good at Agile at the team level and now are solving the next layer of problems? Why do you want Agile in the first place? What problems would you expect Agile to help you with?
Is SAFe about looking at the way we work? Is SAFe about recognizing our weaknesses? Is SAFe about doing continuous improvement? Is SAFe about respecting people? Does SAFe help people grow new skills so they can solve the next problems? When the pressure is on, will people do the practices of SAFe or will they rush at the end of a cycle to check all the check-boxes?
If SAFe puts you on the path towards those things then, maybe, for your organization SAFe might be worth it. If SAFe is just the safe choice (you know, like IBM) for adopting Agile and it does not have serious problem solving as its core, I doubt it’s going to help.
Maybe improvement really has to start with the individual, and the team. One of the things I’ve really come to appreciate about extreme programming is how its practices lead to continuous improvement. The XP approach helps people solve real problems. It helps us understand our fallibility as humans. It challenges us to make our product, our workplace and our lives better.
Starting in 1999, at Bob Martin’s company Object Mentor, we taught XP backwards. First we taught developers about incremental development (TDD, Refactoring, Simple Design, SOLID, Continuous Integration, Pair Programming), only later in the week did we talk of the planning practices. Guess what, incremental planning is easier if you know incremental development.
Looking at Essential SAFe, XP is mentioned. A lot of good things are mentioned. Though it concerns me that the SAFe Road map appear to get teams involved so late. I’m concerned SAFe will again, like Scrum, focus on planning and management. Without the team and technical skills people will feel the pressure to deliver low quality code.
If SAFe is where you learn to do agile so you can figure out how to be agile, maybe it will help. I guess time will tell.
If you are in an organization adopting SAFe, don’t forget, there is more to agile than the DO cycle.