Agility – Five Things It Isn’t

A Clown Being Agile

Earlier this year published an article that contained the results of a poll to find out what IT service management (ITSM)-related people were interested in reading in 2019. Near the top of the list was “Agile.” Therefore, I thought I’d make a contribution.

Here’s my key point: Organizations have to recognize what agility isn’t before they realize what it is.

Please read on to find out more.

The intent (with agile)

In 2001, at The Lodge at Snowbird Ski Resort in the Wasatch Mountains of Utah, 17 people from the world of software development got together to seek an alternative to the documentation driven, heavyweight software development process.

They named themselves The Agile Alliance and agreed on the Manifesto for Agile Software Development. Now referred to as “The Agile Manifesto” it consisted of four values and twelve principles.

The four values are as follows.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The first four of the principles ideates what the manifesto intended.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.”

In essence, it promoted increased agility through continuous and frequent delivery of a valuable product, continual feedback loops in order to incorporate changing requirements, and collaboration.

This was a call for a mindset change from delivery that involved a complete specification of requirements that had to be in place before a project could commence development, copious amounts of supporting documentation, an inability to change direction mid-course, development done in isolation from the business, and extensive periods of time before the business saw anything delivered.

It recognized a mindset change that valued people more than processes, just enough documentation to get work done, customer involvement throughout, and the ability to incorporate change along the way.

Unfortunately, what the manifesto intended has been misinterpreted or misunderstood by some. Let’s look at what agility (and agile) isn’t.

1. It’s not a noun

Much of the intent of agile has been lost in translation.

Agile has become used as a noun. It’s not a noun. It’s an adjective that means you can move quickly and easily.

Saying “We’re doing agile” is like saying “We’re doing rainy.” Saying “the age of agile” is like saying “the age of sunny.”

Saying “We are learning agile” is like saying “We are learning cloudy.”

We should be saying, “We are becoming more agile” or “We are looking at ways to increase our agility.”

We should be saying, “I work on a team that is agile” or “I work on a team that values agility” or “This is the age of becoming more agile.”

We have to get back to the basics and stop corrupting what was an important evolution in a way of thinking not only for software development but also for the delivery of any product or service.

2. It’s not about IT

Albeit it was in the world of agile software development that the notion of agility started, it’s no longer about IT. When change is volatile, uncertain, complex, and ambiguous but also constant, the entire organization needs to be able to quickly adapt and change direction.

Not doing so is a matter of life or death for organizations today. The entire organization needs to be able to experiment, innovate, be totally customer-centric, sense and respond, and be adaptive. It’s business agility that is needed to achieve this. Organizations need to be agile at every level of the business without exception. It’s these organizations that will not only survive in today’s volatility and unpredictability but also actually thrive. 

3. It’s not about control

You cannot “tell” people “We are doing agile now.” It’s not about using the word “agile” and expecting things to happen. You cannot use command and control to establish agility in the organization.

Agility is a fundamental mindset shift. You cannot command that and expect it to happen. Agility is about people, interactions, collaboration, and responding to change.

The fifth of the agile principles is:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

People have to be allowed to self-manage, have autonomy, and be allowed to get on with the job in the way they see best. Not in the way someone else sees it.

Teams need to be able to self-organize and act independently. They need to be trusted.

The team does not follow a rulebook or protocol. It evolves through self-reflection and continuous improvement.

There are methodologies and approaches to support agility such as Scrum, but you don’t want to prescribe exactly how teams should become more agile.

One of my clients has adopted widespread business agility. Every team across the organization has stand-ups, Kanban boards, etc. However, they are all doing it in ways that meet the needs of their particular team. Agility is not prescribed. Every Kanban board is slightly different but the principles of being agile are commonplace.

Trying to introduce agile ways of working into a command and control hierarchy is doomed to failure.

Trust is at the core of agile ways of working and command and control does not foster trust. Leaders need to learn that when they trust and let go of control, they actually gain control. At the core of agility are service leadership and selflessness.

The coexistence of hierarchical command and control along with agile ways of working just sends mixed messages to employees. They hear “You want us to create, innovate, collaborate, experiment, and learn but you want to tell us how!”

An empowered cross-functional team that is trying to move at speed but exists within a hierarchy of control in which decisions have to go up and down the chain of command will fail.

4. It’s not about the work

Agile delivery is all about the outcomes and provision of value. It’s not about the hours that are worked.

It’s actually all about agile principle number ten.

“Simplicitythe art of maximizing the amount of work not being doneis essential.”

It’s about removing things that don’t add value. This means focusing on the must-haves rather than the nice-to-haves. It’s not about the output – it’s all about the outcome.

Teams adopting agile ways of working put their effort into delivering the highest value to the customer with the least elements.

If you have managers who mentally clock their employees in and out and think that a visible presence for 7.5 hours every day is delivering value, then change them or change them (as in replacing them). They need to have an agile mindset along with their employees if the adoption of agility is going to even get off the ground in your organization.

It’s not a Band-Aid solution

I see so many organizations struggling to truly adopt an agile way of working because they haven’t addressed the underlying culture needed.

This excerpt from McKinsey and Company sums it up:

“February 26, 2018 – While many companies are striving to become agile, only four percent of survey respondents have completed an organization-wide transformation, the latest McKinsey research finds. The No 1. problem they cite is culture.”

The successful organizations recognize that the adoption of agile ways of working is an imperative in order to survive in a world of constant change but also recognize that this is not a Band-Aid solution. This is open-heart surgery!

These organizations spend an enormous amount of time and energy on laying the right foundations for an agile organization. They ensure that leaders are able to role model agile behaviors including customer centricity, self-management, self-discipline, autonomy, collaboration, adaptability, trust, experimentation, flexibility, and delegation while embracing constant change and uncertainty.

Is your organization really ready to become agile? If not, start laying the foundations now. Accept that it’s a journey and one on which everyone has to be on. There are going to be fundamental changes and tough decisions to be made along the way, but resistance is not an option. This is about survival and remaining relevant.

Karen Ferris
Director at Macanta Consulting Pty Ltd &

Karen is a self-professed service management and organisational change management rebel with a cause.

Acclaimed internationally as an author and speaker, with industry acknowledgement of her reputation as a thought leader, she provides both strategic and practical advice and insights to her audiences.

Her ability to share her experience and knowledge ensures that everyone is empowered to make a difference within their organisation.

She is the author of 5 book on leadership, change and workforce resilience.

In 2014 itSMF Australia bestowed her with the Lifetime Achievement Award for her contribution to the industry. She has contributed to many service management piublications.

For the last five years she has been voted one of the top 25 thought leaders in service management by HDI. In 2017 the Business Relationship Management Institute presented her with a Global Excellence Award and in 2018 CMI Victoria awarded her the Rebel Award for “The person breaking all the rules to make things better for all”.

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

One Response

Leave a Reply

Your email address will not be published.