It seems this week more SAFe related stuff than usual made it across my desk… some positive, some negative… some old, some new… but all asking the same fundamental questions. Is SAFe the savior of all things software development? Is SAFe really agile or merely the second coming of RUP? Will SAFe survive or be relegated to the ever growing list of failed approaches that have come and gone over the past 30 years.
Here is my take… it doesn’t matter.
Agile as it was defined 14 years ago is basically a lightweight framework for building software. Agile is predicated on the notion of small teams, colocation, onsite customers, lightweight documentation and frequent opportunities for feedback. These teams need to be sufficient for solving the problem they are formed to solve, they need to have clear backlog, and they need to be able to produce a working tested increment on some predetermined interval.
If you go one level deeper, agile teams need to work within a code base that is well architected, wrapped in tests, and safe to make changes. That code base needs to be supported by a team with autonomy to decide how best to solve the problems they are formed to solve. That team needs to be tightly aligned with the business objectives of the organization they are formed to support. They must have some degree of independence from the rest of the organization.
Let’s be clear…most organizations can’t form teams like this.
Most organizations have tightly coupled, non-autonomous teams….
Most organizations have poor alignment to the business…
Most organizations don’t have good tests…
Most code bases are not safe to make changes….
Most organizations are staffed as matrixes…
Should I go on?
So here is the deal. You either create the conditions to do agile well… agile as it was defined 14 years ago… or you do something else. SAFe is that something else. SAFe is a mechanism for wrapping the complexity of organizations that won’t reduce that complexity. SAFe encapsulates a larger, more enterprise focused value stream, a value stream that really does exist in most large organizations and can’t be ignored.
So… I want to say this one more time for emphasis… either you create the conditions to do agile well… or you do something else. SAFe is that something else.
We can say that SAFe is a cop out… or isn’t really agile… or that it’s the second coming of RUP… but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can really do agile at any kind of scale. Some organizations simply can’t or won’t invest in this. At the end of the day small batches are better than big batches. Iterative and incremental is better than waterfall, even if it isn’t agile.
I personally don’t think that SAFe is bad… or that SAFe undermines what we are trying to do with agile in the larger scheme of things… I do believe that SAFe will be better for some companies, some of the time. SAFe isn’t the way that I’ve chosen to tackle the enterprise problem. I want to work with companies that do want to fundamentally decouple themselves and have a shot at doing agile as it was originally envisioned…
But I’m pragmatic enough to know that can be a long road.
So… where does that leave us?
I think we should acknowledge SAFe for what it is and move on. Like I said, SAFe will work better for some companies, some of the time. It will be better than waterfall. I think it will be better than RUP as commonly practiced. I think it will be better than trying to do agile in companies that aren’t willing to create the conditions to do agile well. There will be some of us for which SAFe won’t be good enough, but that is okay too. SAFe will be better for lots of folks.
It all depends on what you value. Ron Jeffries said one time… ‘how good do you want to be, and how fast do you want to get there’?
Even though we don’t teach SAFe at LeadingAgile, I think for some SAFe can be a valid part of the journey toward greater agility… it might not get everyone as agile as we’d like them to be… but that’s probably okay too.