This is one of the most important questions to ask before (or when evaluating) an agile transformations effort. Me and my colleagues from Ugilic, have comprehensive experience in guiding leading companies on their agile journey. More and more often we are met with a desire for a scaled agile setup, and maybe the client already a have a preference for a Scaling Framework.
Before we continue down “that” road with the client, we ask them to press pause and step a few meters back…
It’s time to do a little thinking before acting!
In the past five years, the “agile word” has fast-tracked into almost every industry and has become a hot topic for top management. It seems like putting “Scaled” in front of “Agile” has become a standard for almost everyone, besides of cause the people that are actually working on in real Agile teams. All of us that have experienced the true power, of one or more agile teams, working focused together towards a shared goal, knows how important it is to simplify and descale when possible. So why is it that the “Scaled” version of Agile seems to be a preference for the masses?
Back to the question asked in the title of the post.
“Many agile teams or many layers of “agile” ?
Before we can discuss the need of a scaled agile setup in an organization, we need to agree on the meaning. If we are talking about making an organization, optimized for several individual agile teams’ ability to frequent deliver high quality products to the customer, then I think we could be on the right track.
If we, on the other hand, are talking about building several “agile” layers on top of the actual agile delivery teams, then we should be really careful.
The latter is often the case, when you visit companies who have implemented the SAFe© framework. Way to often I see companies, facilitated by consultants, in a failed attempt to implement an agile organization and culture based on SAFe©. They are measuring the success of the transformation by the ability of having a big room planning session every third month (PI planning) and the amount of control and management put into the roles of Product Management, Business Owners and RTE’s. I see department management transforming into what they call ART management. If you walk by the agile teams in such an organization, and ask them about their limitations, they point fingers at the upper layers of the SAFe(c) framework. So, the result of such implementation of multiple layers of “agile” is way too often restraining the real agility in the agile teams. So, in reality the only thing such organizations achieve, is a feeling of control and “new” management roles for the former team leads, project managers and department leads etc.
In my view, we should remove the A from most SAFe implementations. No doubt that they have implemented a Scaled framework, but it’s rarely Agile.
My clear advice, to any organization that is considering Scaling Agile in any form, is to be really careful not to limit actual agility in the agile teams. Dependencies between the agile teams is almost always adding extra complexity to planning, coordination, testing etc. If it’s possible to avoid the dependencies this should always be the solution. If not, we should educate the involved teams in how best to handle the specific dependencies. We should not do, what most do, move the handling of dependencies away from the teams by adding extra layers to the equation.
Take aways from this post.
- Many agile teams can be great, many layers of “agile” should be avoided
- Educate and coach the teams with unhealthy dependencies to other teams, how to handle/remove these dependencies
- Educate all managers in the core substance of agile teams, so that we avoid unnecessary anti-agile initiatives in the organization