Stop calling it agile
We should stop calling it agile and start calling it modern company culture. In the past fifteen years the word ‘agile’ has become widely popular in software development and other technology affine areas of business, but still people find it hard to find a consensus on what ‘agile’ means for them or their company. There seems to be an agreement that agile development contains such processes as scrum, kanban, xp or on a bigger scale SAFe, Less or any of the other frameworks out there. But an often heard complaint by people involved in software development is, that they are never “100% agile”. Or that they do scrum but find it hard to get that elusive culture shift happening in their companies.
And then there are these agile conferences where the talk is no longer about “how to apply scrum” or similar, but about holocracy, servant leadership, change management, T-shaped employees and so on. ‘Agile’ has grown out of software development - a good thing in my opinion - but we fail to adapt the wording to a larger scale, which makes it hard to explain certain concepts in a way that it produces an aligned understanding in people outside software development or the agile community. As a consequence ‘agile’ is still heavily connotative as a pure ‘development-methodology’ in a lot of business circles.
We are no longer talking about changing single teams of software developers but about building agile companies. We are advocating flat hierarchies, management by peer, role- and context-based responsibilities, planning on the fly in a vertical manner and much more. We want the co-located, cross-functional team but fail to take HR with us and thus try to build teams on inflexible and too slow processes for people development. So we get them on board and call it agile HR - I still find it hard to pronounce that out loud. Then there is the gap to sales which is still selling fixed scope, fixed time projects to customers expecting exactly these kind of projects. So we apply a fast act-sense-respond principle and products-over-projects mindsets to sales and marketing and integrate them closer into our development teams. Now everything is somehow controlled and tied in to finance and budgeting, arguably one of the facets of a company that is perceived as distinctively un-agile. No problem, we agilize the middle management, throw away all those layers of reporting and create a lean-startup structure in the company. And suddenly we’re talking about completely reorganizing and restructuring companies, something traditionally done by C-Level executives and not by up-start developers with a fancy title.
And yet we task a “scrum master” with it. A good thing, however with a title very unfitting for work on that level. Let’s call this position at least “agile coach”, but maybe we should go even further an call these roles “Change Champions”, “Chief Change Officers” or “Company Transformation Experts”. This might help with moving us coaches out of (software-) development and into the other circles of a company. And while we’re on it, let’s call it “modern company culture” and treat “agile development” as a subset of it, which helps us to go there.
Does renaming really help? Yes and no. “No” - because having a clear label like scrum, kanban or SAFe makes it easier to introduce those things, partly because the abundance of information that can be found to each of these topics. And “Yes” - because having it propely named helps us to manage the expectations better from the beginning, by taking away the bias of it being methods only fitting for (software-)development. Additionally it would be a great marketing tool, because which company does not want to be a “modern” company?
Coaching is a lot about wrapping a goal into the right words for the right ears at the right time. But it is also high time that we start selling accordingly. Yes, we should keep using the word agile, as it still helps us defining where we want to go, but maybe we should use if as a subset of this “modern company culture”. And when we do that make it clear from the beginning that we aim at transformations deeper than just changing how software is developed.