Agile viewed in three dimensions
Understanding what Agile is can be a huge challenge for anyone who isn’t familiar with the details. How can they navigate the complexities when it seems like “Agile” means so many different things to different people? How can the wider business hope to understand the implications of Agile if the practitioners themselves don’t seem to agree?
Agile is often portrayed as a continuum from “Waterfall” at one extreme through “Hybrid” to “Agile” at the other end. However, this linear view is too simplistic and is a core reason for the confusion. To understand “Agile” (and where it may have value to your organisation), you need to view it not as one dimension, but three.
While the Agile debate has become increasingly polarised, I am in the unusual position of having a viewpoint from multiple sides. I spent a decade leading processor program delivery in Arm, a world leading semiconductor company. Probably the most talented team I’ve ever worked with, delivering long, planned projects with 100+ people over three years and three continents. Then I have spent the next decade leading engineering teams in small, rapidly scaling software companies, where I have been coaching and writing about Agile good practices.
First, let’s step back and agree some of the language.
Is “Agile” a single concept?
Here’s a typical definition of “Agile” from a Web site found in a quick Google search:
The Agile methodology is a collection of project management frameworks that break projects down into smaller phases
Alternatively, here is another from a different site:
Agile is a lighter weight approach to project management and product development that is customer-centered, team-based, flexible, and collaborative.
You wouldn’t suspect they are talking about the same thing! “Agile” seems to be used to cover so many different meanings it’s no wonder people are confused.
In general terms “business agility” refers to being able to change strategy easily to respond to market changes. There seems little disagreement about this, although it is a very broad term. I generally refer to this with a small “a” as “agility”, reflecting the normal usage of the word in English:
Agile: having a quick resourceful and adaptable character
Merriam-Webster
There’s no doubt that business agility has become a very important topic. Organisations are achieving high levels of growth coupled with the high levels of market change and opportunity, especially in technology fields. It is accepted that a level of “agility” is important for any business (although there may be less agreement how that is implemented).
Data from Google Books below shows how the term “agile” became increasingly used in literature from around 2000 and this trend can be seen to correlate with other terms related to rapid business change. As comparisons in the charts below I’ve included “Start-up” and “VUCA” (an abbreviation for “volatility, uncertainty, complexity, and ambiguity“) as similar language in this area.
However, when we are talking about “Agile” in a development context we mean something more specific than business agility. In particular we are referring to the ideas which are represented in the “Manifesto for Agile Software Development”.
This was a document created in 2001 to encapsulate some ideas around good practices in software development. It was based on observed good practices at the time by individuals who had been experimenting in different approaches. The document is often abbreviated to “Agile Manifesto”, partly to reflect the fact that the ideas are now used more widely than “Software Development”, and also that “Software Development” itself is a much broader and more diverse field than it was in 2001.
The “Agile Manifesto” is the defining document for “Agile”. “Agile Software Development” means a style of development which aligns with the ideas of the “Agile Manifesto”. This is often abbreviated to “Agile Development” or for simplicity “Agile”. For the rest of the article (as in my other writing) I’ll use capitalised Agile to represent this (noting that this is shorthand and grammatically incorrect).
I won’t go through the Manifesto here – look at the links below for more details. It’s very short. Sixty eight words in the Manifesto, backed up with another 189 words in the “Principles” which support it. Overall that’s a bit smaller than the US national anthem, with the Manifesto being the first verse.
Agile approaches
In the years building up to the Manifesto and the subsequent years since 2001, there have been a number of “Agile approaches” developed. The relationship between these approaches and Agile can again be unclear and confusing. There is often confusion between Agile and the most widely used approach, Scrum. Many people believe these to be the same. And yet the Scrum Guide, which defines Scrum, does not even mention the word “agile” or “agility”. How are people expected to navigate this?
The whole Agile domain suffers from this lack of standard language and there is no agreed naming for what I refer to as “Agile approaches”. Looking at some popular approaches:
- Extreme Programming refers to itself as an “Agile Process”.
- Scrum calls itself a “lightweight framework”.
- SAFe says it is a “system for business agility”.
In general, these form a set of techniques, principles and processes which are compliant with and intended to align with the Agile Manifesto. In other words, if you follow these approaches you could be being Agile.
However, there is one really important caveat. There is no certification of how well any specific approach aligns with the Agile Manifesto. And there is no-one to say whether you, in trying to follow one of these approaches, are “being Agile”. There is no central body which owns Agile and never has been.
There was a suggestion that the manifesto authors should begin some on-going agile movement, but the authors agreed that they were just the people who happened to turn up for that workshop and produced that manifesto. There was no way that that group could claim leadership of the whole agile community
Martin Fowler 2005
This causes much of the confusion. With no central ownership of Agile, the term can be used however people choose. Initially this wasn’t a major problem. The Agile Manifesto explicitly promotes experimentation and the expectation that there will be many ways of reaching a successful outcome. So different approaches were different paths to the same general objectives in the Manifesto.
We are uncovering better ways of developing software by doing it and helping others do it.
Manifesto for Agile Software Development
However, the situation has become much more confused in recent years, especially because of the growth of a certification market. Currently around a million people globally have a Certified Scrum Master (CSM) credential, probably the most popular of the many certifications in Agile approaches. Courses seem to cost around £800 ($1000) in the UK. That’s a big industry representing hundreds of millions of dollars.
The result is that every qualification is endeavouring to sell itself as the best representation of Agile. Scrum alone has at least “Certified” training through Scrum Alliance, “Professional” through scrum.org, “Registered” through Scrum Inc, “Practitioner” through PMI and “SAFe” through Scaled Agile, often at multiple levels of qualification.
A typical certification “sell” is below.
The PMI-ACP certification highlights your agile expertise with the industry’s only agnostic, experienced-based, ISO-accredited exam. It validates your ability to drive excellence across methodologies, including Scrum, Lean, Kanban, and more
Agile in three dimensions
As we have seen, Agile seems to mean many things to different people. That complexity comes from the broad range of topics that it is covering, even in the small space of the Manifesto.
In some aspects it focusses on the craft of software development, and the skills and techniques needed.
Continuous attention to technical excellence
In other areas it seems to be talking about the customer and the business, and not about the software.
Our highest priority is to satisfy the customer
And yet again, it is sometimes talking not about technology or business, but about people and how we lead them.
Build projects around motivated individuals
The reality that is often missed is that in the short space of the Agile Manifesto and the associated Principles, there are a blend of different distinct topics. This is the source of much of the confusion around Agile. Software developers often focus on the technical craft aspects of
Understanding Agile requires us to consider these three dimensions separately.
Let’s look at these three dimensions and how they interrelate.
Dimension 1 – Flow
The “flow” dimension covers how we develop in the most effective way. This is the “technical” part of software development and aligns closely with Lean principles.
At one end of the axis here we have developing in large batches with formal handovers between groups from requirements gathering to design, development then coding and deployment. This tends to develop significant amounts of functionality at a time, and work in a sequential way.
At the Agile end we have continuous flow, drawing on the ideas from Lean. This minimises waste through reducing the number of handovers and reducing the batch size. The end goal is to continuously and sustainably deliver high quality work with high levels of efficiency.
In the Agile Manifesto this is best represented by the value below:
- (we value) Working software over comprehensive documentation
And by the following supporting Principles:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
Simplicity–the art of maximizing the amount of work not done–is essential.
Continuous attention to technical excellence and good design enhances agility.
Dimension 2 – Feedback
This second dimension focusses on how we use feedback from customers to produce the most value from our work. Where the first dimension was about efficiency of creation of output, this is about targeting this to create the most value.
At one end of the axis we have a predictive approach. Here we create a plan for what we intend to do, typically by breaking down the problem into component parts. We then aim to execute the plan and deliver what had originally been intended. Success is measure by compliance to the plan, and variance from the plan is minimised.
At the Agile end we instead focus on the value being delivered to customers. We use a way of working which maximises value, typically by having a dynamic backlog and a shorter, iterative, planning approach. This gives us the freedom to adjust the work being done to maximise the value being delivered.
In the Agile Manifesto it is represented by the two values below:
- (we value) Responding to change over following a plan
- (we value) Customer collaboration over contract negotiation
And by the following supporting Principles:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Business people and developers must work together daily throughout the project.
Dimension 3 – Decentralisation
The final dimension looks at how we organise the people involved in the work.
At one end of the axis we have a centralised approach. Authority is held by a management hierarchy which makes the decisions about the work. All decision making is escalated through the hierarchy. Management is generally directive, following the Scientific Management principle of separating planning work from doing work.
By contrast, at the Agile end we build self-managing teams and aim to make decisions at the lowest viable level. Decision making is faster and uses better data as a result. Teams own not only how they do their work but their development and improvement in an approach known as “self-transcendence”
In the Agile Manifesto it is represented by the value below:
And by the following supporting Principles:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The best architectures, requirements, and designs emerge from self-organizing teams.
Good Practices
Agile makes sense only if viewed through multiple lenses and separated into different component parts. A successful implementation of Agile needs to consider all of these, as they will interrelate to lead to success.
As an Agile leader you will need to consider the Flow dimension – how your teams perform work and how to reduce waste and make this as efficient as possible. You will also need to consider the Feedback dimension – focussing on customer value and maintaining the flexibility to pivot to new directions. And finally you will need to consider Decentralisation – how the teams organise themselves and how you as a leader can support and coach them in making decisions and delivering what is needed.
Agile can be hard to understand because it is viewed as a single axis, typically from predictive to adaptive ways of working. But success in Agile requires you to consider how your organisation approaches all three aspects and how these work together.
Leave a Reply