Agile ? Bien sûr ! Euh... c'est à dire ?

Le manifeste

The Agile manifesto has been around for more than 20 years and is still one of the most discussed topics in the software industry. There is a consensus that Agile can be good, and at the same time the number of people complaining about Agile seems to be always growing. The topic can be very polarized, with some people praising its merits and others blaming it for all the issues in the industry. So, what is really the definition of Agile?

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The difficulty is not the definition itself; it is the fact that it defines values, or a mindset, and not actions. For example, most people will agree that working software has more value than comprehensive documentation. But does it mean that we can forget all documentation? Of course, no. So, when are we choosing not to document? Who decides? Based on what evaluation? Well, it depends. As always. The takeout is only that we should ask ourselves before documenting anything: is this documentation going to bring value? The answer will change from project to project, and being Agile does not give the answer, it just reminds us that we must answer.

The same is true for all 4 values. Nobody ever said that we should give up documentation, tools, contracts, and planning. The purpose of the manifesto has never been to forget values. The manifesto only reminds us of all the values that matter, so that we can make a conscious choice and always spend our resources toward our real goals. The consciousness of the choice matters more than the choice itself; it is not a cult.

Scrum is not Agile

Scrum has become the most used framework for Agile development, to the point that it is almost always associated with it. If a company has Sprints, has a Product Owner, makes regular demos, then is it Agile just because it follows some Scrum methods? Well, it depends. Scrum is a framework; it enables but does not guarantee.

We can work remotely or on site, we can have big teams or small teams, we can prefer contractors or employees, we can meet daily or not, we can make many choices… None of them will tell if we value working software over comprehensive documentation. None of them are naturally Agile or not. At best they might enable, make it easier, to apply some Agile values.

Scrum is a framework, a way to organize how the work can be done, how teams should work together, in way that makes being Agile possible. Scrum is not a guarantee that we become Agile. Scrum does not in itself value working software over documentation, it only gives the tools to organize the work. We still must make choices. We still are responsible for being Agile.

If a company defines some kind of time boxing for tasks and call it Sprint, or if they rephrase all their tasks to be “As a … I want … so that …”, or if they allow the Business Analysts to come and add features anytime in some list; is this Agile? It could very well be a false advertisement, we know we should be Agile, but we don’t want to do it, so we use some buzzwords to get away with it.

On the other hand, some companies apply the Scrum framework to the letter, even have Scrum Masters and Scrum Coaches to ensure the framework is religiously enforced. Then, if we follow every little step of the framework, then we must be Agile, right? As always, it depends. Focus too much on the how, and we will forget the why.

And the why is, obviously, because we want to make a better product!

Better Product? Yes of course! Wait… What does it mean?

First, I would like to try and have a definition of what a product is, and what better means. I believe there is always a perspective where a product can be seen as anything built by a company to bring value to a customer. The company paid to build the product, and they expect the customer to pay them, hopefully more.

I would like to note here that customer and user are not always the same.

• B2B: For example, call center agents (users) can use some call center software (product), but they are not the customers. The call center owners are, and in this definition, they use the product by giving it to their employees, to improve their service.
• B2C with free product? No, B2B: If you consider Google Maps, giving free access to their platform to us: we are not customers, we are users, and us using the platform allows Google to sell advertisement to their real customers. From this point of view, there is still a product and customers, users are just part of the product.
• Internal: The customer can also be the company itself. For example, if the IT department builds an invoice software for the Finance department, there will be a cost in the IT department, and the “payment” will be the cost avoided in the Finance department thanks to the automated invoice software.

This definition of a product is extremely simplistic, but it is enough to define what is a better product. A better product is a product that provides more value to the customer in a way that increases the payment we can get.

So, what is Agile?

The short answer is that Agile is a mindset helpful to make better products, under some conditions.

Some products are clearly defined from the beginning. Sometimes it is even a requirement to define everything before we start building. For example, we cannot lay one brick of a house before we get the whole plan approved by the authority. In most highly regulated industries, the same principles apply. In these cases, being agile is not really required, it might even be forbidden, and we can use other frameworks, such as waterfall if we can make all decisions to improve the value of the product before building it.

In the software industry, it does happen quite often that the product is not clearly defined at the beginning. In place of a defined product, there is often some kind of vision, or some need that must be addressed. We know why we want the product, but we don’t know what exactly, and even less how to build it. The is where having an Agile mindset will help build a better product.

Having an Agile mindset is:

• Acknowledging that you might need to explore opportunities before you find the one that will bring the most value
• Recognizing that you might not know everything you need at the beginning, so you need to design while you build
• Relying on Continuous Discovery (as in “Continuous Discovery Habits” by Teresa Torres)
• Reminding ourselves at every step that our goal is to bring value to the customer, and this value, from the customer’s point of view, will always be the only measure of success

It seems obvious that to achieve the best possible product, we must find a way to discover what we need to build and assess if we built something useful. It seems obvious that we need to collaborate with the customer if we want to address their needs. It seems obvious that we must respond to change if we cannot plan everything from the beginning. Most Agile values and principles are common sense, and yet they are very hard to apply.

Being Agile is reminding ourselves of the why at every step. Because keeping the big picture in mind is hard, using common sense is hard, being consistent is hard. Being Agile is hard. Following a guide is easier. So, we follow what we believe is the cookbook for being Agile: Scrum. As you can guess now, I believe this can be dangerous, because Scrum is only a tool. The first Agile principle teaches us to value individuals and interactions over processes and tools. I suggest we start doing just that.