The Agile Manifesto: What agile has brought us

Published in 2001 the agile manifesto is now 20 years old, but it’s still alive. The values and principles of the Manifesto for Agile Software Development make a lot of sense to me, they resonate with me on how I collaborate with people to deliver value.

Over the years I got a lot of inspiration and useful ideas from the authors who wrote the agile manifesto. In this article series on the agile manifesto, I’ll explore what I’ve gained through reading stuff that has been published by the authors, talking with them or interviewing them, or collaborating with them.

In the first article The Agile Manifesto: A new mindset I explained how the agile manifesto gave visibility to a new mindset and explored how the alphabetically first six authors inspired me and what I learned from them. The second article The Agile Manifesto: Why Agile Makes Sense showed that the manifesto wasn’t something “new” thing to me but still made a lot of sense; also the article includes inspiration from six more manifesto authors. This third and final article in the series on the Agile Manifesto explores what agile has brought us. And I’ll share the third block of five manifesto authors, showing how they inspired me and what I have learned from them.

What agile has brought us

Opinions about what agile has brought us vary a lot. Some of it is great, but not all of it is.

Agile makes us focus on people instead of processes. Could this help to create more humane organizations? I know of some organizations who not only say that their employees are important, but also act that way. They fully support self-selection and self-organization. They trust their people, give them space, and allow them to do their work the way they want to do it. Many of them mentioned that taking an agile approach helped them to establish conditions where people can grow.

But, such companies are rare. Most companies that say that they adopted agile still treat their people as resources. They expect them to become self-organized by telling them how to do their work. They fail to establish a culture of psychological safety where people dare to speak up. Putting people in the center is key to increase agility, stop telling people what to do. Cargo-cult agile, which damages people is a bad thing.

The agile manifesto has made us aware of the importance of collaboration and communication. I’ve seen discussions around agile help people think about how they want to work together, how to align and coordinate, how to become more transparent and open. Communication and collaboration are hard, but they are key aspects to deliver something of value to someone. Communication issues need to be dealt with.

At the same time, I see people who blame agile for causing problems. When there’s an issue, they say it’s because they have to be agile. This is nuts! Agile doesn’t cause problems, the problems were there all the time. Agile brings problems to the surface and can foster safe discussions to solve them. Stop blaming agile, start solving your real problems!

I believe the agile manifesto has created a stage for modern (and better) approaches for organizational change. Agile has also helped to bring out many modern leadership approaches. These approaches for change and leadership support self-organization, empowerment, reflection, and continuous improvement, which are key aspects of agile.

Unfortunately, most agile adoptions are still done as agile transformations, using a “classic” change approach that tends to fail utterly. It doesn’t work as such an approach is incongruent with an agile mindset. The best evidence that this doesn’t work is that most of the agile transformations fail. People don’t want to be transformed, imposing agile doesn’t lead to higher agility. In fact, it reduces it.

Everyone agile, agile everywhere is what I have seen happening over the years. Where agile started as something for software developers, agile has made its way beyond software development into other software functions, business agility, agile marketing, agile HR, education, hardware development, and more. Agile as described in the manifesto wasn’t designed for such purposes, but the agile mindset and agile principles do lend themselves for it. But then you need to go back to the manifesto and not just apply an agile framework or method.

I’m wondering, did agile directly or indirectly raise attention for diversity, equity, and inclusion (DEI)? Being focused on people, agile may have made it easier to talk about these topics. I’m seeing an increasing awareness for DEI, but I haven’t seen it linked to the manifesto although it’s clear that DEI supports agility in organizations.

How authors of the agile manifesto inspired me

Over the years I have met and spoken with most of the authors of the agile manifesto. I’ve interacted with them at conferences where we presented and shared our stories or did interviews together. I have been reading their books, articles, blogs, and much more. I’ve had discussions with them on LinkedIn, Twitter, Slack, or email. I also interviewed most of them as an editor for InfoQ as I wanted to share their experience.

Here’s how I got inspired by them: Below find my stories with inspiration from the third block of five authors of the agile manifesto (alphabetically).

Robert Martin

I did an interview with Robert Martin on the oath for programmers that was published on InfoQ.

After multiple toxic tweets and seeing the effects that those tweets were having, I ceased all contact with him.

