The different definitions of Agility

One reason why getting different people on board in an agile initiative is because they may not understand what's in it - for them. We can put the different perspectives together by looking at the different definitions of agility. This allows us to negotiate better with people who have a different focus in their own work and gain their support for change.

Everyday definition

"Move quickly and easily." - Cambridge Dictionary

Note the two vectors here: Speed and effort. This definition doesn't focus on externally imposed change. Although only implicitly, it is primarily concerned with the ability to reach one's goals.

Managerial definition

Acting according to the current situation - Peter Drucker

“The greatest danger in times of turbulence is not the turbulence: it is to act with yesterday's logic.” 

Change is only a problem when we're not able to think and act in a manner suitable to the new circumstances. We must be sufficiently flexible to adjust when something unexpected happens.

Financial definition

"Turn on a dime for a dime." - Craig Larman 

There are business opportunities every day. Many businesses can't capitalize on opportunities for two reasons: Either, the cost of grasping the opportunity outweighs the gains from the opportunity (i.e., a negative business case). Or, the window of opportunity expires before we can grasp it.

Technical definition

"Minimizing the cost of change for code." - Kyle Griffin Aretae

"Cost of change over the long term is almost the only thing worth paying attention to when working in code. It's more important than doing any individual feature requested most of the time."

The initial creation of code is marginal compared to the cost of maintaining or changing the code. We have high code-level agility if there is a low cost of change for our code, and low code-level agility if we are spending a lot of time, energy and money to change our code.

The different focus

Looking at this diagram, we see that no single definition is all-encompassing - and that there is only a small overlap between them.

Hence, we have to be clear what we are setting out to achieve, and how we would like to achieve it.

• Do we want to increase sustainability and reduce effort? Unless we can tick these boxes, developers most likely won't care.
• Do we want to become more adaptive and faster? That makes our initiative interesting for management.
• Do we want to reduce cost and increase profitability? Otherwise, let's not assume finance will support us.
• If we're not in it to get more done in less time, surrounding stakeholders - like Marketing, Sales or Customer Service, won't care.

We can't dogmatically insist that we want to do only one thing, like increasing adaptability, because we'd struggle to get anyone to support this. Instead, we can use these different perspectives to have deeper conversations as to what people need from a change initiative, and how they would like to become part of this change.

And - the Customer?

Frankly - as a customer, I don't care about your agility. 

I care that I get what I want, how I want it, when I want it. How you do it - your call.