Arrêtez la méthode Scrum... Et pratiquez l’agilité !

13 décembre 2019

L‘agilité est bien plus qu’une méthode ! C’est une approche et une culture différente. On oublie parfois qu’elle touche également toute l’entreprise si on veut la mener jusqu’au bout et profiter de toutes ses vertus. La méthode la plus répandue est bien sûr la célèbre méthode “Scrum”. Cet article a pour but d’essayer de vous aider à vous poser les bonnes questions si, justement, vous pratiquez l’agilité ou si vous êtes dans une démarche de mise en place dans votre structure, équipe ou entreprise.

Le guide Scrum adulé !

Si on touche de près ou de loin à l’agilité, nous avons tous pratiqué toute ou partie la méthode Scrum. C’est, en effet, la plus répandue, la plus pratiquée et, certainement, la plus documentée du moment. Depuis deux décennies, elle a fait ses preuves et continue de les faire. L’Agile Manifesto n’est pas déraisonnable et est basé avant tout sur du bon sens ainsi que sur des grands principes clés. Cependant, cette méthode est souvent pratiquée à contre-sens même de l’agilité, telles que ses 4 grandes valeurs nous incitent à le faire.

- les individus et leurs interactions plus que les processus et les outils ;

- un logiciel qui fonctionne plus qu’une documentation exhaustive ;

- la collaboration avec les clients plus que la négociation contractuelle ;

- l’adaptation au changement plus que le suivi d’un plan.

Certains diront que c’est un “truc à la mode” de pratiquer l’agilité. D’autres, qu’on leurs a imposé cette méthode ou simplement qu’ils souhaitaient arrêter le “cycle en V”. Tout un tas d’organismes, de coachs et d’experts sauront vous accompagner dans sa mise en place au sein de votre structure. Mais leur mise en place est-elle “agile” ?

via GIPHY

Il ne faut pas simplement se contenter de mettre en place la méthode, mais être vigilant à inculquer la culture agile lors de sa mise en place. Ce n’est pas en mettant en place des itérations, en nommant un Product Owner et un Scrum Master et en collant quelques post-it que l’on devient “agile” ou que l’on peut prétendre faire de l’agilité.

Être agile plutôt que faire de l’agile

l'état d'esprit de l'agilité

Il faut avant tout voir l’agilité comme un état d’esprit, où l’équipe, voire l’entreprise, est motivée à y aller (oui, il ne faut pas oublier que toute l’entreprise est concernée). Il est nécessaire de comprendre les pratiques de l’agilité avant d’essayer de la mettre en place. Viendra ensuite la phase d’intégration et de mise en application. Le guide Scrum sera ensuite là pour vous aider à comprendre en détail le concept de la méthode et vous donner quelques outils pour y arriver.

Se poser la question du "Pourquoi-fais-je cela ?"

Le Scrum, l’ eXtrême Programming restent des méthodes. Elles ne sont peut-être pas toujours adaptées à votre besoin ou à votre structure. Il est donc primordial de ne pas les appliquer “à la lettre” mais de s’en inspirer, d’essayer, de tester, de débriefer. Tout l’intérêt de l’agilité est là. C’est essayer une pratique, une organisation afin de la valider ou, au contraire, la modifier ou revenir en arrière car elle n’apporte rien à l’équipe, au client ou au produit. L’équipe se sent-elle mieux ? Apportons-nous plus de valeur à notre produit de cette manière ? Mes tâches apportent-elles de la valeur ? Le rythme est-il adapté?

Ce n’est pas parce que l’on vous a préconisé des itérations de deux semaines que ce rythme sera le bon pour votre équipe. Tout comme l’utilisation des post-it ou d’un outil de ticketing.

Rappelez-vous : les individus et leurs interactions plus que les processus et les outils” !

Utiliser les outils qui vous ressemblent et qui vous correspondent le mieux.

A quoi bon prendre un outil de ticketing avec 25 fonctionnalités si un tableau avec quelques post-it vous suffit ?Au contraire, si vos valeurs écologiques sont mises à mal par l’utilisation de centaines de post-it par mois, arrêtez ! Trouvez un autre outil (tableau effaçable, …) qui vous correspondra mieux ! L’outil ne doit-être qu’un support à la cohésion et à l’interaction entre les coéquipiers. Le tableau de post-it est généralement retenu car il reprend les principes clés : simplicité, lieu d’échanges, partage (vision claire et simple de l’avancée du projet, accessible à tout le monde).

Ne pas oublier l’importance d’impliquer, dans la démarche agile, tous les intervenants (clients, équipe externe…).

Sans cela votre projet peut être mis à mal. Votre équipe peut se sentir ralentie ou incomprise sur certains sujets, et cela peut donc malheureusement générer des tensions inutiles. Sans connaître vos pratiques, votre client pourrait-être amené à vous demander un planning ; planning que vous ne saurez lui fournir (en tout cas, pas sur un long terme).

….mais aussi “l’adaptation au changement plus que le suivi d’un plan.

