Agile methods: the real and the fake

This definition of agile is open to many interpretations. What are the most common misconceptions? What exactly should we understand? How can we apply agility in the field?

Agile method: 3 common misconceptions

1. Agile is not suitable for large projects: False. The more complex or long a project, the higher the risk of new requirements. Agility was created to adapt to all the changes that can impact the project.
2. Agility is the outcome of reflections that began in the 1980s around IT project management. This effort has produced a body of values and principles to help us optimise project management in all areas.
3. Agility does not use documentation: False. Agility requires formalising processes for the smooth continuity of a project even if we can consider that agility will prioritise the search for results.

   To better understand the “Agile” vision, let’s look at the meaning of the beliefs:

Agile: “People and their interactions more than processes and tools

Employees are often confronted with message formatting that makes exchanges unwieldy. The Agile approach makes communication within teams more fluid by encouraging face-to-face interaction and thus enabling better dissemination of key messages.

Agile: “Operational software rather than exhaustive documentation”

The Agile approach focuses on value production. Documentation is generally a time-consuming task that mobilises the development team to the detriment of progress on deliverables. It should be noted here that an Agile approach does not exclude documentation, as it remains necessary for the continuity and maintainability of the project, but does not appear as a priority.

Agile: “Collaboration with clients more than contractual negotiation”

In a traditional approach, the project operates according to the rules agreed at the start between the client and the team in charge of the service. This approach reaches its limits when there are major unforeseen events. In this case, the terms of the project must be renegotiated in order to redirect the project towards new goals. The “Agile” approach advocates a dynamic operation capable of absorbing changing needs by prioritising continuous collaboration with the client, involvement in all phases of the project, and a search for a common solution.

Agile: “Adapting to change rather than following a plan”

Finally, this last belief invites us to set up a flexible operation capable of absorbing changes and redefining goals and priorities. With this operating mode, deliverables can be reoriented to suit their ever-changing contexts, giving customers an edge over their competitors.

These values are the pillars of agility, but perhaps most importantly, the manifesto concludes: “We recognise the value of the latter, but value the former.” This means that the “agile methodology” does not impose strict rules but rather the choice of defining priorities according to goals. This in turn brings us to the definition of the word “agile”, which is to embrace the movements of a changing environment.

How can you apply an “Agile” approach to a project or an organisation? There are several recognised methodologies for doing so. One of the most widespread is the “Scrum” approach, which is based on several principles that mesh perfectly with agility, namely:

• Productivity, or how to use resources more efficiently, doing more with less
• Adaptability, which prioritises the continuous detection of obstacles to correct a project’s trajectory
• Transparency, which ensures the same level of information for all stakeholders so that everyone has a clear and precise idea of the issues

The “Scrum” approach also introduces new functions such as the “Product Owner”, who is in charge of the product, or the “Scrum Master”, who coordinates the teams and guarantees the method.

All these actors respect “ceremonies” at the beginning and end of each iteration and communicate regularly to detect possible obstacles and adapt accordingly.