The Agile Architect
Evaluating SAFe
You say you want enterprise agility and you think SAFe is the way to go? Our Agile Architect explains why you just might be right. Or are you?
In a previous Agile Architect column, Can Agile Truly Scale to the Enterprise?, I discussed my requirements for scaling agile to the enterprise. In brief, they are:
- Align around value streams
- Break dependencies where possible. Otherwise, manage them
- Ruthlessly simplify complexity everywhere
- Enhance communication
- Fight, fight, fight against rigidity
- Minimize unpredictability
For this column, we are going to see how the Scaled Agile Framework, otherwise known as SAFe, measures up against my requirements above. But first, let's talk a bit about what SAFe is.
The Basics of SAFe
One of the great things about SAFe is how well the methodology is documented. To see an overarching graphic of the entire process you can visit their Web site here.
The foundations of SAFe can be found in the agile manifesto which is expanded into SAFe Core Values (Alignment, Built-In Quality, Transparency and Program Execution) and Lean-Agile Principles.
There are multiple configurations of SAFe, all of which use a layered approach to scaling.
At the base layer of SAFe are multiple Scrum delivery teams. Newer versions of SAFe also incorporate elements of Kanban. Each delivery team has a Scrum Master and Product Owner.
Delivery teams coordinate at a Program layer by being part of an Agile Release Train (ART) focused on one or more value streams. The ART is managed by a Release Train Engineer (RTE) who coordinates and collaborates with the team-level Scrum Masters, a Product Manager who works with the team-level Product Owners, and a System Architect/Engineer who works with the developers.
Large Solutions that require more than one Release Train are managed through a Solution Train layer. The Solution Train Engineer, Solution Manager, and Solution Architect/Engineer coordinate with their counterparts in each Release Train.
At the highest layer, business and enabler epics from the portfolio backlog are managed using Lean Portfolio Management techniques to ensure that business value and learnings are derived as quickly as possible.
Across the entire SAFe organization, schedules are managed on a cadence that aggregates multiple Sprints into Program Increments. Within this, there are multiple mechanisms to allow time for exploration and management of schedule slippage.
How Does SAFe Stack Up Against My Requirements for an Enterprise Agile Framework?
1) Align Around Value Streams
Yes. One of the primary aspects of SAFe is organization at the Portfolio level aligned around value streams. In fact, Principle #10 is Organize around value.
2) Break Dependencies Where Possible. Otherwise, Manage Them.
Yes and No. SAFe has a great philosophy of breaking dependencies by "Deploy continuously. Release on demand." One way to accomplish this is by using the Branch By Abstraction strategy I wrote about in a previous column. By deploying continuously, multiple teams in a Release Train can share code in a very flexible way that minimizes inter-team dependencies. Release on demand ensures the deployed code is switched on at the right time for the business.
Beyond this, SAFe manages dependencies rather than break them. This is done through inter-team coordination and leads to a lot of the complexity that SAFe is criticized for.
3) Ruthlessly Simplify Complexity Everywhere.
No. SAFe increases complexity by layering on multiple layers of management and technical oversight. The presumption is that the complexity is necessarily inherent in the technology and organization or you wouldn't be using SAFe. Of course, SAFe doesn't preclude ruthless simplification, and while one could argue that it is inherent in any agile environment, SAFe does not address this as part of its methodology.
4) Enhance Communication
Yes. SAFe as a methodology has multiple paths of communication and ceremonies to ensure that all parties are in alignment. SAFe defines communication pathways between all of its parts.
5) Fight, Fight, Fight Against Rigidity
No. SAFe puts in place a very rigid structure. Modifications to the structure occur through publication of new versions of SAFe. This leads to the unfortunate effect of organizations that are used to a non-agile, rigid environment believing they have to follow SAFe slavishly. When colleagues tell me about their successful SAFe implementations, it usually starts with "Well, we're doing SAFe but…"
6) Minimize Unpredictability
Yes. SAFe has plenty of planning meetings and feedback loops to ensure predictability. In addition, SAFe builds in safeguards to allow time to deal with unexpected headaches.
Final Thoughts
SAFe is by far the most well known and well marketed of the branded enterprise-scale agile methodologies. It addresses many of my requirements. Unaddressed in SAFe is the need to continue to follow the basic tenets of the Agile Manifesto. For enterprises that are already agile, SAFe may be a good next step. For enterprises that are not yet agile, making the leap directly to SAFe, bypassing the experience of working with simpler agile frameworks, may lead to a mess.