The most logical spot to look for the purpose of Agile is at the Agile Manifesto website:
“We are uncovering better ways of developing software by doing it and helping others do it.” — Manifesto for Agile Software Development, 2001
This is an all too familiar sentence for most of you. Here, the creators of the ‘Agile Manifesto’ brought forward what they aimed to achieve.
What is missing is WHY they were uncovering better ways. For that, you need to look at other places of the Agile Manifesto.
The 12 principles behind the Agile Manifesto help out a bit:
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. — 1st principle”;
- “… Agile processes harness change for the customer’s competitive advantage. — 2nd principle
From this, we can distil that ‘Agile’ exists to help out customers by delivering valuable software early and continuously and be responsive to changes.
Going beyond the principles, I stumbled upon the following:
“At the core, I believe Agile Methodologists are really about “mushy” stuff — about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset”.” — About the Manifesto by Jim Highsmith
So ‘Agile’ is about treating the customers and developers better. It exists to respect them instead of ignoring them or squeezing them like a lemon.
These are great things to strive for. But it still does not answer the fundamental question of why this is necessary. It also fails to explain how it stands out compared to traditional approaches.
The arguments from the Agile Manifesto website will hardly convince a manager of C-level to embrace Agile. Treating your people as your most important asset is not exclusive to Agile. The ability to respond to changes does not resonate when people wish to avoid changes in the first place.
The Manifesto for Agile Software Development reads like a response to methods and approaches that don’t work. It doesn’t clearly state why and when the values and principles of Agile are more effective.
But even when people are convinced by the values and principles from the Manifesto, they may be for the wrong reasons.
Agile is open for many interpretations and totally different approaches. Partly intentionally so. Every environment is unique and there are many ways to get to an Agile approach. But the lack of a clear reason why it exists turned against Agile.
All kinds of frameworks and methodologies call themselves ‘Agile’. As long as you can tick off the boxes of 4 values and 12 principles, you can claim you are too.
Not all approaches are actually ‘Agile’ though. Frameworks exist that qualify according to the principles. But a large group of the creators of the ‘Agile Manifesto’ despise them as they don’t tackle the issues that Agile wants to solve. Then we have the Agile consultants of which some are detached from the origins and the ideas of ‘Agile’. They are only in it for the money and don’t care about agility at all.
But there’s more.
I have discussed the wildfire of practices, coaches and consultants. On top of that, many practitioners have come to misunderstand what Agile is all about. The same is true for the most popular Agile framework, Scrum. Here are a few delusional ideas:
- Agile is about delivering things faster.
- Agile comes with out-of-the-box approaches that you can apply everywhere in the same way.
- You don’t need to change your organisation to work “Agile”.
- Velocity is a great indicator to measure the productivity of a team. Some even use it to determine the apparent value delivered by a team.
- Every team can work in the same rhythm, like 2-week Sprints.
- When you work Agile you need to use tools like Jira.
These misunderstandings show a misguided idea of what Agile and Scrum are all about. But still many believe they are real. This has lead to a wildfire of approaches labelled ‘Agile’. Much to the dismay of people who are serious about Agile. Some of them have responded with efforts to return to the core.
Alistair Cockburn is one of them. He was one of the creators of the Manifesto for Agile Software Development. Recently, he brought us back to the Heart of Agile:
“Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the heart of agile.” — Alistair Cockburn
Heart of Agile is about “Collaborate — Deliver — Reflect — Improve”:
Then some bright minds came with new approaches to build products. Like Joshua Kerievsky, who has attempted to Modernise Agile:
“We learn rapidly by experimenting frequently. We make our experiments “safe to fail” so we are not afraid to conduct more experiments. When we get stuck or aren’t learning enough, we take it as a sign that we need to learn more by running more experiments.” — Modern Agile — Experiment & Learn Rapidly
Modern Agile has four principles:
- Make People Awesome.
- Make Safety a Prerequisite.
- Experiment & Learn Rapidly.
- Deliver Value Continuously.
One of the most successful approaches lately comes from Eric Ries. He created a Lean Startup:
“Should this product be built?” and “Can we build a sustainable business around this set of products and services?” To answer those questions, we need a method for systematically breaking down a business plan into its component parts and testing each part empirically.” — Eric Ries from Lean Startup
Lean Startup has “Build — Measure — Learn”.
The three remove a lot of the noise of the original Manifesto:
- Heart of Agile emphasises teamwork, the need to deliver a product increment, the necessity to inspect the impact of the changes and adjusting course if this is sensible.
- Modern Agile underlines sustainability due to safety, the regular delivery of value and learning from the feedback on your product.
- Lean Startup is all about delivering something fast to learn quickly and adapt.
Considering these different approaches together brings us closer to the core of Agile. But still, it does not answer the question WHY.
The Agile Manifesto doesn’t give us the answer to why it exists and new approaches also don’t. Where then can I find the reason to work Agile in the first place?
Well, actually, there’s the Scrum Guide!
Yes, the Scrum Guide tells us why Scrum (and other Agile approaches) exist:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Scrum always had the missing piece of the puzzle. Ever since its start (1995) the two creators Jeff Sutherland and Ken Schwaber clarified WHY. The great thing is that it also helps to understand why Agile exists. It explains why Agile has its values and principles.
The creators of the Agile Manifesto wanted to move away from traditional project management. Not because these approaches are wrong, but because they don’t work when you develop software. The reason is the unpredictability of software development. Software development is complex.
It immediately explains Agile values and principles, for example:
- It is why business people and developers must work together.
- It clarifies why self-organising teams should work at a sustainable pace to foster creativity.
- It explains why you should take small steps, creating working software frequently.
- It shows why you should show working software to your customers at regular intervals to learn from it and decide what to do next.
For some reason, they failed to mention this explicitly. I say this was a mistake.
20 years after it came to light, many still don’t know why Agile exists at all. So frameworks and methodologies have spawned that may appear Agile on the surface. They are not in reality. Not to mention the flood of misguided Agile consultants spamming the globe.
In the past years, people came with a response to this to bring the focus back to where it should be. Heart of Agile, Modern Agile and Lean Startup are examples of such approaches.
There’s one framework that has weathered all the storms and is stronger than ever: Scrum. Scrum always explained why it existed and why it has its roles, events, artifacts and rules.
You may not want to adopt Scrum to create your products. But at least take note of the ‘why’ of Scrum and how this applies to your situation. It may help you understand why Agile exists. Then you may be on your track to find the best approach for you.