A ton of SAFe related stuff made it across my desk this week. More than the usual amount. Some of it was positive, some of it was negative, some of it was old, and some of it was some new—but it was all asking the same fundamental questions. Has SAFe become 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.
A Brief History of Agile
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 a clear backlog, and they need to be able to produce a working tested increment on some predetermined interval.
Now, 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. However, 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, and they must have some degree of independence from the rest of the organization.
Let me be clear. Most organizations can’t form teams like this. A lot of organizations have:
- Tightly coupled, non-autonomous teams
- Poor alignment to the business
- A lack of good tests
- Code bases that are not safe to make changes
- A matrixed staff
Shall I go on?
So, What is SAFe
Here’s the deal, you either create the conditions to do Agile well—Agile as it was defined 14 years ago—or you do something else. That something else is called SAFe.
It encapsulates a larger, more enterprise focused, value stream. A value stream that really does exist in most large organizations and can’t be ignored.
Again, I’ll say it one more time for emphasis—either you create the conditions to do Agile well, or you do something else, and SAFe is that something else.
What’s the Verdict?
We can say that SAFe is a cop out, that it 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 do Agile well at any kind of scale. However, 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.
Personally, I 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… However, 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?