Des équipes AGILE ? Mais pourquoi ?

Tout le monde parle d’agilité, de SCRUM, de Kanban et de Lean Management de nos jours. Mais peu de gens comprennent vraiment de quoi il s’agit et encore moins des implications d’une transformation AGILE dans une organisation.

L’objectif de cet article est de vous aider à vous faire une image  de ce qu’est et de ce qu’impliquerait une transformation AGILE.
Pourquoi serait-il intéressant « d’agiliser » mes équipes ?
  1. Pour maximiser la production de valeur le plus rapidement possible en positionnant le client (ou son représentant) au centre des processus de développement.
  2. Permettre un changement de périmètre, à tout moment du projet, afin de réorienter la production, et, si nécessaire, être plus réactif.
  3. Améliorer la communication  entre toutes les parties prenantes d’un projet. Le manque de communication efficace est souvent la source des problèmes dans les projets.
  4. Livrer fréquemment. Dans certaines organisations, Amazon par exemple, les équipes techniques livrent en production des améliorations de façon quotidienne. Arriver à ce niveau d’agilité n’est pas aisé, mais sans AGILE, c’est tout simplement impossible.
  5. Mettre aux oubliettes les effets tunnels.
  6. Améliorer la qualité et respecter ses engagements (délais et coûts)
  7. Bénéficier d’indicateurs de pilotage probants et constamment mis à jour
  8. Responsabiliser les équipes de développement,  créer des conditions de travail agréables, entre autres, en leur permettant de travailler en mode projet  avec une charge constante (diminuer les pics de charges).
  9. Etc… Il ne manque pas de bonnes raisons pour justifier l’agilité !
Est-ce que l’agilité va réellement aider mes équipes à faire mieux, plus vite et dans une ambiance plus agréable ?

Attention ! Plusieurs connaissances, amie(s) et collègues me parlent du calvaire qu’ils vivent depuis qu’ils sont devenus AGILE : Peu importe que vous soyez développeur, lead technique, scrum master ou product owner, si la mise en œuvre de cette méthode a engendré plus de charge, c’est que vous n’êtes pas vraiment AGILE. Parole d’expert !

Avant d’affirmer que vous êtes agiles, prenez le temps de vérifier auprès d’un expert en lui parlant de vos processus et activités. En réalité, il y a plusieurs méthodes AGILE. Voici quelques-unes des plus répondues :

  • SCRUM est une méthodologie AGILE adaptée  pour des équipes de développement logiciel dans une perspective de création de produit.
  • Kanban est plus adaptée à des activités à forte dépendance techniques dans un contexte industrialisé et surtout à flux tendu.
  • SCRUMBAN est un mix des deux méthodologies qu’on peut appliquer dans des contextes particuliers impliquant des équipes mixtes.
  • Lean management permet « d’agiliser » la production d’un service ou d’une direction des systèmes d’information par exemple.
  • Lean startup est la dernière née des pratiques agiles destinée aux équipes marketing et/ou innovation pour le développement de produits/offres.
Il y a plus d’une dizaine de méthodologies dites AGILE. Il est important de comprendre les différences qui les caractérisent afin de pouvoir choisir celle qui est la plus adaptée à votre contexte particulier.
Est-il vrai qu’on ne rédige pas de spécifications lorsqu’on est AGILE ?

Un mythe, une mauvaise compréhension, voir un mensonge, consiste à dire que lorsqu’on  est agile, on ne rédige plus de spec. C’est totalement faux ! La documentation est toujours là. La forme et le cycle de production des documents changent, mais  ils ne disparaissent pas. Aucune personne expérimentée ou sensée n’oserait supprimer la documentation d’un projet quel que soit sa taille.

Les principes semblent faciles. Avons-nous réellement besoin d’un coach ou d’accompagnement pour déployer de l’agilité dans nos équipes ?
Bien que les préceptes AGILE soient assez simples en général, ils n’en demeurent pas moins complexes à mettre en œuvre. Il est question de changer des habitudes. Tout individu ayant eu à gérer un projet de changement sait à quel point gérer de l’humain et l’amener à changer ses habitudes peut être complexe.  Pour maximiser les chances de réussite d’un projet de transformation agile, il est non seulement conseillé de choisir la bonne méthode , mais il est également important de vous faire accompagner par un expert. Ceci dit, le rythme d’intervention de l’expert peut varier en fonction de la maturité des équipes en place.

À part introduire la gestion de valeur dans le projet, en quoi cette méthode est-elle différente des méthodes classiques finalement ?

Quels sont les paramètres qui définissent le triangle qualité ?

1. Le respect des coûts,
2. Le respect des délais
3. Le respect du périmètre.
La qualité d’un projet peut donc être pilotée via ces trois éléments. J’ai tendance à systématiquement ajouter la gestion des risques qui n’est pas prise en compte dans le triangle qualité. Dans les méthodologies dites traditionnelles (cycle en V par exemple – Waterfall), il est admis que seuls les délais et les coûts peuvent changer. Le périmètre lui ne peut et ne doit pas changer (respect des spécifications).
Des études démontrent que plus de 60% des fonctionnalités développées  sont peu ou pas utilisées (THE STANDISH GROUP – CHAOS Report). La théorie SCRUM propose donc de réviser ce paradigme en plaçant la production de valeur au centre des développements. Ainsi, contrairement aux méthodes classiques, dans un projet AGILE, seul le périmètre peut varier. Les délais et les coûts demeurent fixes. Pourquoi serait-il inimaginable de repousser le développement des fonctionnalités de moindre importance à une prochaine version ? Pas si catastrophique que ça si on y pense bien ! Cependant, ce principe ne fonctionne que si le propriétaire du produit (le marketing ou un représentant) maîtrise le besoin de ses clients et effectue un réel travail de valorisation des fonctionnalités à développer.

Une réflexion au sujet de « Des équipes AGILE ? Mais pourquoi ? »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.