Restez flexible et ouvert à tout changement pouvant apporter de la valeur à votre produit. Plusieurs modèles appliquant l’amélioration continue et l’agilité prônent cette valeur. La “rétrospective” ou “débrief” est un moment privilégié et dédié à la communication au sein de l’équipe. L’échange sur le bien-être, l’appartenance à l’équipe et les points de blocages est primordial et aidera l’équipe à aller dans la bonne direction et à être en quête de la perfection ! Avoir un moment de partage est bien, mais en ressortir des actions est mieux. Si l’équipe ressort un point négatif, tout l’intérêt de l’agilité est de le résoudre (en tout cas d’essayer), afin de rendre l’équipe meilleure. Bien sûr, tous les problèmes identifiés ne peuvent être résolus du premier coup mais il est impératif de chercher des solutions (collectivement) aux soucis. Certes, le fait de faire parler tous les membres de l’équipe évitera des problèmes de fond mais ne l’aidera pas plus à avancer.

Prenez des idées et adaptez-les !

La majorité des articles, formations et informations que l’on trouve sur la méthode Scrum vous recommanderons de pratiquer un certain nombre de cérémonies, un certain nombre de “process”. On ne remet pas en cause ici ces pratiques car elles font leurs preuves et peuvent être totalement adaptées à certains contextes. On recommanderait seulement de voir cela comme une boîte à outils géante, où se trouvent pleins de pratiques à prendre, essayer, creuser dans l’objectif de trouver la bonne pratique adaptée à votre projet ou entreprise. Vous ne devez pas vous adapter à la méthode, vous devez adapter la méthode à votre usage !

via GIPHY

Vous trouvez que le rythme d’une itération de 15 jours génère trop de temps passé en réunion ? Allongez-le ! Adaptez le temps à votre organisation. Vous livrerez peut-être des fonctionnalités moins régulièrement mais rappelez-vous des piliers de l’agilité : les individus et leurs interactions plus que les processus et les outils. Si les coéquipiers de l’équipe ne se sentent pas bien dans l’équipe, cela va se ressentir dans leur travail et donc dans le produit. Un développeur peut parfois avoir besoin de temps, de concentration et ne pas être interrompu pour coder proprement. Réfléchissez au planning en amont et essayez de répartir les réunions.

Rétrospective, Sprint planning, Daily meeting, Backlog raffinement, Priority meeting, Réunion d’architecture, Réunion d’équipe avec le management,…ça peut faire beaucoup en effet !

On peut lire parfois également que l’agile engendre du “retard technique” : un traitement plus long des bugs ou une lenteur de l’amélioration technique. Est-ce vraiment la faute de la méthode ou plutôt de la manière dont-elle est appliquée ? Intégrez ces améliorations, bugs, etc… dans vos itérations, et voire même dédiez-en une si nécessaire ! Le principal est d’avoir un produit fonctionnel ET opérationnel.

Comme évoqué précédemment, la priorité à donner dans l’agilité doit être de se focaliser sur l’équipe et l’attendu (le produit) et non principalement sur la méthode. On connait les bienfaits des teams building, mais il ne faut pas oublier l’objectif de ces derniers, tout comme l’utilisation des jeux et des “ice-breakers”. Ils doivent être utilisés avec parcimonie, tout en ayant un objectif. Le but n’est pas de uniquement de “passer” un bon moment. Que ce soit pour renforcer l’esprit d’équipe ou pour faire ressortir une problématique interne à l’équipe, les jeux doivent être en adéquation avec la situation.

Il n’y a pas que le Scrum dans la vie ! Découvrons d'autres méthodes pratiquant l'agilité

Souvent méconnues, plusieurs autres “méthodes” se sont développées et ont, en quelque sorte, adaptées l’Agile Manifesto à notre époque et aux nombreux changements. Ci-dessous, quelques-unes d’entre elles :

Agnostic Agile : communauté d’agilistes aidant les entreprises à trouver le bon niveau d’agilité, en se reposant sur 12 principes fondateurs (Priorité au client, adaptation, partage, ...)

Heart of agile : 4 grands principes concentrés autour d’une approche radicalement plus simple dans le but d’obtenir des résultats exceptionnels ;

- Collaborer : afin de générer les meilleures idées ;

- Améliorer : les idées, les processus et la mise en œuvre technique ;

- Livrer : par petit incrément et tirer les leçons de chaque livraison ;

- Réfléchir : une sorte de rétrospective afin de voir ce que l’équipe a appris.

Modern Agile : Modern Agile est une communauté pour les personnes intéressées de découvrir de meilleures façons d’obtenir des résultats impressionnants, construit autour de 4 grands principes:

- Rendre les gens fantastiques ;

- Apporter de la valeur en continu ;

- Faire de la sécurité un pré-requis ;

- Expérimenter et apprendre rapidement.

Toutes ces méthodes peuvent-être positives si elles sont appliquées avec une volonté forte et partagée par toute la hiérarchie d’un changement profond d’organisation et/ou de structure de l’entreprise.

Conclusion

L’agilité regorge de bonnes pratiques, méthodes et jeux permettant d’apprendre de façon ludique. Cependant, si leur mise en place n’est pas adaptée, l’approche peut-être perçue de façon négative ou lourde pour les équipes. Il est donc important de donner un sens à la démarche et de savoir comment et vers où l’équipe souhaite aller, quelque soit la méthode appliquée. Retenez que la meilleure des méthodes est la vôtre !

Mathias BOCQUIER, Product Owner à Valeuriad - relu par la Tribu Agile de Valeuriad

Valeuriad
Par Valeuriad
13 décembre 2019
Nos derniers articles
La théorie du Chaos

Le Chaos Engineering est une pratique qui consiste à tester la résilience d'un système informatique en introduisant intentionnellement des défaillances…