As Agile Coaches, we all hope for those engagements where everything goes by the book. After the contract is agreed to, the customer goes with all your recommendations and the engagement goes smoothly from start to finish.
While this is the ideal scenario, I have never seen an engagement play out anywhere near to that. Organizational resistance, while expected, can be stronger than initially thought. Customers may decide that your recommendations are too expensive, time consuming, or not necessary since they’re already “Agile”. These deviations are more what I see when I am on an engagement and I plan for exactly this type of environment.
Of course, the other side of the coin is the customers may apply Agile rigidly and not allow for adaptation and experimentation, their LACE becomes the Agile Police and goes after anyone who deviates even slightly from the dictates set by the Agile Coaches.
I was recently working with an organization on a first ART launch. The lead coach had recommended standard steps: SAFe for Teams training, identifying people for roles, prep work in advance, followed by a first PI Planning. The lead coach would hang around for some time after to provide support as the ART got running. After signing the contract, senior leadership started asking to remove some of the work. First came combining some of the roles, making changes to the prep work, and eventually removing training for team members. The company had been going through a lot of changes and leadership was concerned that team members were overwhelmed with change fatigue. We replaced the training with a half-day overview, adjusted the scope, and advised their leaders of what the changes to the outcomes would likely be. The launch went off decently, but the customer has yet to achieve the value from using SAFe and is aware of the limitations.
Another scenario where I was the lead coach, we were helping a hospital chain’s IT department launch their first ART. When it came time to put people onto teams, the recommendation to the customer was we wanted people 100% committed to the teams. The CIO countered with “that’s not how we operate here. We need people working on multiple items simultaneously.”. We explained that they will likely not see the best value from this but we will proceed as instructed.
As consultants, we recognize that we need to meet our customers where they are. While we have suggestions that can help them better outcomes, they may not be in a place where they are ready to take on the effort to realize those benefits. Other times, customers may want to religiously follow SAFe to the letter and that can stifle innovation and adaptation. It is important to take a balanced approach to get your customers the best value they can achieve now. If we do well enough, we can come back later and help them again to get a bit better.
I like to think of SAFe as a large and complicated tool. Think of a machine that could build an entire house for you, from digging out the foundation, to painting the walls, roofing, to even grading and paving the driveway. There are a lot of moving parts and it is very complicated to operate. For some jobs you would need only parts of the machine, in other cases, you might need the whole thing. The key is recognizing where your customer is, where they want to go, and how amenable they will be to hearing and implementing your suggestions.
SAFe has also long since recognized this reality and, while this was previously implied but not stated, it is recognized that SAFe can be adapted based on need, but there is guidance to ensure that we do not lose the spirit of the change. In the article Customizing SAFe, the team at Scaled Agile have laid out some guidance to help organizations that have a need to adjust the process due to mitigating circumstances in their environment.
The first thing I would like to highlight arrives near the top of the article. Customizing SAFe means bringing in experienced change agents who have the experience to understand the intent of the change and how to adapt the framework to still provide the best value for the customer. Freshly minted SPCs will likely not have the field experience necessary to understand what can change and how to make it work well. The heart of the article, however, points out the four guardrails to customizing SAFe. Let’s review them below.
Enhance agility RATHER THAN compromise the essence of SAFe. This means that you should know and understand the heart of SAFe. To know what you must do to adapt SAFe, you need to have a deep understanding of the Lean Agile Mindset, the four Core Values, and the Ten SAFe Principles. If you have ever been in a Leading SAFe or Implementing SAFe class with me, this is exactly why I hammer home the lesson on the Mindset, Values, and Principles as being key to understanding SAFe. When you’re having to change direction, go back to those articles, and review them to understand how to best change to help your customer while keeping the heart of the transformation stable
When it is the right solution RATHER THAN the easiest thing to do. Large scale organizational change is HARD. Imagine if I went to my doctor and told them I wanted to lose 25 pounds. Of course, my doctor will come back with suggestions like get out and exercise, eat healthier, and avoid sugar. If I tell my doctor that I will not change my diet and exercise routines, how successful do you think I will be? The same thing applies to companies wanting to become Agile. If you want the results, there is hard work you need to do to make it happen. You need to work with your doctors Agile Coaches and work with their recommendations to achieve results. Now, if you think you need to adjust the framework, ask yourself whether this is being done out of necessity, or because we are not wanting to make the effort to change?
Amplify outcomes RATHER THAN maintain the status quo. This lines up with the previous guardrail. If we are just reinforcing the current operations and keeping things safe and not SAFe, we should ask if we are avoiding the hard work of helping the organization become better and stronger in favor of maintaining our current ways of working because “we’ve always done it this way” or “we don’t want to rock the boat”, we should evaluate why we are changing the process.
And, finally, optimize systematically, RATHER THAN solve local problems. As we are looking at the implementation and how to tweak it, we should look at the system as a whole and find ways to optimize the individual parts of the organization in support of the entire organization, rather than optimizing only pieces at the expense of the entire system. This goes back to the heart of SAFe Principle #2: System Thinking. We need to look not only at our small piece of the pie, but the entire pie when thinking about how to optimize. Optimizing components only helps that small piece, often to the detriment of the rest of the organization.
In summation, I just want to bring the perspective that as you are either coaching a customer or working in an organization wanting to become more Agile, SAFe is not a rigid structure that should be applied strictly, it should instead be held lightly and nudged as long as you understand the guardrails you should maintain in order to be successful.