How I learned to introduce the Agile Manifesto

The Agile Manifesto, considered a holy text for some, is often (if not always) mentioned in Agile training on the market. By dint of exchanging within the community, I realized that we did not have the same way of approaching it, nor of presenting it during our training.

That's why I thought I'd explain how I've learned to do it so far.

A little history

The history of the Agile Manifesto is this link on http://agilemanifesto.org/ that seems few people have had the curiosity to browse, and yet what is told there is fascinating! A French translation is also available through Fabrice Aimetti.

We know that 17 software development experts met from February 11 to 13, 2001 in Snowbird, Utah, and resulted in the development of what is now proudly called the “Agile Manifesto”. But how did they come up with this idea of meeting?

Why they got together

The idea of the meeting was born following a previous meeting organized by Kent Beck between the promoters of eXtreme Programming and some "outsiders" where the participants expressed their support for a set of so-called "light" methods without anything concrete does not really come out of it. The term "light" was used in contrast to "heavy" approaches to documentation-driven software development.

In September 2000, Bob Martin sent an email to propose "a small conference (of two days) (...) here in Chicago" to gather all the leaders of these "light" methods in the same room.

The idea behind the Agile Manifesto

According to Jim Highsmith, fundamentally, Agilists want to deliver great products to their customers by operating in an environment that does more than say "people are their greatest resource" but actually acts as if people are most important, forgetting the term "resource".

So indeed, most of the debates around agility revolve around these topics – considered mushy by some – of values and culture. Thus, even if the Agile Manifesto provides some specific ideas, the important thing is to restore value to the human by placing it at the heart of our strategies (professional and personal) and by rethinking our ways of being and doing in result.

Some anecdotes

• Martin Fowler (an Englishman) raised the issue that most Americans can't pronounce the word "agile".
• Nobody initially thought that this group of organizational anarchists would agree on anything substantial.
• The fiercest debate that erupted was about the choice of location: too cold, too hot, too far, nothing interesting to do...

How I describe the Agile Manifesto

The Agile Manifesto is a text composed of 4 distinct parts:

• 2 introductory sentences
• the 4 Agile values
• 2 closing sentences
• a list of authors

I don't always present these parts in chronological order. Very rarely in fact.

I usually use this order:

The introductory sentences

We learn how to develop software better by doing and helping others do it. These experiences have led us to value:

In general, I invite the participants to identify the elements that seem important to them, the basis on which the exchanges will be based.

• " We discover… "

I had never dwelt on this part before but one day a participant said to me:

"The use of the verb discover in the present can induce the idea that we do not remain on the basis of what has already been found, and that we continue today to discover new things. »

When we say that agility is not an end in itself but rather a journey towards continuous improvement, I find that we find this idea well here. I have often heard that we learn as much or even more than the participants by leading training sessions, here is a blatant example, so I kept it! :-p

• " …softwares… "

Let's not forget that initially, the 17 people who met are representatives of software development methods.

However, I tend to add that the Manifesto would be just as right or even more so by replacing the term " software " by " product » as said Alistair Cockburn in Keynote of ScrumDay 2014 in Paris.

• “…by practice…”

In literal translation from English, “…by doing it…”, I refer here to the empirical characteristic of the Agile approach in opposition to the predictive characteristic of the Traditional approach. Indeed, it is through experience that we learn concretely (and that we continue to learn) with a view to continuous improvement.

• “…by helping others to do so. »

I am talking here about the Agile community, which aims to share good practices and distribute them to as many people as possible. Indeed, everyone is likely to discover something new, to question concepts that may have become obsolete, now the important thing is not to keep it for yourself and the Agile community is a good place to share! 🙂

The closing sentences

We recognize the value of the second elements, but favor the first.

I often describe this part at this time to prepare the ground. Indeed, it helps to explain the structure used by the 4 Agile values comparing elements (literally) on the left and on the right.

I insist then on the fact that this comparison is not a strict opposition. We don't talk about opposition Good bad but rather an opposition Better / Good. Indeed, we recognize the value of the second elements, but we want to tend towards the first as often as possible. In other words, it's a cursor issue.

The 4 Agile values

Individuals and their interactions more than processes and tools

Organizations are made up of individuals who produce value in order to meet business strategy. Most of the time even they do not produce it alone but as a team, which makes the importance of their interactions all the greater.

I tend to inject this adage at this point:

“The whole is greater than the sum of the parts. »

I explain this by saying that indeed, what makes an organization greater than the sum of its individuals is that you add to it the sum of all the interactions that operate within it. It is thus by taking care of these interactions that we will have a better control of the value that we wish to produce.

Now processes and tools are also not to be deleted. I don't know many companies (if at all) that would work without a process or without a tool and there is a reason for that: the world and technology are changing so fast that it is difficult to manage the resulting complexity. However, let's not forget that the tools have no use in themselves, except when they act as support. Thus, the right processes and tools can help individuals better manage their interactions.

