What Is Agile Anyway? The Agile Manifesto (1). Values

“We must be Agile!” From C-level to any level employee, Agile is becoming more and more popular. But what do they mean by being Agile? This is what I got from asking the people around me:

we have to move fast
I want to see the work before it’s completed
I need the team to adapt fast to me changing my mind (customer)
we need to operate as a startup
we have to get rid of processes
we don’t need documentation
we don’t offer career paths and guidance to our employees.

For them, “being agile” means moving fast, little or no process, little or no documentation, little or no team structure, little or no team coaching, guidance or control.

So, what is Agile?

The brief definition of the adjective “agile” is: “able to move quickly, and easily“. The term was coined as a characteristic of software development in 2001.

In the cold winter of 2001, 17 seasoned software engineers – true legends to this day – met in a mountain resort in Utah, Snowbird, and defined a new way of building software, which they called “Agile”. If you’re curious to know who the magnificent 17 are, read on.

During that meeting, they created The Agile Manifesto, which states the Agile Values and accompanying twelve Principles for developing software.

I will cover here only the Values, the Principles deserve a post of their own.

If we’re to create a definition for the Agile way of developing software, it would be this: “building software in a manner that respects the values and principles of the Agile Manifesto“.

The Agile Manifesto: Agile Values

At first sight, the Agile Manifesto is as simple as it can get, but this simplicity hides deep thinking and complexity.

First off, I’d like to emphasise the idea that …

“We are uncovering better ways of developing software by doing it and helping others do it.“

… the Manifesto is not the end of the line, in a true agile spirit, it is work in progress. There is no perfect model for building software so we are continuously working to uncover better ways for doing it.

Creating software is a craft, and the way to mastery is a long and complex journey. There are always better ways to do the craft, and our prime objective is to continuously look for improving how we build software. I consider that continuous learning and continuous improvement are at the heart of Agile (and the most underestimated practice in most organisations).

Let’s dive into each value individually:

“Individuals and interactions over processes and tools“.

In most organisations, there is an intense focus on processes, tools, structure, governance, etc. A lot of the time the process is in the way of creating the right environment for the team to create excellent products. What the Manifesto suggests is to review your processes through different lenses: is this really helping the teams deliver excellent products? Better yet, ask the team to solve the problem and work with them to continuously improve on the solution.

“Working software over comprehensive documentation“.

Agile software development implies short iterations (currently the industry norm is of about 2 weeks), and constant feedback from the client. The product idea you start with will constantly change based on customer feedback, and you might end up with an entirely different product altogether after a reasonable amount of time. In this context, full documentation upfront, when you start working on your product, is obsolete after a while and it creates waste.

Working software delivered to the customer is more valuable than any detailed documentation of the product. One could argue that if your system needs documentation for the users to figure out how to use, the problem is with the system itself, not the lack of documentation.

I also noticed that the teams work quite well with minimum documentation: roadmaps, user flows, user stories (or feature description), that are needed to build each iteration. If you want to track the changes in your specs, make it in whatever platform the teams use to track their work (e.g. our teams document their features in the user stories on Trello, or Pivotal Tracker as they work on them).

“Customer collaboration over contract negotiation”.

This statement is self-explanatory: instead of negotiating rigid contracts with the clients upfront, work together to create the highest value for them.

When we implemented Zuora for our check-out / payment a couple of years ago, we were introduce to “agile contracting”. The contract was negotiated and concluded almost a year after we were using the platform. During this time the Zuora team worked directly with our devs for implementation, database transfer, customisation, etc. We ended up with a superbly customised product that covered the complexity of our business model, and a fair contract that made both parts happy.

This is one example of customer collaboration before contract negotiation. By the end of the implementation, we ended up with a product model that was entirely different from the original assumption. If the contract was rigidly negotiated at the beginning of the project, I doubt that we would’ve gotten a fair deal and all the “change requests” (anything different from the original system that is initially negotiated) were very costly.

