Or “The answer is SAFe; now what was the question?” Or “We Need to Go SAFe Now!”

• Executive leadership
• Transformation coaches
• Transformation team

At a certain point in the transformation, executives realizes that there seems to be value in the “agile thing”. They have noticed that other executives seems to be gaining credibility because they are moving toward agile, and are reporting benefits. In addition to a genuine desire to improve, the executive will feel pressure to be seen to be doing something as well. A quick review of other implementations will show that other people are using SAFe. There is a nice website, with a lot of information that speaks the language of the executive (strategic themes, portfolio planning, etc), that seems to be well thought out, and shows a nice hierarchical set up where clearly senior people are identified away from more junior people. It also seems pretty safe to do. Not only are my peers using it, but there are all these case studies and it’s right there in the name. What could possibly go wrong?

Larger groups in particular gravitate to this model because it seems comfortable, controllable, and predictable. It certainly seems to make this whole agile thing (“which from what I’ve heard is pretty soft”) more concrete. It seems to be oriented to large organizations. In order to make progress, the executive starts driving toward this implementation, working to create a plan which, at the end will have all these structures and approaches in place - a project plan. You just build team, identify people into roles in the new hierarchy, do training, and ta-da! we are transformed and we can move on to the next initiative.

You’ll hear, “it makes me wonder why the agile coaches didn’t just say ‘do SAFe’ in the first place.”

And while this thinking is generic to other scaling frameworks, it is particularly pronounced with SAFe.

Let’s be clear, there is nothing wrong with SAFe. SAFe captures good values, principles, and practices, that are the gathered up the results of a number real world experiences. And I've used the framework in many situations.

The problem is that like all frameworks, it is a tool, and sometimes tools are used in the wrong context, and even if the context is applicable, the tools can be misapplied which do not produce the expected result or worse result in outcomes that you’ll regret in the future.

Let’s get specific for a moment and think through some of these potential problems and impacts:

• SAFe is primarily focused on the coordination of multiple teams where those teams have dependencies on each other. The structure (trains), additional roles (Product Manager, System Architect, Release Train Engineers) and ceremonies (PI planning, ART sync (scrum-of-scrums, PO Sync), system demos, I&A) are aimed at coordinating the efforts of multiple teams oriented toward a value stream. If you do not have the problem of aligning dependencies across multiple teams, then you might be putting bureaucracy in place that does not actually help with the flow of work. In addition to being very wasteful, this causes frustration in your people as the system being used to deliver doesn’t help work actually get done.
• SAFe is primarily aimed at train structures with 50 to 125 people. Because SAFe has mindshare and people understand that it helps with coordination of teams of teams, people think they need to apply everywhere. The reality is that you often don’t need the overhead of SAFe if you have only a few teams working together, even if there are dependencies between the teams. For example, the simplest solution to coordinate and align a couple of team is to have representatives from the teams effected get up and talk to each other about specific issues. This may sound “wishy washy” but why would you do anything more than that for smaller groups of people?
• SAFe is focused on fast delivery value. Value is identified as a result of value stream analysis / mapping from the perspective of the customer of the train requesting some feature or service. Most organizations are not organized this way but rather tend to be organized in silos of disciplines. Putting teams in place over this existing structure, and then scaling that structure to a train will not materially result in improved value delivery from the customer’s perspective which means, again, you have put additional bureaucracy in place for limited real gain.
• SAFe uses cadences (time periods) to align ceremonies and provide regular opportunities for feedback across multiple teams. This approach is useful when you have work that can and should be planned. We often see organizations who think that “all our work is break-in”. If the work really is all break-in, then these cadences slow down delivery of value and reduce our ability to respond to events. The reality is that most organizations actually have more work that can be planned than they think and so cadences could help. But if your work really cannot be planned, you will reduce the flow of value and your ability to respond if you use planning cadences.
• SAFe uses the concept of a “team” as the fundamental unit of execution. In the rush to get to a train (team of team) structure, many organizations don’t spend enough time focusing on developing great teams. We use the phrase “nail it before you scale it” to capture this concept. SAFe says “you cannot scale crappy code” but the notion applies equally to organizational structures.
• SAFe is a collaboration framework. The idea is that if you are a Product Manager, then you are part of a Product Management team with the Product Owners and the System Architects. Many people will look at the SAFe framework, will see a layer called “Team” and another called “Program” and will assume that this is a reporting hierarchy where the senior person tells the junior person what to do. While this might be a comfortable notion to the supervisors, this is not how SAFe is intended to operate. As said, SAFe is a collaboration framework. For example, it is the Product Management team that works the Program Backlog collaboratively. The Product Manager doesn’t just tell the Product Owners what to do. That negates the whole point of collaboration. At best, the Product Manager is the “referee of last resort” who breaks a tie if the Product Management team cannot make a decision. Similar thinking applies to all levels of the SAFe framework.

To repeat, there is nothing wrong with SAFe, except if you apply it in the wrong context or misapply some of the ideas.

Do not just assume you should put all this structure in place Day 1. There are a number of potential remedies:

• If you can, work with a seasoned agile coach or consultant to help you through the best approach to apply in your situation. The bottom line is that SAFe might be right for your organization. Or perhaps aspects of SAFe make sense. Or perhaps it doesn’t make sense at all and something else will improve value delivery for your organization. Irrespective of the approach, they can also help you with sequencing the initial steps, leveraging learnings as you adopt new approaches, and establish an execution model that is sustainable after the consultant is gone. Note that this approach requires significant investment in time from leadership involved. (Also: I realize this a shameless plug for consultants:-))
• If you cannot work with a seasoned agile coach or consultant, start small. In general we call this approach “DIY Agile” and there is absolutely nothing that is regrettable about this approach. The idea is to start by developing agile teams, working with them to improve over time. This approach requires that people are trained in the new agile values and principles, as well as roles, ceremonies, and artifacts that are used to kick teams off. Then make sure the team is having increasing direct conversations with their customers and continuously work to improve their processes.

No matter what approach is taken, there is significant organizational fortitude required to do this as agile represents a fundamentally different way of thinking about work which often causes friction with the existing organization. For example, teams are stood up as stable, long lasting structures which mean that you don’t bring people to work (eg a project) but rather bring work to a team that has the capability to work. For this reason leadership has to “lean in” and work with the team through the process - this is not something you can just say “make it so”.

• Pure operations group wanting to go SAFe. There were two problems here. Firstly the group represented about 3 teams which really meant the SAFe bureaucracy was overkill. The second problem was that a lot of the work was incident management and so difficult to plan to a cadence. Organization went more DIY approach, growing into the structure they needed, and reporting good results (especially around work visibility).

• Source: What Kinds of Problems Do you Typically See As The Organization Transforms to Agile / Lean?
• Why Should We Work Harder to Eliminate the Effect of Dependencies?
• Why Do We Establish a Cadence of Events?