Steve Mellor

In one of my first jobs, I learned about Structured Development for Real-Time Systems where I applied the Ward-Mellor method that Steve had developed together with Paul Ward. This was in the 1980s is before agile was there. I used state diagrams to better understand the system for which I developed software.

My career in software development has been mostly in real-time and embedded systems development. Steve explored how to apply agile in the embedded world. Real-time software has some specific aspects, and being embedded comes with specific challenges. You need to build your own infrastructure to be able to do frequent releases in an embedded context.

I haven’t had a chance to meet with Steve Mellor yet.

Ken Schwaber

Reading the book Agile Project Management with Scrum by Ken Schwaber gave me insights on how management can complement agile and what can be done to make Scrum work in the organization. The key thing I learned from reading this book is that it’s all about connecting people throughout the organization and establishing a culture of collaboration.

In 2017 I did a Q&A with Ken Schwaber and Jeff Sutherland about Scrum Guide Updates for InfoQ. One of the things that we discussed was how continuous improvement is supported by Scrum using inspect and adapt:

Scrum is inspection and adaption. Every event is inspection and adaption. Sprint planning is inspecting the top of the backlog and making sure it is ready for the Sprint. Daily meeting is inspecting what you’ve been doing yesterday and fixing it today. Sprint review is inspecting the product at the end of the Sprint and changing the backlog based on stakeholder feedback. And so on.

Ken Schwaber on InfoQ

In a recent interview with Ken Schwaber that I did for InfoQ about the changes in the 2020 Scrum Guide, he explained why there’s no more development team in the Scrum guide:

The goal was to eliminate the concept of a separate team, the Development Team, and instead have one team focused on delivering value. The separate Development Team could create ‘us and them’ behavior between the product owner, the Scrum master and developers. By removing the Development Team, we have one Scrum Team focused on the same objective. The three accountabilities describe how they all work together to deliver on that objective.

Ken Schwaber on InfoQ

Being focused on delivering value, this new insight in Scrum surely resonates with me!

Jeff Sutherland

When I was at Goto Amsterdam in 2015 giving my workshop Getting More out of Agile and Lean, I had the chance to meet Jeff Sutherland in person. In the Q&A with Jeff Sutherland on Agile Leadership published on InfoQ I asked him which kinds of problems he sees in larger organizations when they are adopting Scrum:

Their problems are huge but boil down to one problem. The leadership needs to become Agile. They need to support the teams, remove impediments, and coach the organizations to be agile. There are so few managers trained and good as this today that many companies will be driven out of business by their agile competitors.

Jeff Sutherland on InfoQ


After reading the book Scrum: The Art of Doing Twice the Work in Half the Time I did a Q&A with Jeff Sutherland on Scrum for InfoQ where I asked what’s his advice to teams that want to increase happiness:

At Scrum Inc, we use the Happiness Metric to start the Scrum Retrospective for all teams. How do I feel about my job on a scale of 1-5. What will make me feel better. When we have the info from every team member, the team brainstorms what single improvement will increase happiness the most in the next sprint. We then put this as the Kaizen at the top of the Sprint Backlog with acceptance tests for completion in the next sprint. This has caused the team improve output by 400% in the first year and to keep improving for the past three years. Harvard research shows happiness increases production for any type of work.

Jeff Sutherland on InfoQ

In 2019 I did a Q&A on A Scrum Book: The Spirit of the Game with Jeff Sutherland and James Coplien for InfoQ. One of the questions I asked was how the Testable Improvement pattern support measuring improvement in teams:

Today, I train new ScrumMasters in the Toyota Kata, kaizen thinking. Every impediment is an improvement waiting to happen. Every sprint a team needs to prioritize the improvement that will give the most benefit for the least cost. The improvement should be small enough to measure the effect in the next sprint. This is fundamental to Lean and Scrum derives from Lean through the paper, by Takeuchi and Nonaka, who coined the term “Scrum.” The Testable improvement pattern shows a team how this might be implemented.

Jeff Sutherland on InfoQ

Using impediments as a source for improvement works! I’ve seen teams do this and I wrote about it in my book Problem? What Problem? It does take a culture though where failure is allowed instead of being punished.

Jeff is a big supporter of EduScrum, we’re both friends and partners of eduScrum.

