In the world of Agile development, SAFe has become a popular framework for organizations to adopt. However, some people believe that SAFe is just Waterfall with an Agile twist. They claim that SAFe is just a translation of Waterfall into the Agile world. But, these people are wrong. SAFe is built from the ground up on Agile principles, not a mere translation of Waterfall.
To understand SAFe and its origins, it’s essential to look at the history of Agile. Agile was born in the 1990s, as a response to the slow, bureaucratic nature of Waterfall. The Agile Manifesto was written in 2001 by a group of software development leaders, who recognized the need for a new way of working that was flexible, adaptable, and responsive to change. Agile values and principles were designed to help teams deliver value quickly and efficiently, by breaking down large projects into smaller, more manageable pieces.
As Agile evolved, it became clear that some organizations were struggling to implement it effectively. This was particularly true for large organizations, where multiple teams were working on complex projects with interdependencies. These organizations needed a more structured approach to Agile, something that could provide guidance and support while still being flexible enough to accommodate change.
This is where SAFe comes in. SAFe (Scaled Agile Framework) was developed by Dean Leffingwell, who saw the need for a more structured approach to Agile at scale. He developed SAFe to help organizations implement Agile principles across multiple teams and departments, with the aim of delivering value to customers more quickly and efficiently.
So, how is SAFe different from Waterfall? The answer lies in the underlying principles and values. Waterfall is a rigid, linear approach to software development, with distinct phases that must be completed in order. SAFe, on the other hand, is based on Agile principles, which emphasize flexibility, collaboration, and continuous improvement. SAFe borrows some concepts from Waterfall, such as the idea of planning and release cycles, but it is not a Waterfall-based framework.
To illustrate this point, let’s look at the example of religion. When I was a kid who practiced the Catholic religion, some other kids would claim that Catholics are not Christians. That boggled my mind. This same conversation happened multiple times, based on a lack of understanding of Catholicism’s identity as a more traditional Christian religion. I was just as dumbfounded then about how people could maintain that stance as I am today that people still think SAFe is really just Waterfall. Maybe badly implemented SAFe is more like waterfall, but when done right the two are not very similar if you dig into it.
Catholicism is an application or framework of Christianity, which has its own unique beliefs, practices, and traditions. Similarly, SAFe is an application or framework of Agile, with its own unique set of practices and principles. While some Agile/Scrum purists take one look at SAFe and think “oh no, that doesn’t look light weight at all (and to be fair, it isn’t), that seems like it’s just Waterfall all over again.“
To further illustrate my point, we could compare Waterfall to a different religion, perhaps a Pagan religion that was practiced at the conception of Christianity, but no longer practiced by many people today. Just as Catholicism may borrow some concepts from Pagan religions, such as festivals and other practices, SAFe may borrow some concepts from Waterfall, but it is certainly not Waterfall.
SAFe is not just Waterfall with an Agile twist. SAFe is built from the ground up on Agile principles, with the aim of helping organizations implement Agile at scale. SAFe borrows some concepts from Waterfall, but it is not a Waterfall-based framework. SAFe is an application or framework of Agile, with its own unique set of practices and principles. Just as Catholicism is an application or framework of Christianity, SAFe is an application or framework of Agile. It’s essential to understand these differences to implement SAFe effectively and reap the benefits of Agile at scale.
