Agility over agile, more than word play
Is it just me or is the world moving away from agile and towards agility?
That may sound like a silly question. I’m prepared to admit it come as much from what I want to happen as to what is happening. Perhaps it is confirmation bias, but it feels like there is a change in the air. It’s a change I’m all for – I was talking about the need for agility over agile over 10 years ago (Objective Agility).
It might seem like a small semantic change to go from “agile” to “agility” but it is a change from “doing agile” to “having agility.” It is a move from “means” to the “end”. From “the way of doing things” to the “outcome.” Rather than emphasis “the way people work” the emphasis is “what is the end result?”
That is a good thing. By definition agile methods, and agile frameworks (Scrum, SAFe, Kanban, even Xanpan) describe how to work. There is an assumption that if one works that way one will achieve agility. In reality there are many different routes to agility. Some look like Scrum, some like Kanban, others don’t. Some people find their own way to agility.
I always introduce agile by asking: “What do you want agile to do for you?” The agile toolkit can be used for many ends.
With agility the answers are pre-defined: agility is both ability to move fast but also the ability change direction and manoeuvre with haste. In order to do that information is needed (learning), and that information needs to be acted on (decision making) – feedback loops again. Maximising agility means pushing that learning and decision making down to the lowest level: giving the people who do the work authority and trusting them. This is where digital tools come in and is why digital transformation demand agility.
Agile Beyond Software
There are two forces driving this change. First off is the expansion of agile beyond software development and into many other fields. As I’ve said before: digital tools spread the agile virus.
As other fields – marketing, law, research, and more – adopt methods which were originally for software engineering some tools need changing. Sure, some tools work just the same – think daily stand-up meetings. Others need rethinking: test first thinking needs a little work when testing is not the norm. And some don’t work at all: Unit testing.
A couple of years ago I saw Scrum forced on people not in software. These people did not always work in teams, they time sliced between different activities and who had to handle a lot of unplanned, urgent, work. The emphasis was on “doing agile” rather than “being agile”. Despite some valiant work it was a mess.
As we apply agile thinking away from software we need to emphasise the outcome rather than the method.
Business Agility demands more
Second, talking about agility, and in particular business agility, puts the emphasis on the whole – the wider context. That is to say: you can have the most agile team ever but the wider organization can stunt agility. The wider organization also needs to hear customers and adjust efforts: budgets, portfolio, governance and other teams also need to work agile so the whole enterprise can have agility.
Summary
Yes: agility over agile might be semantics but it is an opportunity to change the emphasis:
- Prioritise outcomes over methods
- Seeking agility outside of technologists means embracing more variation in how teams work
- It is not enough for teams to be agile, the wider enterprise needs to challenge how it works
Finally, agility is not binary. One might work agile or might not work agile, but agility is measured on a scale. How much agility does your company have? – it might be zero, it might be 10, it can always go higher.
Agility over agile, more than word play Read More »
