Voici quelques leçons durement apprises dans les tranchées l’année dernière en 2021. La plupart de ces enseignements sont vrais depuis plusieurs années, mais ce sont récemment exacerbés.
En 2021, l’agilité a vécu une année folle. Lors de cette deuxième année de travail à distance elle a pris des virages étranges et inattendus.
J’ai vécu des moments incroyablement inspirants… et j’en ai aussi vécus qui m’ont donné envie de remettre en question la viabilité de l’agilité.
La chance m’a permis de travailler avec douze entreprises au cours des deux dernières années. En 2020, j’ai vu des modèles commencer à prendre forme, et en 2021, ils sont devenus des tendances évidentes. Ainsi, voici douze réflexions et stratégies d’avenir que j’aimerai vous partager.
Les 12 enseignements de 2021
№1 : Il y a encore des néophytes agile et leur transmettre l’agilité est excitant
Ce fut une surprise car je ne m’attendais pas à ce qu’une équipe ou une organisation découvre encore, 20 ans après la formalisation du manifeste agile, l’agilité.
Mais c’est plus courant que je ne le pensais : J’ai travaillé avec plusieurs personnes au cours des deux dernières années qui n’avaient jamais entendu parler d’Agile, de Scrum, de Kanban ou de Lean. C’est fou non ?
Après que mon choc initial soit passé, j’ai découvert quelque chose d’autre qui dormait en moi. J’ai de nouveau éprouvé le frisson de révéler le monde des méthodes Agiles aux non-initiés Beaucoup de ces personnes n’avaient pas expérimenté cette façon de travailler de toute leur carrière. J’ai vu leur joie d’utiliser une approche centrée sur l’humain pour terminer les petites choses plus tôt. Quel bonheur !
№2 : Les équipes « pratiquant » Scrum depuis des années sont souvent loin d’être Agile
Ouch ! Celui-ci a fait mal !
Lorsque vous trouvez une équipe qui a déjà vécu 50 Sprints, vous vous attendez à apprendre de choses en l’observant car elle est expérimentée. Mais ce que j’ai vu n’était pas l’apprentissage auquel je m’attendais : une équipe peut « faire » Scrum pendant longtemps et être loin d’être Agile. Souvent ces équipes compromettent Scrum à un point tel qu’il est méconnaissable. Au lieu d’affronter et de supprimer les contraintes, ils les ont embrassées. Ils ont intégré les contraintes à leur façon de « faire » du Scrum. Et dérouler leur faux Scrum est dur et douloureux. Ces équipes seraient mieux sans leur Scrum bricolé et paralysé. Je trouve qu’il est plus intéressant d’utiliser mon énergie pour me concentrer là où je peux faire une différence. Les équipes qui sont satisfaites de leur variante non Agile de Scrum n’ont pas besoin de coaching de ma part. J’ai passé des mois au cours des deux dernières années à essayer d’aider ceux qui ne veulent pas être aidés; ça ne vaut pas le coup.
№3 : Tout le monde veut être axé sur les résultats, et presque personne ne l’est
Utiliser des Buzzwords, des mots à la mode, comme si on a avalé de la potion magique c’est cool. Dire Backlog, product Owner, accelerate, wip, etc… tout ces concepts mal appliqués ne provoquent un changement qu’au niveau de la surface. La plupart des actions et des comportements restent profondément enracinés dans des valeurs et des moteurs prédictifs. Les nouveaux comportements axés sur les résultats, la valeur et les changements apportés au système n’ont pas rattrapé le discours à la mode.
№4 : Pour la plupart, une utilisation disciplinée de Jira signifie la même chose qu’être Agile
Dans presque toutes mes missions on m’a inévitablement demandé : “Pouvez-vous nous à mieux utiliser Jira ?”. Pour moi, ces outils sont les cancers des entreprises puisqu’ils tuent la collaboration. Une concentration malsaine sur eux donne la priorité aux outils et aux processus plutôt qu’aux individus et aux interactions. En 2021, le travail à distance en a poussé beaucoup dans le piège de moins collaborer et d’utiliser plus ces outils de ticketing.
Face à cela, j’essaie de guider les équipes vers une compréhension plus profonde de ce que signifie être Agile et être tourné vers les gens.
Les outils et les processus ne rendront pas les équipes agiles. Le respect des personnes et l’accent mis sur les interactions humaines l’emportent à chaque fois.
№5 : La prévision des dates de livraison et la livraison dans les délais dominent toujours la conversation
Voici un échantillon de ce que j’ai entendu cette année en ce qui concerne les délais :
- “Nous avons besoin d’une feuille de route détaillée qui inspire la confiance que nous pouvons livrer dans les délais et le budget.”
- « Nous ne pouvons pas être purement Agiles. Nous devons composer avec la réalité. Et la réalité est la suivante : nous devons respecter les délais. »
- “Sans délai, les équipes n’accompliront jamais rien.”
- “J’espère que vous n’êtes pas un de ces puristes Agiles qui croient que nous n’avons pas besoin de délais.”
- « Nous devons avoir des délais solides et des livrables fermes pour faire approuver notre budget annuel. »
Ces citations proviennent des mêmes personnes qui souhaitent être agiles et qui prétendent vouloir se concentrer sur les résultats et la valeur. La plupart ne réalisent pas à quel point les délais fonctionnent contre l’Agilité. L’atteinte des résultats restera une chimère insaisissable tant que les délais seront au centre des préoccupations.
№6 : La plupart des équipes vivent avec des dépendances au lieu de les éradiquer
Grandes ou petites, vieilles ou récentes, les entreprises avec lesquelles je travaille sont truffées de dépendances. Leur réponse par défaut est de tolérer et de gérer les dépendances par la coordination. Comme dans un PI planning par exemple. La dissolution des dépendances est rarement considérée comme une option.
Et tous les suspects habituels sont en jeu. Pour n’en nommer que quelques-uns, nous avons des équipes différentes pour la stratégie, la recherche, l’expérience utilisateur, le front-end, le back-end, les données, le test, la plate-forme, l’infrastructure et la sécurité. Les entreprises prennent ces décisions structurelles avec de bonnes intentions. Ils visent à réduire les coûts et à optimiser les avantages de la spécialisation avec ces silos.
Mais dans leur quête d’optimisation locale, les équipes spécialisées se retrouvent bloquées sur des îles désertes, très éloignées de tout résultat utilisateur. Ils finissent par avoir du mal à occuper les spécialistes et à créer des goulots d’étranglement. Et le flux de valeur ralentit ou même s’arrête face à ces impacts néfastes.
Les dépendances tuent le flux et sont égales aux délais pour empêcher une orientation vers les résultats. L’autonomie, la maîtrise et le but ne peuvent pas coexister avec les dépendances.
№7 : Beaucoup valorisent la formation et les certifications plutôt que le coaching
La plupart des organisations supposent que les formations et les certifications sont tout ce dont elles ont besoin pour “devenir” Agile. Ils croient que si toutes les équipes sont formées et certifiées, tout se mettra en place comme par magie. C’est une solution miracle que recherchent de nombreuses organisations, mais c’est une quête vaine.
J’ai vu de nombreuses entreprises perdre leur temps et leur argent dans la formation et les certifications.
Si les connaissances acquises ne sont pas appliquées avec les conseils d’un coach expérimenté, s’il n’y a pas d’accompagnement post-formation, elles se faneront et mourront. Les certifications n’aideront pas non plus.
Sans coaching, de nombreuses équipes abandonnent trop tôt lorsqu’elles trébuchent en essayant un nouveau modèle de comportement. Mais avec un coach lean agile comme guide, il peut les aider à utiliser l’échec comme une opportunité d’apprentissage pour corriger le cap.
Les formations ou certifications sans coaching sont un gâchis pour l’entreprise, les équipes et moi. Rien ne remplace l’expérience, et vous ne pouvez certainement pas la former ou la certifier.
№8 : Les Scrum Masters sont mal compris et ne sont pas valorisés
Neuf fois sur dix, les entreprises avec lesquelles je travaille n’ont même pas pensé au Scrum Master. Ou s’ils l’ont fait, vous trouverez un Scrum Master au service de trois équipes ou plus.
Dans de nombreux cas, le Scrum Master est une réflexion après coup, assignée au hasard à un développeur de l’équipe en tant que double responsabilité. Cela vient en grande partie du fait que les organisations considèrent le Scrum Master comme une fonction administrative et facultative de gestion de projet. Pour aggraver les choses, les quelques Scrum Masters qui sont en jeu n’ont aucune expérience ou une mauvaise expérience. Ils ont une certification (parfois) et de bonnes intentions. Mais ils n’ont pas de véritable expertise ou pouvoir pour aider les équipes.
Voici quelques-unes des choses terrifiantes que j’ai vu des Scrum Masters faire cette année :
- Fixer des délais pour les US dans le Sprint et attribuer des USà chaque développeur pour les démarrer en parallèle
- Fixer des objectifs de vélocité pour l’équipe
- Compter la vélocité partielle pour le travail non effectué – “Nous devons obtenir nos points!”
- Dire : « Nous ne pouvons pas changer la façon dont l’organisation fonctionne, nous devons donc l’aspirer et faire des choses dont nous ne pensons pas avoir besoin.
- Demander à chaque développeur de s’engager sur un certain nombre de points pour chaque sprint
- Demander le statut lors du Daily Scrum pour faire rapport à la « direction »
- Annuler les revues de sprint et les rétrospectives afin que les US engagées puissent être terminées
№9 : La gouvernance et le statut ont augmenté
J’attribue une partie de l’augmentation de la gouvernance au télétravail. Mais une grande partie a ses racines dans d’anciennes façons de penser.
Nous continuons à poursuivre la planification, la normalisation, la structure et le contrôle en tant que stratégies de réduction des risques. Cela étouffe l’énergie et le succès des équipes autonomes, capables de résoudre des problèmes et transparentes.
№10 : Les gens sont encore appelés “ressources”
Oui c’est vrai. Aujourd’hui encore, la plupart des entreprises considèrent leurs employés comme des ressources. Aucune mauvaise intention n’est présente, mais les mots comptent. Et le mauvais langage peut entraver un véritable changement de mentalité.
J’ai vu de nombreuses organisations que je coache vouloir arrêter de qualifier leurs employés de “ressources”. Je trouve ça génial quand ils veulent changer. Mais cela s’avère toujours être une habitude difficile à briser pour beaucoup.
Je trouve que je suis souvent hésitant lorsque j’aborde cette question. Je ne veux pas dénoncer ce comportement car cela pourrait être embarrassant pour mon client. Mais je devrai trouver des moyens de décourager doucement son utilisation au cours de l’année à venir.
№11 : Beaucoup n’ont pas d’yeux pour les déchets dans leur système actuel
Lorsque je commence mon coaching avec une organisation, je suis surpris par le peu de choses que l’on sait sur les gaspillages Lean. La plupart n’en ont jamais entendu parler. Même lorsque je le leur explique et que je leur montre à quel point leur système est plein de ces déchets, ils ne les voient pas.
La plupart des organisations considèrent ces déchets comme un sous-produit naturel de leur façon de travailler aujourd’hui. Ils sont dans leur statu quo depuis si longtemps qu’ils ne voient aucune issue. C’est comme ça et ils se sentent impuissants à changer leur situation.
Voici quelques-uns des gaspillages pervers que certaines organisations ne semblent pas voir :
- Effectuer une planification et une conception lourdes à l’avance pour réduire les risques
- Avoir une équipe centralisée de leads expérimentés pour prendre des décisions pour les équipes Scrum
- Séparer déploiement et livraison en équipes distinctes
- Réclamer le “Terminé” lorsque le code est terminé et le remettre à une équipe de test
- Répartition des compétences spécialisées en équipes homogènes et cloisonnées
- Construire des choses aujourd’hui au cas où nous en aurions besoin demain
- Passer des mois à prévoir quand quelque chose sera livré, combien cela coûtera et combien cela pourrait profiter à l’entreprise
- Garder les membres de l’équipe occupés même si la valeur n’est pas évidente
№12 : Dorénavant, les managers aident à la transformation Agile
Au cours de ma carrière de coach agile, j’ai vu des managers retarder activement ou bloquer toute décision de passer à un état d’esprit Agile. Mais au cours des deux dernières années, à ma grande joie, j’ai vu cette tendance commencer à reculer. Ces jours-ci, je trouve plus de managers qui veulent activer et soutenir l’agilité que ceux qui veulent tuer dans la mouvance.
La meilleure façon pour un manager de soutenir et de servir une équipe est d’éliminer les déchets que l’équipe ne peut pas éliminer elle-même.
Voici quelques-uns des actes héroïques que j’ai vus de la part de managers en 2021 dans leur quête d’un comportement Agile :
- Un groupe de managers s’est battu pour mettre en place un one piece flow, a formé d’autres managers et parties prenantes à ses avantages et a fixé un objectif à l’échelle du département pour atteindre une limite de travail en cours d’une pièce.
- Une équipe de direction a décidé d’arrêter les postes mi-mi, choisissant de s’efforcer que chacun de ses employés soit entièrement affecté à une équipe à la fois
- Une équipe de direction a pris des mesures pour identifier et aider à supprimer les dépendances douloureuses fréquentes qui affligent ses équipes
Pour bien débuter 2022
À bien des égards, les modèles que j’ai observés au cours des deux dernières années m’ont surpris étant donné à quel point nous sommes dans la chronologie Agile. Après tout, le Manifeste Agile a récemment fêté ses 20 ans. De nombreuses entreprises en sont encore à leurs balbutiements pour adopter un état d’esprit et des comportements Agiles.
En 2022, mon objectif et d’éradiquer les comportements liés aux délais, les dépendances et le mot « ressources ». Mon coaching se concentrera sur la mise en avant des managers pour conduire le changement. Ils doivent allumer l’étincelle, établir la confiance avec les équipes et cultiver des Scrum Masters pour les aider à attiser les flammes.
Est-ce que ce sera facile ? Certainement pas. Mais je ne peux pas m’asseoir sur la touche; Je dois changer mon approche pour accompagner le changement que je souhaite.
À la fin de 2022, je veux parler de la façon dont les entreprises ont misé sur le respect des personnes.
On en parle chez Zenika
Ci-dessous des extraits de conversations à propos de cette article. Après avoir demandé aux participants de la conversation leurs accords, je vous retranscrits ici les échanges car ils ont, à mon sens, de la valeur :
Intervenant 1 :
3 :
Toutes les équipes ne doivent pas être focalisées sur le résultat (outcome)
La conduite du changement ne doit être focalisé ni sur le résultat (outcome) ni sur le livrable (output), mais sur les vecteurs
4 :
Les tickets JIRA sont une forme d’interaction humaine. Il y a bcp de problèmes avec cette valeur du manifeste Agile “individus et interactions plutôt que processus et outils”, dont cette catégorisation manichéenne entre ce qu’on met à gauche et ce qu’on met à droite. Le monde est bcp plus complexe que ça.
“Having respect for people and emphasizing human interactions wins out every time” Nope, it doesn’t. Sinon, nous serions tous agiles. Cela ne se décrète pas. Comme l’a constaté John Shook, La manière la plus efficace de changer la culture, c’est de changer ce que font les gens.
5 :
“Without a deadline, the teams will never get anything done”.
C’est vrai, cf. loi de Parkinson. Ce ne sont pas les deadlines qu’il faut abolir. L’ennemi est ailleurs.
9 :
We continue to pursue planning, standardization, structure and control as risk reduction strategies.
C’est sans surprise quand on voit non seulement que les méthodes agiles ne sont pas une alternative suffisante mais aussi que ces méthodes contribuent à ce résultat.
Final thoughts […]
As such, 2022 will be a doubling-down year for me as I try to move organizations to a true outcome orientation. I will need to eradicate deadline-driven behavior, dependencies, and the word “resources.” My coaching will focus on bringing managers forward to lead the change.
Pour moi, c’est juste révoltant de lire ça.
Intervenant 2 :
Ah zut ! Je sors de la lecture de l’article en étant plutôt aligné avec l’auteur et je vois tes commentaires :pensif:
J’essaie de donner mon avis (vite fait) :
3. Qu’est-ce que tu entends par vecteurs ?
4. J’ai vu pas mal d’usages de Jira qui correspondent exactement à ce que décrit l’auteur. Jira, en tant que tel n’est pas le mal absolu. Il peut d’ailleurs être très pratique pour gérer son backlog. T’as tous les éléments nécessaires pour le prioriser, le rendre vivant, etc. Mais j’ai vu tellement de dérives où on se retrouve avec des specs fonctionnelles voire techniques détaillées dans un truc appelé “User Story”…
5. Je suis plus convaincu par les typologies de cost of delay de Reinerstein. Certains éléments ont besoin d’une deadline mais pas tous. Et encore une fois, j’ai vu tellement de fois des équipes d’abord s’engager sur une estimation (parce que la méthode le dit) et se focaliser ensuite uniquement sur cette estimation initiale en tant qu’engagement avec comme seule variable d’ajustement la qualité. Les gens se créent leurs propres deadlines et se font du mal.
9. Pirouette de ma part : les méthodes, “telles qu’appliquées” contribuent certainement à ce résultat. Mais je pense que l’agilité dans son esprit, est à l’opposé de ça. Après, je lâcherais volontier le mot “agilité” pour trouver des alternatives suffisantes…
Pour conclure sur l’article, j’ai vraiment l’impression dans mon expérience récente chez ce fameux leader français du e-commerce installé en région bordelaise d’avoir vu cocher tous les anti-patterns décrits ici…
Intervenant 1 :
3. Qu’est-ce que tu entends par vecteurs ?
Ceci : https://cynefin.io/wiki/Vector_theory_of_change
Présenté également ici : https://youtu.be/MsLmjoAp_Dg
Et là : https://medium.zenika.com/lapprentissage-une-perspective-d-anthro-complexit%C3%A9-6ec919278b99
4. J’ai vu pas mal d’usages de Jira qui correspondent exactement à ce que décrit l’auteur. Jira, en tant que tel n’est pas le mal absolu. Il peut d’ailleurs être très pratique pour gérer son backlog. T’as tous les éléments nécessaires pour le prioriser, le rendre vivant, etc. Mais j’ai vu tellement de dérives où on se retrouve avec des specs fonctionnelles voire techniques détaillées dans un truc appelé “User Story”…
Je suis d’accord avec ce constat du problème. Pour moi ça ne nous fait pas avancer vers la solution d’appeler JIRA un outil ou un processus et d’appeler les gens à se respecter et à humaniser leurs interactions.
5. Je suis plus convaincu par les typologies de cost of delay de Reinerstein. Certains éléments ont besoin d’une deadline mais pas tous. Et encore une fois, j’ai vu tellement de fois des équipes d’abord s’engager sur une estimation (parce que la méthode le dit) et se focaliser ensuite uniquement sur cette estimation initiale en tant qu’engagement avec comme seule variable d’ajustement la qualité. Les gens se créent leurs propres deadlines et se font du mal.
OK pour qu’il y ait des choses qui n’aient pas de deadline. Mais généralement, la loi de Parkinson s’applique. Là où on peut éventuellement se passer de deadline explicite c’est quand il y a de la motivation intrinsèque, auquel cas la ou les personnes qui font le travail se fixent leur propre deadline implicitement. Même dans ce cas, il faut veiller à ce que le mieux ne soit pas l’ennemi du bien.
Ptet un fil intéressant à tirer, mais je trouve que l’article ne propose pas une piste utile.
9. Pirouette de ma part : les méthodes, “telles qu’appliquées” contribuent certainement à ce résultat. Mais je pense que l’agilité dans son esprit, est à l’opposé de ça.
L’agilité dans son esprit n’est que ça : une vue de l’esprit. Ce n’est pas la réalité et ça ne se décrète pas. Si l’on doit attendre que tout le monde se convertisse à cet état d’esprit, on n’est pas prêt de se coucher, cela détruirait la résilience des équipes et c’est n’est pas éthique de forcer ce changement.
Les méthodes telles qu’appliquées sont le fruit des différentes cultures dans lesquelles l’agilité a été semée et les manières dont l’agilité a été définie, expliquée et enseignée. Si l’on veut changer ce résultat, ça ne sert à rien d’exhorter les gens à revenir aux sources. Il faut plutôt un réensauvagement de l’agilité.
