As part of a previous role I once asked members of an online group how they would describe “Agile” to someone if they had 30 seconds to do so, for example giving an elevator pitch in a lift. My favourite response was; “I’d push the stop button”.

But why do we struggle so much with defining agile in a business sense? Although, arguably project and programme management have existed for longer, both have fairly clear definitions when compared to range of responses you would receive asking the same thing of agile.

Recently published guidance from AXELOS® (the owners of PRINCE2® and MSP®), seeks to provide clarity by breaking agile down into three areas;

  • The first is Agile (note the capital “A”) which refers to agile tools and techniques such as Scrum, Kanban or even ceremonies such as the daily stand-up. We can think about these as proper nouns in the sense they are tangible named approaches which come under an umbrella of working in an agile way
  • The second is agile (note this time no capital “a”) which refers to a way of working which embodies the ethos behind agile. Some of these traits include flexibility, a quickness to respond and adapt to a current situation. The purpose of this distinction is to draw a line between using an approach such as Scrum and defining yourself as working in an agile way. An individual or organisation could either use Scrum or not, but either way, it doesn’t define whether they are agile
  • The third is agility (or for an easier distinction enterprise agility) which seeks to define how agile an organization. This is not simply whether an IT delivery arm uses Scrum or defines itself as agile, but how the whole organisation operates and embodies agile principles.

While some of these differences may seem nuanced, it is, I believe, an important step to try and clarify what agile is, what the benefits of using (or being) agile are, and how individuals and organisations can tap into those benefits.

My favourite example of the misuse of an agile tool is that of a Kanban board. Walking into many offices you will often see a Kanban board displayed as having all of the tasks “In Progress”. This directly contradicts the main objective of using Kanban to efficiently optimise workflow by limiting work in progress. When used correctly it’s a powerful tool, but its misuse can lead to incorrectly blaming failure on the tool or technique.

The tribal nature of some pockets of agile communities creates a sense of “mine is better than yours” leading to a one size fits all approach to embracing agile ways of working. The problem with this is while all major Agile methods and tools offer great value to those using them when adopted and adapted to the right situation, they cannot be used for everything.

When I attended my Scrum Product Owner training one delegate was a product owner for an organisation who built parts for space shuttles. Now while there would be many valuable principles, tools and techniques from agile they would be able to leverage in their role, they spent the entire training course battling how Scrum could be applied to their situation. It felt like trying to put a square peg in a round hole.

A major challenge to successful agile adoption starts with the definition, leading to the lack of understanding of the strengths and weaknesses of the array of tools and techniques available le to practitioners. I don’t believe it will be long before agile is blamed for a number of high profile failures, and I highly doubt that any of these will be in an instance where an agile tool was deployed in the environment it was designed for.

The benefits of effective agile working is huge, but it those who are aware of the array of options available to them, understand the environment they are working in and effectively apply the right tools who will see the greatest rewards.