Les méthodes agiles sont actuellement sur toutes les lèvres et constituent un mot à la mode populaire, synonyme de changement et de renouveau. Jusqu’à présent, les méthodes agiles, et en particulier SCRUM, étaient principalement connues dans l’informatique, notamment dans le développement logiciel. Cependant, cette tendance se propage désormais à tous les départements de l’entreprise. Mais les équipes non techniques peuvent-elles vraiment appliquer des méthodes agiles ? La réponse succincte est : bien sûr ! Les valeurs et principes agiles peuvent être facilement transposés à d’autres environnements. Les nouvelles méthodes peuvent être appliquées non seulement dans les équipes, mais aussi dans des départements entiers. Cependant, si un manager impose soudainement à son équipe une méthode dont il vient d’entendre parler, cela peut rapidement se retourner contre lui. Beaucoup ne sont pas encore familiarisés avec les nouvelles méthodes de travail, sont sceptiques ou les rejettent catégoriquement. Par conséquent, il ne faut pas introduire au hasard de nouvelles réunions et des murs de post-it simplement parce qu’une autre équipe travaille avec succès de cette manière. Les méthodes agiles devraient toujours apporter une valeur ajoutée et soutenir l’équipe, plutôt que de créer un travail supplémentaire.
Les méthodes comme valeur ajoutée
Le point de départ pour une nouvelle méthode dans une équipe existante est généralement un problème, un conflit ou même un obstacle à surmonter. En utilisant des méthodes agiles, le problème ou le conflit peut être résolu, créant ainsi une valeur ajoutée. Le graphique montre un problème classique que beaucoup connaissent dans la routine de bureau. C’est toujours la même personne qui vide le lave-vaisselle, remplit les grains de café ou apporte des gâteaux. Un merci est rare, il y a un manque d’appréciation et de reconnaissance mutuelles. En introduisant un tableau KUDOS (dérivé du mot grec pour gloire et honneur), chacun peut exprimer sa gratitude et son appréciation envers les autres. Chaque employé peut écrire sur les post-its fournis à qui il est reconnaissant, que ce soit pour l’organisation d’un tournoi de babyfoot ou pour faire avancer la vision de l’entreprise. Les photos conviennent également bien au tableau KUDOS ! En conséquence, la satisfaction et la cohésion augmentent parmi les employés ou les membres de l’équipe. Il y a généralement une plus grande volonté d’assumer des tâches quotidiennes petites et grandes.
Utiliser des méthodes agiles pour résoudre des problèmes ou des conflits
Clarifier les attentes vis-à-vis des méthodes agiles
Avant de recourir aux méthodes agiles, il convient de prendre conscience de ce que l’on en attend réellement. Ce n’est qu’ainsi que l’on pourra mesurer ultérieurement si la méthode a vraiment apporté une valeur ajoutée ou si elle n’était pas adaptée à l’objectif.
Pour ce faire, il est utile de clarifier l’objectif visé et de le mettre par écrit conjointement pour l’équipe ou le département. Tous les membres de l’équipe doivent-ils être mieux informés de l’avancement du projet ? Faut-il réduire le nombre de courriels ou avoir une meilleure vue d’ensemble des tâches ouvertes et accomplies ? Le plus souvent, l’objectif découle déjà des problèmes ou conflits existants. Cela permet également de montrer aux critiques pourquoi on essaie maintenant quelque chose de nouveau. Des attentes claires aident non seulement à préparer et à choisir la bonne méthode. Après quelques semaines d’application, il est beaucoup plus facile de déterminer si la méthode a vraiment rempli son objectif. Chaque membre de l’équipe peut réfléchir si ses attentes individuelles ont été satisfaites ou non.
SCRUM même sans programmation
Il existe une multitude de méthodes agiles que l’on peut utiliser en dehors des équipes techniques. Cependant, comme beaucoup connaissent bien le cadre SCRUM, je voudrais aborder dans ce qui suit comment on peut utiliser certains éléments clés de SCRUM dans n’importe quelle équipe, qu’elle développe un logiciel, déploie un nouveau logiciel ou soit responsable des mesures marketing. Ceux qui souhaitent rafraîchir leurs connaissances sur SCRUM peuvent lire un résumé du cadre dans cet article.
Quotidien : Une réunion quotidienne d’une durée maximale de 15 minutes, au cours de laquelle l’état du projet est résumé collectivement, permet à chaque membre de l’équipe d’avoir le même niveau de connaissance. Il n’est pas nécessaire que tous soient dans la même pièce, une réunion virtuelle remplit tout autant son objectif. Lors de cette réunion quotidienne, chacun peut brièvement présenter son avancement, les problèmes peuvent être discutés ensemble et les tâches peuvent être rapidement attribuées aux différents membres de l’équipe. L’effort de coordination peut ainsi être considérablement réduit. Au lieu de nombreux canaux de communication individuels entre les personnes, une concertation commune peut accélérer significativement l’équipe. Par exemple, j’ai eu des expériences très positives avec cette méthode dans un grand projet de déploiement. 15 minutes au début de la journée de travail ont par la suite évité de nombreux appels téléphoniques individuels, courriels et discussions.
Sprints : Dans SCRUM, l’objectif des sprints est de diviser un grand bloc de travail en petits lots qui sont traités successivement. Ce concept peut également être appliqué à d’autres domaines. Chez digatus, par exemple, nous avons une initiative interne pour créer des modèles PowerPoint standardisés pour les rapports et présentations récurrents. Au lieu d’un grand projet s’étalant sur plusieurs semaines et aboutissant à 20 modèles, nous avons divisé le travail en plusieurs itérations. Plutôt que de présenter vingt modèles à l’entreprise après six mois, nous pouvons présenter cinq modèles tous les deux mois. Les avantages sont les mêmes que dans SCRUM : nous livrons des résultats en continu et pouvons adapter notre approche aux circonstances à tout moment.
Rétrospectives : Un concept fondamental des méthodes agiles est la réflexion et l’optimisation continues de sa propre méthode de travail. Même sans SCRUM, les équipes ou les départements peuvent mener une rétrospective et analyser ce qui fonctionne bien et ce qui fonctionne mal, quelles habitudes devraient être abandonnées et lesquelles l’équipe souhaite conserver. Les rétrospectives peuvent être menées de différentes manières, selon ce que l’équipe trouve le plus approprié. Un bon exemple est la méthode KISS (Keep, Improve, Start, Stop). Chacun commence par noter sur des post-its quelles pratiques il/elle souhaite conserver, renforcer, commencer ou arrêter dans l’équipe. Ensuite, chaque membre de l’équipe colle les post-its sur une surface préparée à cet effet (par exemple, un tableau à feuilles mobiles ou un mur vide). Enfin, les résultats sont discutés ensemble et des mesures sont définies pour leur mise en œuvre. L’attente initialement définie vis-à-vis d’une nouvelle méthode peut d’ailleurs également être vérifiée lors d’une rétrospective.
Conclusion
De nombreuses méthodes issues du développement logiciel peuvent également être adaptées à d’autres domaines. Il n’est pas nécessaire de développer des logiciels, de gérer une application ou de travailler dans un service d’assistance informatique pour utiliser des méthodes agiles. Le domaine des méthodes de travail agiles englobe de nombreuses méthodes et principes qui peuvent également être utilisés dans un environnement non technique. Non seulement les équipes de projet, mais aussi les départements (tels que le marketing, les ressources humaines ou les ventes) peuvent recourir à des méthodes de travail agiles. Les environnements particulièrement dynamiques, où des changements fréquents se produisent, peuvent bénéficier des méthodes agiles. Ce n’est pas sans raison que « Embrace Change » est un thème central de l’agilité. Il est important de choisir la méthode en fonction du problème à résoudre et de ne pas imposer quelque chose à l’équipe simplement parce que c’est à la mode. Il s’agit donc surtout de se fixer un objectif commun et d’essayer de l’atteindre, plutôt que d’appliquer simplement une méthode.
