Scaled Agile Frameworks have gained popularity among organizations worldwide over the last half-decade, with many major businesses undertaking massive organizational changes that impact thousands of people and their customers. Most invested in rigid adoption and conformity efforts to one of the Scaled Agile Frameworks and found that the results were far less than expected. Instead, teams were running into issues with morale, value delivery, and product innovation leaving people wondering what went wrong.
The problem lies outside the concepts within the frameworks and more on a misconception that transformations are a copy-exact compliance effort. Transformations are far more complex and complicated than that. Even Agile companies like Spotify, which introduced the "Spotify Model" for scaling Agile, understood this. That is why, back in 2012, when Hendrik Kniberg and Anders Ivarsson presented how Spotify had structured their Agile organization, it came with a disclaimer--learn from it, but don't copy it. They gave this advice because, simply put, your company is not Spotify. You don't have the same history, the same products, the same organizational complexity, or share the same culture. So you cannot simply ask people to emulate or comply with the way Spotify does work and expect to get the same results. In fact, this holds true with every other scaled framework as well.
This does not mean that the frameworks are without merit for your transformation effort. On the contrary, they have a lot of value in understanding different ways to design your organizational system to meet the business outcomes you are trying to achieve. In my work, we piloted and then adapted many of the scaled framework concepts and ideas into our company. Each out-of-the-box implementation was merely the starting point of our transformation work. We had to put a lot of energy into the learn-and-adapt cycle to evolve the framework into something that worked for the product we were trying to deliver. In some cases, the framework's evolution was almost indistinguishable from our starting point. But in the end, we had a well-balanced system that fit the organization's needs.
You can do this as well. The good news is that what you have learned has not gone to waste. It is all valuable insight into what is working and what needs to change. You need to step back from running your adoption as a compliance effort and switch to a transformative critical reflection and problem-solving model. Combine that with a set of well-defined transformation objectives and goals, and you will be well on your way to creating the system your company needs.