A project I worked on as a Project Manager started with an original estimate of 90.000 Euros, and it ended up with a total of 300.000 Euros by the end of implementation (two years after). That is a 3x difference, and the project was not completed entirely (there were still small changes, updates, maintenance needed to be performed by the vendor).

“Responding to change over following a plan“.

This is the main reason that Agile exists. Plans are flawed in a rapidly advancing technological world.

You start a product with an idea and a high degree of uncertainty. No plan, research, benchmark, study will change this uncertainty. The only way to reduce the uncertainty is to actually release work to the user and get direct feedback. Based on their feedback, you review your product and adapt to the new reality. Constantly adapting your product based on customer feedback is essential for creating the right product that customers really need.

So not only does your plan need to be adjustable based on real user feedback, but your entire product needs to adapt to changes rapidly. This is why short iterations, high-level plans (roadmaps), and having enough information to build a first iteration are enough to start building the product. The uncertainty will decreases as you move on from iteration to iteration, collecting feedback as you go.

The most overseen part of the Manifesto, the final paragraph is essential to understand the intention of its creators…

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

… which means that you can’t use the Manifesto as an excuse for (1) no documentation, (2) no use of processes, (3) faulty contracts or (4) absolutely no planning.

The Manifesto puts more emphasis and value on the items on the left, but the items on the right are not excluded, your focus should be to deliver the highest value to the customers, so you need to adapt based on their needs.

Who are the 17 signatories of the Agile Manifesto?

Kent Beck: software engineer with over 30 years of experience, creator of Extreme Programming and 10 books under his belt.
Mike Beedle: physicist turned software engineer, expert in Scrum, Enterprise Scrum and Business Agility, author of three books. Unfortunately he passed away earlier this year. He is the one that came up with the word “Agile” to define the new way of doing software development in that famous meeting in 2001.
Alistair Cockburn: computer scientist, creator of Crystal software development, and author of numerous books on software development, engineering, agile software development etc.
Ward Cunningham: the programmer who developed the first wiki (yes, he’s been writing code for THAT long), author of several related books, co-creator of Extreme Programming.
Martin Fowler: British software developer, author of several books (patterns, UML, refactoring, Extreme Programming).
James Grenning: seasoned extreme programming coach and trainer, coaching his first XP team in 1999, author (TDD).
Jim Highsmith: 30+ years of software engineering (started his work on the Apollo space program), received the International Stevens Award for outstanding contributions to the literature or practice of methods for software and systems development, renowned author on software development practices.
Andy Hunt: also known as Pragmatic Andy, software developer, co-author of the famous The Pragmatic Programmer and 10+ other books on software development.
Ron Jeffries: software engineer, one of the three creators of Extreme Programming (with Kent Beck and Ward Cunningham), with a few books under his belt, and a really awesome blog.
Jon Kern: software architect, technical and agile coach, expert in anything agile, BDD/TDD, CI/CD, development secrets and a passionate climber.
Brian Marick: programmer, tester with 26+ years of experience, specialised in testing, Ruby, agile software development.
Robert C. Martin: the famous Uncle Bob, software engineer with 30+ years of experience, author of 10+ books on programming practices, clean code, agile software development, etc.
Steve Mellor: software engineer, with 40+ years of expertise in executable methods for real-time and embedded systems, author of of structured, object-oriented and agile approaches to software development, and accompanying books.
Ken Schwaber: software engineer, product manager, creator of the famous agile framework Scrum, founder of Scrum.org, co-author of the Scrum Guide and quite a few books on Scrum and Agile software development.
Jeff Sutherland: software engineer, product manager, creator of the famous agile framework Scrum, founder of Scrum.inc, co-author of the Scrum Guide and quite a few books on Scrum and Agile software development.
Dave Thomas: also known as Pragmatic Dave co-author of the famous The Pragmatic Programmer and other books on software development (especially Ruby, unit testing, Rails, Elixir etc.).
Arie van Bennekum: thought leader and agile coach, expert in Agile Project Management, agile core, team facilitation and user involvement.