Dominik Berner

C++ Coder, Agilist, Rock Climber

Project maintained by bernedom Read the privacy statement for this blog

Don't fear large scale agile frameworks

Don't fear large scale agile frameworks

Agile is successful and we know it. For years we scrum masters, agile coaches and change champions advertised and trained developers in the agile principles and the many frameworks and ideas out there. We have seen teams and individuals grow and become self-organized and empowered. It was fun but tough work. We grass-rooted ideas with the developers and helped people changing their minds about “how we work”. And it was frustrating when we hit the hard wall of culture-shifting whole organizations instead of just teams. Our teams worked well but somehow the movers and shakers of the companies needed a lot more and a different kind of attention to bring them along. Suddenly the ideas and principles we instilled so successfully into cross-functional teams of developers, testers and engineers were under harsh critique. Somehow there always seemed a someone up a higher level that did not agree with what we tried to achieve. Countless stories of trying to put scrum into action on a contract that is essentially waterfall are a strong indicator to that.

And then a few years back there was a shift. The big consulting companies such as McKinsey, PWC, Gartner and many more started advertising agile and agile leadership. “agile” became “Agile” - with a capital “A”. The word now is: “If you’re not agile, you’re going to file bankruptcy soon.” Maybe reality is not that dramatic, but the direction of movement became clear. Pulling on that momentum, agile frameworks for larger settings such as SAFe, LESS, Disciplined Agile (to name the big ones) were thought out and put to the public. Wow! These were well documented processes that spoke the same language we did when we coached teams. But wait a minute - Did we not state “Individual and interactions overs processes and tools”? And those large scale applications of the agile frameworks somehow look way more like rigid processes than those people-based approach we had before?

Yes they do. And parts of the agile community started to pick them apart because of that. SAFe has the image of cementing existing hierarchical structures and to encourage command-and-control behaviors in “those in the upper part of the hierarchy”. LESS walls teams into a rigid form of scrum instead of letting them discover their best approach to the usage of scrum. Each framework has its “yes-but” aspects. It seems these large scale approaches compromise our beautiful agile world. These large scale frameworks seem to take what we did so successfully in the past and put it into a too rigid corset, compromising our original idea of agility.

Yes, those frameworks put more structure around the almost anarchistic way of how we often imagine the agile world. When applying SAFe or LESS there is less of “Let’s do it!” and more of “Let’s make a plan of what we’re doing and see what’s working”. Planning is something larger companies seem to rely on much more than smaller organizations. I doubt that this has to be that way for bigger companies, but it surely is a reality at the moment. However, this increased focus on planning is often needed to sell agility to organizations where the grass-rooting approach of introducing agile on a team level did not yet yield the desired result.

In my opinion it is a good thing that companies start to want to introduce agility on a larger scale. More and more initiatives to introduce the agile mindset in a company come top down from C-level executives and that is good! This shows that the idea behind the agile manifesto has matured and can be applied outside the nerf-gun-stuffed offices of engineers. But it also forces us coaches to think differently on how to introduce the agile mindset and methodology.

It is not that our free-for-all idea of agility gets compromised. It is us that need to compromise and grow. Over the years we got real good at making individual teams go fast and have great impact with the products they develop. But as the ideas get adopted and implemented on a bigger scale we need to think and act on a bigger scale. The pure logistics of agilizing an organization of 50+ people or even larger make it hard to find time to talk to everybody. With so many people we need some kind of structure where we can share the coaching work. On an organizational level we need to put effort into aligning all those teams in mindset and standard practices. And the large-scale frameworks help us with that. They establish standard operation procedures and a common language for a lot of the common tasks and challenges. And by being very specific and well documented they help us breaking up old structures and promoting a new agile mindset.

Of course part of that new mindset has to be that neither SAFe, LESS or any other large scale framework can be implemented and just be left there and to be done. So while they might be implemented rigidly at first it is essential to grow past them and keep moving and adapting when the first dust has settled. Here the same principles as when coaching teams come into play. Have retrospectives on a bigger scale, identify the pain points and experiment and measure to get better. The same as individual teams, organisations should never stop changing, there is always something to work on. So don’t be a afraid of large scale, top-down introduced changes, but use them to everyones benefit and don’t get stuck in the first implementation of these frameworks.

Written on May 7, 2018