These days when you talk to a manager in no matter what industry, after only two or three sentences he or she will say that their organization is an agile workplace too. The explanation that invariably follows is filled with phrases supplied by the marketing world. “We work in tribes, but also in squads” and “we no longer have bosses, but product owners and squad leaders”, and so on. The source, as it turns out, is Spotify’s organization model, a working method that appears to be a shining example these days for several big multinationals. The aim of agility, which managers are keen to propagate, is to enable your organization to keep up with the increasing speed of society. After all, we need to respond with lightning speed to anticipate today’s fast-changing world. Which is fine. But to me this seems more about keeping pace with the masses. As someone who has been around the block in the business world, I think it’s yet another collective hype. Does anyone know exactly what agile is?

We in the IT industry have known this agile working for a while, of course, because we started it. Around the last turn of the century, a group of software developers wrote a statement called the ‘Agile Manifesto’, listing the insights and principles on best practices in developing software that they had learned in the previous decade. Just as a recap for the non-IT people: When you develop software in an agile way, you try to reduce the risk of (big) mistakes as much as possible by delivering something usable in short, easily surveyable periods of time, daily, one week, or two weeks, or four weeks max. These periods are called lead time or sprints. Within each sprint you run through the entire production cycle: analysis, design, build, testing and delivery. The trick is to deliver something after each sprint that can actually be used. When you deliver something that does not exactly do what it should, or that has small mistakes in it, it’s not a disaster because the production period was short and so the damage is limited. Incidentally, working by cycling - the thing I like to talk about - is also agile working. The difference is that the cycling metaphor covers a whole spectrum of ‘getting things done’.

Occasionally I take an interest in one of those conversations about agile working and I ask some questions. I try to find out where exactly the agility is in this manager’s new working method, and does it make the entire organization truly agile? Are the lines shorter now? Are the hierarchy and bureaucracy gone? Does new features get delivered while business operation is running and if so, can you actually use them? Sadly the heads droop a little at that point in the conversation and people summon their courage for a last defense. Are there really any organizations yet in this world that structurally offer their services and products in short, surveyable periods of time? Organizations that make small mistakes without immediately and seriously harming the production flow?

Unfortunately, so far my conclusion must be that the agility most managers talk about is nothing but a marketing story with an apparently collective credo. Departments, sometimes entire businesses are overhauled. Some mixing and matching takes place, and afterwards everyone does more or less what they did before, except managers are now called ‘product owners’ or ‘squad leaders’.

In the context of IT and the organization, agility is a many-headed monster. Is it in the collaboration between the workers? In the culture? In the governance? In the IT production process? From idea to IT? In technology management? In the infrastructure? Or in all of the above? In my experience there is one constant to be discerned: you get agility in an organization if the work gets priority over the people. Managers (or tribe leaders or product owners) need to focus mainly on organizing the work and the collaboration needed to get the work done. If they can pass by people’s functions and pay more attention to the roles people can play in the process, they would achieve more with the same number of workers. There would be less waiting around for people within the organization to ‘do their thing’ and the flow of the process would improve. People who get to work in that flow will do so in a wonderful state of relaxation and peace of mind. It will allow them to achieve more, in a more intuitive way, and to anticipate internal and external changes. In other words: hyper agile. Agility without performance is basically jibber-jabber.

There’s an extra bonus too: people feel better in a flow, so it’s even good for their health!

Sincerely,

Hans van Bommel,
Digital Transformation Accelerator