Vous l’aurez compris au titre de l’article, le sujet d’aujourd’hui concerne le développement logiciel à travers les méthodologies agiles. Pour celles et ceux ne sachant de quoi il s’agit, lisez cet article d’introduction aux méthodologies agiles.
Attention : il n’est pas question ici d’évangéliser le fait que ces méthodologies fonctionnent pour tous les projets ; il ne s’agit que d’outils, impossible de convenir à toutes les situations ! Non, le débat du jour se situe sur la distinction entre agilité et souplesse dans une équipe produit.
Si vous êtes convaincus que ces deux termes sont identiques, alors pour vous le yoga et le parkour ne sont qu’une seule et même discipline.
Flagrant délit de souplesse
Maintenant que vous sentez qu’il existe une différence entre agilité et souplesse, redonnons du sens à ces termes. La souplesse désigne la pseudo-agilité n’empruntant à l’originale que son vocabulaire et déformant les traits/principes pour coller à une représentation qui nous arrange.
Mais alors comment reconnaître la souplesse lorsqu’on la croise ? Signe avant-coureur si l’on vous annonce « ici on fait de l’agile », commencez à vous poser des questions. Faute langage ou lapsus révélateur il faudra creuser pour savoir, toujours est-il qu’il faut être agile.
D’accord jouer sur les mots c’est sympa, mais concrètement comment savoir si l’on dérive ou pas ?
Le meilleur du pire…
Pour m’aider à répondre à cette question j’ai compilé le top des réponses d’un petit sondage effectué auprès de différents adeptes de l’agilité :
- « pas la peine d’écrire de spécifications, on fait de l’agile » ⇒ Alors oui mais en fait non. Les spécifications sous forme de cahier des charges de 1200 pages (que personne ne supporte), sont effectivement à proscrire ; en revanche il est impensable de commencer à développer une fonctionnalité sans un minimum de spécifications.
Ce minimum est à rédiger fraîchement en amont de l’implémentation, de façon à être en phase avec le besoin. - « ne teste pas, ça va plus vite » ⇒ Au-delà de la véracité douteuse de ces propos, je vous invite à réfléchir au concept suivant : « sans qualité, pas de maîtrise ». Si vous n’avez pas de tests, documentation vivante de l’application, impossible de prévoir le coût de modification d’une fonctionnalité ; au mieux vous aurez une estimation complètement hasardeuse sur laquelle vous baser pour fixer une deadline.
Que celui qui monterait dans une Tesla dont le logiciel de navigation n’est pas testé, me jette la première pierre. - « tu avais estimé la tâche à 3j, ça fait 5j » ⇒ Oui les méthodologies agiles sont aussi là pour responsabiliser de l’équipe. Mais lorsque l’on s’engage c’est sur un résultat, l’estimation préalable n’est que ce qu’elle est : une estimation.
Qui est le plus responsable : celui qui assume l’erreur d’estimation et conserve la qualité de réalisation, ou celui prenant des raccourcis pour coller au planning ? - « je suis sûr que l’utilisateur veut cela » ⇒ On ne sait jamais ce que veut l’utilisateur, lui non plus de toute manière. Les besoins évoluent constamment et les prédictions tiennent rarement ; il suffit de mettre une version de l’app dans les mains d’utilisateurs pour qu’ils vous suggèrent d’autres fonctionnalités.
Et ça tombe bien, il sera possible de les réaliser lors de la prochaine itération…
… et ses conséquences
Malheureusement cette liste n’est pas exhaustive, il est en effet courant que certaines cérémonies soient l’objet de dérives. Par exemple les « daily meetings » donnent souvent lieu à un flicage à cause de son format de reporting ; les « sprints » sont raccourcis en cours de route afin de livrer plus rapidement une fonctionnalité…
Les conséquences pour l’équipe et le produit sont bien souvent extrêmement négatives, tant sur le fond que sur la forme :
- L’absence de spécifications met l’équipe en difficulté lorsque survient l’implémentation ; la moindre fonctionnalité, même basique, nécessite des allers-retours incessants et n’est jamais réellement terminée. Un sentiment de faire du « surplace » s’installe et a un impact immédiat sur la productivité de l’équipe.
C’est là qu’une dissension peut s’installer entre l’équipe et les parties prenantes, ne voyant pas le projet avancer. - Le reporting et flicage incessant génèrent une pression et un sentiment d’insécurité générale au sein de l’équipe. Il est impensable de construire un produit de qualité de manière constante dans ces conditions, or c’est un des piliers de l’agilité.
Cette pression/insécurité peut éventuellement pousser certains membres de l’équipe à partir. - Impossible de faire confiance à son produit sans tests, les problèmes finissent toujours par arriver. Au-delà du coup de frein évident sur la productivité, un bug repéré en production peut avoir d’énormes répercussions au niveau business.
Imaginez : le parcours de validation du panier d’achat n’est pas testé, le bug est remonté 3j après le déploiement de la nouvelle version ; combien de chiffre d’affaires avez-vous perdu sur cette période lorsque vos clients ont abandonné leur panier ?
Encore une fois cette liste est loin d’être exhaustive mais parfaitement évitable si l’on devient agile. « Comment faire ? » me direz-vous, c’est le sujet de la prochaine section de l’article !
Agilité : un état d’esprit
Premièrement il faut comprendre que l’agilité n’est pas un ensemble de règles strictes, mais un état d’esprit à maintenir. La première étape est de lire le manifeste agile et savoir si l’on adhère à son contenu. Pour ceux qui le trouvent trop abstrait, les 12 principes sous-jacents du manifeste sont plus concrets.
Agile par choix
L’agilité au sein d’une équipe pour un projet ne peut pas être imposée ; il s’agit d’une prise de conscience et d’un engagement collectif. Ne cherchez pas à l’imposer au sein de l’équipe, il vaut mieux les intéresser progressivement au sujet. De nombreux ateliers d’expérimentation et d’introduction à l’agilité existent et il est possible de les réaliser avec l’aide d’un coach agile.
Celui-ci sera plus à même de vous démontrer le plein potentiel de l’agilité et pourra répondre à vos questions particulières à votre situation.
Il est fortement recommandé de continuer à réaliser des exercices une fois le processus agile en place. En effet cela permet à tout le monde de s’approprier l’état d’esprit nécessaire et de le transmettre à tout nouvel arrivant au sein de l’équipe.
Les arrivées et départs dans une équipe sont synonymes de baisse de vélocité : temps d’intégration, appropriation… Si vous souhaitez conserver une vélocité constante sur un projet, et coller à vos prévisions, évitez de remanier l’équipe constamment.
Prendre le temps
Grâce à cette appropriation, l’équipe est en mesure de définir les règles et méthodes les plus adaptées à sa situation. Cet ensemble est défini comme le « cadre de travail » de l’équipe ; ce dernier évolue avec l’équipe, mais il est primordial de le respecter : sans respect du cadre vous ne trouverez pas l’agilité mais l’anarchie.
La mise à jour du cadre s’opère est constante, notamment grâce à des moments de réflexion dédiés.
Ce sont d’ailleurs ces instants de réflexion qui font toute la valeur ajoutée de la vraie agilité. Ils permettent de sortir la tête du guidon et de procéder à une introspection de l’équipe, relever les points bloquants et proposer des solutions qui seront ensuite éprouvées lors de la prochaine itération.
Ces corrections de cap régulières permettent à l’équipe de continuer à s’améliorer dans le temps de la même manière que le produit.
Avec ou sans framework ?
Vous avez probablement entendu parlez des processus agiles via leurs deux représentants les plus connus : SCRUM et Kanban. Ces frameworks ont pour but de poser un cadre initial répondant à certaines problématiques que l’on rencontre en devenant agile.
Ces méthodes sont de bonnes références dans l’agilité, mais cela ne signifie pas qu’elles sont forcément adaptées à vos besoins. Partir du besoin est le point de départ de réflexion de tout bon « agiliste », alors ne négligez pas les vôtres !
Bien sûr partir d’un modèle prédéfini est rassurant et plus simple à mettre en place au départ. L’important est de s’approprier le modèle par la suite, afin de tirer le maximum des processus agiles.
Si cela fait trop d’un coup pour vous, n’hésitez pas à l’intégrer petit à petit : lorsque l’on est agile « adaptabilité » est le maître mot !
De la même manière que se targuer de « faire de l’agile » ne rend pas votre équipe agile, ne pas marquer « SCRUM » en haut de son tableau blanc n’enlève rien au fait d’être agile. C’est d’ailleurs la réponse de 82% des personnes interrogées à la question « selon vous une équipe qui ne suit pas une méthodologie bien définie (ex: SCRUM / Kanban…) peut-elle être agile ? ».
Finalement
Il faut comprendre que l’on ne fait pas de l’agile, on le devient par la pratique et l’introspection. Les processus agiles sont empiriques, itératifs et personnels de manière à garantir la meilleure adaptation à chaque équipe/produit.
A contrario en rejetant les temps de réflexion et en pliant le cadre agile, la souplesse aura un impact négatif sur votre équipe et votre produit.
Le sujet de l’agilité est très vaste et ce fût un véritable challenge que de conserver mon angle sans digresser, tout en parlant de l’essentiel. C’est pourquoi je tiens à remercier toutes les personnes interrogées via le sondage, les messages directs et les cafés, d’avoir répondu à mes questions et de m’avoir fourni le matériel nécessaire pour cet article !
Si cet article vous a plu, n’hésitez pas à me le faire savoir en le likant et en le partageant sur vos réseaux sociaux. Vous pouvez également profiter de mes autres articles lorsque vous aurez 5 minutes !