Jeff also took part in the interviews about the updates of the Scrum guides mentioned earlier. When I asked Jeff why they changed the Scrum guide from teams being self-organized in the 2017 edition to self-managing in the 2020 edition, this is what he had to say:

When we started working on updating the Scrum Guide, I thought self-organization was the most widely abused term in the industry because every company told me they had developers who were self-organizing to do whatever they wanted, and not helping the team to meet the Sprint Goal. I realized that a typical developer had no training in the Complex Adaptive System Theory, and did not understand the term. We hope that self-managing will help them act more like an intelligent system.

Jeff Sutherland on InfoQ

To help teams and professionals to become truly self-managing, it helps to teach them about the concept of self-managing and, most importantly, to provide them with opportunities to experiment with it. This is something that I do in many of my workshops.

Dave Thomas

In 2014, Dave Thomas published the article Agile is dead where he suggests retiring the word “agile”:

The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

Dave Thomas in Agile is dead

He suggests using the word “agility” as that’s something that describes what we do and how we can be focused on the outcome and the result. This was one of the reasons why a workshop that I do more often these days is called Improving Organizational Agility. It’s not about agile, it’s agility that matters.

Í don’t teach agile, and I do teach with agility. Living the agile principles, no two workshops are the same as every workshop is adapted to the audience and situations at hand to provide something that truly helps people learning how they can increase their agility. As one of my clients said about my workshop:

In 2015 I attended GOTO Amsterdam where I did an interview with Dave Thomas about increasing your agility. I asked him about

I think the original values [of the agile manifesto] are still valid, and we can use them to inform the way we work.

I like to express it like this. Every team that develops with agility follows these steps:

– Know where you are
– Take a small step towards where you want to be
– Evaluate what happened
– Repeat

This sounds easy—it isn’t. It is hard because it applies to everything, at all levels. 

Dave Thomas on InfoQ

This is a great summary of what agility is about. It goes back to the values of the agile manifesto (which I use as a foundation for agility in my talks and workshops) and explains how to apply those in your daily work

Together with Andrew Hunt, Dave Thomas wrote the book The Pragmatic Programmer. It was originally published in 1999, but the version I have read is the 20th-anniversary edition published in 2019. In the podcast  Dave Thomas & Andy Hunt on the 20th Anniversary Edition of The Pragmatic Programmer, they mentioned that being agile is something you live, not something you buy from a consultant. You need to change constantly in order to improve, as explained in the podcast:

The real spirit of agility is about constantly monitoring what you are doing, constantly trying small changes and constantly getting feedback

Dave Thomas & Andy Hunt on InfoQ

This is so true! It’s about constantly being aware of the impact of things that you doing, looking for feedback, or anything that helps you to learn and improve.

Other people who inspired me

The 17 people who crafted the agile manifesto aren’t the only ones who are knowledgeable on agile. Over the years I have learned many things about software development, leadership, teamwork, quality, and coaching, from people like Jerry Weinberg, Linda Rising, Tom Gilb, Capers Jones, Michal Vallo, Watts Humphrey, Diana Larsen, Tim Ottinger, Mary Poppendieck, Jurgen Appelo, and Klaus Leopold, to name some.

I’ve also learned a lot from the conferences that I attended. It sounds like a cliche, but I often pick up stuff from discussions with people during the breaks, open spaces, mini-workshops, and other interactive sessions. These days I dare to skip talks to be available for anything that pops up naturally, where I favor conferences that provide the space at atmosphere for spontaneous things to happen. To the many people that have inspired me with small but important nuggets: Thank you!

Agile has brought us value

As mentioned before, I was agile before the term agile was invented, way before 2001. I adopted the agile manifesto because it makes sense and alignes with what I believe in.

The authors of the agile manifesto have been an inspiration throughout my career in many aspects. Sometimes I wish that I had been there when the manifesto for agile software development was crafted in 2001. But I wasn’t invited. Anyway, I don’t like cold weather, snow and skiing (I’m a scuba diver).

True agility is about practicing, experimenting, and learning by doing. It doesn’t come with a certificate. You can’t learn it in a course or take an on-line training. You have to live it. Becoming truly agile by doing and learning.

I hope that by sharing my inspiration from the agile manifesto and it’s authors in this series of article will inspire you.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.