“A problem is a statement of the difference between the current state and the desired state.”
Before a solution can be designed and implemented, the problem must be understood. When it comes to Agile transformation, too many people are jumping in trying to force a solution before understanding the problem. There are devoutly loyal consultants fixated on a solitary framework for solving every quandary. That’s the equivalent to using a hammer on every project around the house. It’s an awesome tool when building a wall, not so awesome when you need to paint the wall. You *can* paint with it.
Just because you can doesn’t mean you should.
Solving the problem could entail just tweaking existing fundamentals. No need to bring the sledge hammer for something like that.
The solution could be as complex as implementing an entire portfolio driven, value based, framework. A jewelers screwdriver won’t fix that.
Not all organizations have the need, or comfort level, to transform from a highly matrixed hierarchy to a lean startup. Take time to assess where an organization is currently, where their desired end state lands, and fix the problem that needs to be solved.
There are a variety of options available. Fill your toolbox with an assortment of instruments. The fact that (any Agile framework) solved the problem previously has no bearing for how to resolve the current situation. Step back, listen to what the problem is before suggesting the solution.