42% des projets Agile sont couronnés de succès contre seulement 13% pour l’approche traditionnelle Waterfall. Ces données proviennent du CHAOS Report de 2020, réalisé à partir de 50 000 projets. Agile. Serait-ce un mot magique ? Faire des sprints et des daily planning, est-ce cela la clé de la réussite ? Une startup qui livre 10 fois par jour en production, est-elle Agile ? Des équipes qui font des PI planning de deux jours pour prévoir trois mois de travail, est-ce être agile ? Récemment, je me suis demandé, mais en fait qu’est-ce que l’agilité ? Aurais-je travaillé dans des équipes dites “Agile” pendant plusieurs années sans comprendre le concept ? Oui…
Perdu dans cette cacophonie, j’ai décidé de retourner aux sources pour tenter de comprendre l’intention première de l’agilité. Voici un résumé de ce que j’ai appris.
Les comparaisons faites par la suite proviennent pour l’essentiel des références citées en fin de page. Merci beaucoup à Erwan BOURGEOIS (Coach Agile) pour son aide apportée dans la rédaction de ce post !
Un peu d’histoire
Historiquement, les ingénieurs réalisent des ouvrages bien physiques : des ponts, des routes, des tunnels, des machines… La fabrication de ces ouvrages nécessite plusieurs phases de développement, dont la conception et la réalisation. Pendant plusieurs mois, des personnes travaillent à l’élaboration d’un cahier des charges. Ils définissent des besoins, des contraintes, des parties prenantes, des budgets et élaborent un plan de réalisation. Il y a peu de place à l’erreur alors les ingénieurs tentent de tout anticiper, de tout prédire. Dans ces projets, le besoin est généralement clairement exprimé par les clients.
Dans les années 1970, une nouvelle catégorie d’ouvrage a émergé : le logiciel. Les équipes d’ingénieurs ont transposé le savoir-faire organisationnel des projets traditionnels dans le développement logiciel. On design un logiciel, on le réalise et on le livre aux clients sur des disquettes. Pas de place à l’erreur, pas d’internet pour mettre à jour les logiciels à distance. Et puis au fil du temps, les logiciels se sont complexifiés, internet est apparu et le nombre de clients a augmenté. La demande de logiciel des entreprises a explosé, augmentant ainsi drastiquement le nombre de logiciels développés chaque année.
The Standish Group CHAOS Report
Au milieu des années 1990, un cabinet nommé Standish Group a décidé de mener une étude sur le développement logiciel aux États Unis. Ils ont interrogé 365 managers IT d’entreprises de tailles diverses. L’échantillon était de 8300 projets. Résultat : 16.2% des projets de logiciels étaient complétés dans les temps et avec le budget imparti ! 52,7% étaient hors budget ou hors temps ou livrés avec un scope réduit. Enfin, 31,1% des projets étaient tout simplement abandonnés.
Les équipes de Standish Group estimaient qu’en 1995 les entreprises et agences gouvernementales américaines avaient dépensé 81 milliards de dollars dans des projets annulés.
Le rapport de l’étude fournit des détails sur les résultats, notamment les causes de ces échecs. La conclusion est intéressante :
Application software projects are truly in troubled waters. […] Research at The Standish Group also indicates that smaller time frames, with delivery of software components early and often will increase the success rate. Shorter time frames result in an iterative process of design, prototype, develop, test and deploy small elements. This process is known as “growing” software, […]. Growing software engages the user earlier, each component has an owner or a small set of owners, and expectations are realistically set.
À cette période, plusieurs groupes d’experts comprennent que réaliser un logiciel comme on réalise un pont, ça ne fonctionne pas. Ces ingénieurs inventent donc de nouvelles méthodes (lightweights), plus adaptées et orientées “Growing software” : SCRUM, Extreme Programming, Crystal… La conclusion de ces experts ? Le développement logiciel n’est pas prédictible.
Ils constatent entre autres :
-
que coder un logiciel, ça coûte moins cher que construire un pont. Donc la phase de conception d’un logiciel est moins rentable. Là où un pont nécessite 15% du budget pour la conception, pour un logiciel cela va peut-être dépasser les 50%.
-
que le succès d’un projet dépend énormément des personnes qui composent les équipes de développement, de leurs relations et de leur créativité.
-
qu’il est difficile de prévoir toute une phase de développement d’un logiciel en amont. Les besoins changent souvent. Les technologies évoluent rapidement et certains besoins n’apparaissent qu’une fois le produit entre les mains des clients. De plus, si tout a été planifié sur de longues périodes de temps, les modifications coûtent très cher.
-
Enfin, que séparer les acteurs (marketing, analystes, concepteurs, développeurs et autres), génère un silotage des informations. Donc des barrières de communications. Ce qui n’est pas bénéfique pour le produit et donc les utilisateurs finaux.
Agile Manifesto
En 2001, 17 de ces experts se réunissent dans un chalet au ski pour tenter de trouver une base commune abstraite à leurs différentes méthodes. Après deux jours de travail, le manifeste agile est esquissé, il est composé de quatre valeurs. Dans les mois qui suivirent, douze principes furent ajoutés par les membres du groupe.
Ces deux phrases de Martin Fowler résument très bien les fondations de l’Agile à mon sens :
Agile methods are adaptive rather than predictive. Agile methods are people-oriented rather than process-oriented.
Martin Fowler
Prédire, c’est “Annoncer qu’une chose future adviendra”, ce n’est pas annoncer une chose future qui va advenir. Si la prédiction est mauvaise, le plan tombe à l’eau : “in troubled waters”. Adapter, c’est “ajuster une chose à une autre”, c’est ajuster son projet, son organisation, son code, aux aléas de l’environnement.
Sofware is a compound word. The word “ware” means “product”. The word “soft” means easy to change. Therefore, software is a product that is easy to change. Software was invented because we wanted a way to quickly and easily change the behavior of our machines.
CleanAgile - Uncle Bob Martin.
Le développement logiciel Agile, c’est être adaptatif et non prédictif. On ne peut pas prévoir (cf. CHAOS Report), alors essayons de réagir au mieux aux événements. Comment faire ?
En valorisant le changement et en minimisant les process coûteux.
En écoutant les retours des utilisateurs.
En éprouvant le plus souvent possible les applications. Cela au travers de nombreuses releases incrémentales fréquentes.
En construisant des équipes de personnes autonomes et capables de s’auto-organiser pour s’adapter rapidement.
En somme, tout ce qui permet d’être adaptive rather than predictive, people-oriented rather than process-oriented.
Tout ceci n’est pas possible sans un certain niveau d’excellence technique. C’est pourquoi en tant que développeurs, nous sommes les principaux acteurs de l’agilité. Nos solutions techniques permettent d’envisager l’agilité. Et c’est par nos actions et notre manière de développer que l’on peut l’implémenter.