Introduction
Que pensent les devs de l’agilité ?
De manière générale, les répondant(e)s ont un sentiment de décalage et de défiance envers l’agilité. Seuls 23% des répondants estiment que l’agilité répond à leurs besoins, tandis que plus de la moitié ont l’impression de la subir, et 16% cherchent même à éviter les environnements agiles.
Zombie Scrum is the New Black
Ce malaise est renforcé par la fréquence élevée des anti-patterns Scrum rencontrés. Tout d’abord, aucun des devs interrogés n’a connu de Scrum qui fonctionne parfaitement. En effet, 100% des répondant(e)s ont rencontré au moins 4 anti-pattern Scrum et plus de la moitié en ont rencontré 16 et même une personne en a rencontré 33 sur les 36 anti-patterns présentés.
Un outil pour les devs ?
Nous l’avons vu, l’agilité a été conçue par des développeurs pour des développeurs. Cependant, dans sa mise en œuvre actuelle, elle est souvent perçue comme un ensemble de contraintes managériales ou de pratiques déconnectées des contextes et problématiques des équipes de développement. Sa mise en œuvre défaillante corrèle avec l’impression de subir l’agilité et la pensée que l’agilité n’est plus adaptée aux équipes de développement.
Cela a pour effet de créer un sentiment de défiance envers l’agilité, vécue comme un ensemble de contraintes managériales ou de pratiques déconnectées de leurs contextes et problématiques, alors qu’elle a été conçue pour être un outil à leur service.
Les devs, les oublié(e)s des conférences agiles
L’analyse des descriptions de sessions de conférences agiles mettent en évidence que les devs sont les grands absents des conférences agiles. Le terme “développeur” apparaît dans 4% des sessions, et lorsqu’il est présent, c’est souvent pour évoquer des problématiques de gestion ou de management, rarement pour aborder leurs réalités, leurs pratiques ou leurs problématiques.
Les devs sont davantage vus comme des ressources à “manager” et certain(e)s orateur(rice)s se montrent même parfois condescendants lorsqu’ils évoquent les développeurs.
J’ai également demandé aux équipes d’organisation des conférences agiles de m’indiquer la composition de leur équipe ainsi que les critères de sélection des sessions. Quatorze équipes ont bien voulu répondre à mon questionnaire. Parmi elles, seulement 5 d’entre elles contiennent au moins 1 dev (parfois face à 6 Scrum Master).
L’agilité s’est-elle détournée de son esprit originel ?
Souvenons-nous : le mouvement agile a été initié par 17 développeurs en 20011. Aujourd’hui, sur ces 17 développeurs, 11 sont aujourd’hui plus attachés à la pratique du développement logiciel qu’à l’agilité institutionnalisée. Pour 5 des 6 autres, c’est l’inverse : ils consacrent davantage d’énergie à l’agilité institutionnalisée. Entre les deux, il y a Alistair Cockburn.
Quelques signataires du manifeste pour le développement agile de logiciels ont même publiquement désavoué l’agilité.
Dave Thomas
En 2014, dans son billet intitulé Agile is Dead (Long Live Agility)2, Dave Thomas est le premier des co-signataires a alerter sur une dérive du mouvement agile.
Having conferences about agility is not too far removed from having conferences about ballet dancing.
The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
[The word “agile”] became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.
I’m particularly sensitive to the damage it does to developers. [They] can no longer use [agile] as a guide to what is useful in their practice.
Andrew Hunt
Un an plus tard, Dave Thomas a été suivi par Andrew Hunt qui a écrit dans The Failure of Agile3 :
The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly.
Instead of looking up to the agile principles and the abstract ideas of the agile manifesto, folks get as far as the perceived iron rules of a set of practices, and no further.
Agile methods ask practitioners to think, and frankly, that‘s a hard sell. It is far more comfortable to simply follow what rules are given and claim you’re “doing it by the book.”
Teams find themselves unknowingly stuck in a rut: blindly following the concrete rules, not gaining the experience they need to get to the point where they know they need to move beyond the rules.
Martin Fowler
C’est ensuite au tour de Martin Fowler de s’exprimer sur son blog4 en 2018 :
Our challenge at the moment isn’t making agile a thing that people want to do, it’s dealing with what I call faux-agile: agile that’s just the name, but none of the practices and values in place.
The Agile Industrial Complex imposing methods on people is an absolute travesty (…) because in the end there is no one-size-fits-all in software development.
[There is a] lack of recognition of the importance of technical excellence to what we do. A lot of agile conferences I go to don’t tend to talk very much about the actual techniques of writing software.
[The Agile Alliance] realized that they were getting a lot of people who were involved in the project management side and things of that kind, but not very many people who are the technical people who actually did the work.
Ron Jeffries
Toujours en 2018, Ron Jeffries écrit un billet intitulé *Developers Should Abandon Agile”5 :
“Agile” has become big business. Led, no doubt, by the Scrum Alliance’s successful Certified ScrumMaster offering, we now see hundreds, perhaps thousands of so-called “Agile” coaches and trainers, and many competing frameworks and methods.
Over a period of years, I’ve heard from many developers who say that “Agile” sucks. (Usually they say that “Scrum” sucks, because most people in organizations trying to do “Agile” are in organizations trying to do Scrum.)
It breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better.
[Developers] should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods. Those development approaches, to me, involve use of practices such as, but not limited to, those of Extreme Programming.
Robert C. Martin
Enfin, la même année, Robert C. Martin s’est également exprimé au sujet de l’agilité dans The Tragedy of Craftsmanship6 :
The Agile movement got so involved with promoting conferences and with certifying Scrum Masters and Project Managers that they abandoned the programmers, and the values and disciplines of Craftsmanship.
The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: “Wow! Agile is a cool new variation on how to manage projects.”
Craftsmanship is the Agile, that the Agile movement left behind.
[Craftsmanship] is about working well, adding value, and doing a good job. It’s about interacting, communicating, and collaborating. It’s about productively adapting and responding to change. It’s about professionalism and ethics.
Rendons l’agilité aux devs
En préparant cette conférence, j’ai eu l’occasion d’échanger avec différentes personnes impliquées dans l’organisation de conférences agiles. L’une d’elles, m’a indiqué ces mots, en parlant de sa conférence :
C’est une conférences agile, ce n’est pas pour les devs.
Ce type de propos illustre une séparation entre l’agilité (perçue comme une affaire de méthodes, de management) et le développement logiciel.
Cette phrase montre également le fossé entre les attentes des devs d’une part et la vision (d’une partie ?) de la communauté agile d’autre pas.
Cela explique également pourquoi, en tant que développeuse, j’ai l’impression de ne pas avoir ma place dans les conférences agiles : les devs ne sont pas la cible des conférences agiles.
Comment rendre l’agilité aux devs ?
Apprenez à faire confiance aux équipes de développement et faites-leur entièrement confiance.
Ce sont elles qui font le travail.
Ce sont elles qui sont sur le terrain.
Ce sont elles qui sont les mieux placées pour savoir ce qui est adapté à leur contexte et leurs problématiques.
Ce sont elles qui sont les mieux placées pour savoir ce qui n’est pas adapté à leur contexte et leurs problématiques.
Écoutez-les, faites-leur confiance et vous verrez : tout va bien se passer :)
Bibliographie
Bibliographie
-
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. Agile Manifesto. https://agilemanifesto.org/ ↩
-
Thomas, D. (2014). Agile is Dead (Long Live Agility). pragdave. https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html ↩
-
Hunt, A. (2015). The Failure of Agile. Andy Hunt’s Toolshed Technologies Home Page. https://toolshed.com/2015/05/the-failure-of-agile.html ↩
-
Fowler, M. (2018). The State of Agile Software in 2018. martinfowler.com. https://martinfowler.com/articles/agile-aus-2018.html ↩
-
Jeffries, R. (2018). Developers Should Abandon Agile. Ron Jeffries. https://ronjeffries.com/articles/018-01ff/abandon-1/ ↩
-
Martin, R. C. (2018). The Tragedy of Craftsmanship. Clean Coder Blog. https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html ↩