Otherwise, individuals are then subject to their tools, which tends to rather reduce their ability to interact with each other. Known chorus? :-p

Operational software more than comprehensive documentation

The first remark I make is of the order of translation. Indeed, the English version speaks of " comprehensive documentation which effectively translates to “exhaustive documentation” in French. Beware of the false friend and therefore of a possible misunderstanding or misinterpretation.

The idea behind this value is that we favor having software that actually works in front of us rather than having documentation explaining very precisely how it should work.

I often draw a parallel with progress indicators, one of the underlying principles of the Agile Manifesto. I tell the story of a project in which I had worked where I had established 2 progress indicators for my hierarchical superiors: a real progress indicator and a theoretical progress indicator. The first corresponded to the progress of the software actually completed (therefore also tested) while the second also took into account the tasks in progress.

In the first case, we have real progress on which we can communicate without surprise, whereas in the second we risk having the effect of the graph which goes quickly from 0 to 50% then slower from 50 to 90% and which has a crazy badly to advance the 10 end %!

Now, that doesn't mean that the documentation is useless and that we remove it entirely, it's just not used in the same way anymore. I will talk about Agile documentation in a future article 😉

Collaboration with customers more than contract negotiation

The main idea that I convey for this value is the change of relationship with customers. In fact, what we are looking for here is to replace the old client-supplier relationship with a real partnership, in a win-win relationship where everyone finds their way.

This approach seems rather logical when you see the precision with which customers express their needs. It's not even necessarily their fault, but even the precise need at a time tends to change over time. This is where customer collaboration comes into play and where the relationship of trust is created. In addition to the expertise part that resides with the supplier partner, what transpires is the desire to provide the best solution at the best time for the customer and thus enable him to nurture his competitive advantage.

Now, all this cannot be done without a contract, it is obviously necessary to define a framework in which the 2 parties can evolve. However, they are no longer the same as before – which only served to protect each other mutually – but on the contrary, they offer new perspectives for collaboration!

Adapting to change more than following a plan

A little quote to start:

“In preparing for battle I have always found that plans are useless, but planning is essential. – General D. Eisenhower

I like this quote because it allows me to continue by saying:

“In Agile, it's not that we don't like to plan, on the contrary, we plan to plan! » 🙂

I then explain that today change is something inevitable, even necessary, which means that we have the choice of the perspective we give to it. In Agile, change is seen as an opportunity: an opportunity for the customer to maintain a competitive advantage, an opportunity for the supplier to provide the best solution at the right time.

I then talk about the turn that projects generally take in the traditional approach by drawing this diagram:

When all is well, all is well. On the other hand, when we start to deviate from the plan, we do everything to get back on the plan. But is this the right solution? The problem that most often arises is that at the end of a project, the need having changed, point B is no longer the right destination!

I then draw this diagram:

We have a hypothesis and a basic plan but sometimes the starting point can evolve, we then replan from this point (A') but less far. Changes happen along the way, and well we take them into account and replan to see where the destination would be most relevant next time. And so on, which allows us to adapt on the way to changing needs, and above all to arrive at the right place at the right time.

So the plan itself is of no use except to give us direction for a while. It is the planning activity that allows us to see where we are, to see where we want to go, to be reactive and to adapt to a constantly changing environment.

I complete the description of the values by taking a step back and explaining that the elements on the right can be considered as tools in support of the elements on the left which represent the objectives that we wish to achieve.

Then I ask the following question:

“In your opinion, if you had to choose only ONE of the values of the Agile Manifesto, which would be the most important to you? »

There is often everything in the answers, which makes the exchanges interesting on the reasons for each person's choice.

Then, I direct the debate by pointing out each value one by one from bottom to top:

• “What do I need to be able to adapt to change? »
• “What do I need to collaborate with customers? »
• “What do I need to get working software? »

If I don't have the rug pulled out from under me by the participants (which often happens at this stage), I end by saying:

• “Well of individuals and their interactions. Remember that it is people who produce value and without them nothing could work. »

Sometimes, I even invite participants to summarize the Agile Manifesto in one word, which gives rise to new exchanges and makes it possible to see everyone's position on the subject.

I then announce the word used by Alistair Cockburn during ScrumDay 2014 in Paris:

PEOPLE

List of authors

I present in this part some of the authors, generally those who could speak the most to the audience or who could be related to topics discussed later such as:

• Jeff Sutherland and ken schwaber: the 2 fathers of Scrum
• Ward Cunningham: the inventor of the Wiki concept
• Martin Fowler: known for design patterns, UML and refactoring
• Kent Beck: the inventor of eXtreme Programming

This is how I have learned to present the Agile Manifesto so far. This is by no means THE way of doing things but MY way of doing things today. Now, I am always open to good ideas to evolve my approach knowing that I will “continue to discover how to do it better, by doing it, and by helping others to do it”. 🙂

And you, how are you doing ? 🙂

Note: I limited the article to the description of the 4 fundamental values without going into the details of the 12 underlying principles.