Commencer petit pour mettre en œuvre un grand changement est presque toujours une bonne idée… et le mot « presque » y tient une grande importance.

A pilot project is not always the best way to start your agile journey

https://kbondale.wordpress.com/2021/01/24/a-pilot-project-is-not-always-the-best-way-to-start-your-agile-journey/ par Kiron Bondale

Beaucoup d’entre nous s’accorderaient sur le fait que si vous essayez de mettre en œuvre un grand changement, commencez petit. De même qu’il est plus facile d’avaler une petite pilule qu’une énorme, la capacité d’adopter et de supporter le changement est souvent plus simple quand le changement implique des pas de fourmi.

Cette approche des petits pas/changements progressifs s’applique aussi à Agile.

Par exemple, les expériences d’amélioration qu’une équipe identifie pendant une rétrospective de sprint devraient être petites pour fournir des retours rapides sur si vraiment cela vaut la peine d’aller plus loin.

Mais quand j’ai lu un récent article HBR de Ron Ashkenas et Nadim Matta sur les challenges à reproduire en plus grand un projet pilote réussi, cela m’a rappelé que ce principe de commencer petit pourrait ne pas fonctionner avec des transformations Agiles.

Dans l’article, les auteurs listent quelques défis à appliquer avec succès les leçons d’un projet pilote sur un plus grand contexte

• La résistance de la masse des parties prenantes auxquelles on demande de travailler de façon différente alors que la cible des personnes impactées pour le pilote est probablement plus réceptive aux changements proposés. C’est le problème de “franchissement de l’abîme”.
• Éviter des éléments bloqueurs dans l’organisation ou des obstacles est relativement simple dans le contexte d’un projet unique, mais cela devient exponentiellement plus difficile quand le périmètre des changements augmente.
• La difficulté à essayer de faire appliquer et évoluer des pratiques et des apprentissages du projet pilote aux contextes variés de multiples projets différents.

À cette liste, j’ajouterais encore un défi.

La première source d’incertitude de livraison dans la plupart des projets basés sur la connaissance est la prévisibilité de disponibilité des bonnes personnes avec les bonnes compétences et au bon moment. Dans un pilote, il est possible d’améliorer la dotation en personnel en notre faveur en allant extraire des gens compétents de leurs rôles normaux pour travailler sur le projet.

Si nous ne remplaçons pas ce personnel avec des ressources temporaires, cela a des impacts sur la capacité de chacune des équipes dont ils faisaient partie et ça n’améliorent probablement pas nos relations avec les leaders de ces équipes.

Mais encore pire, quand le projet pilote est fini et que nous commençons à nous congratuler des résultats, la raison principale n’est pas parce que nous étions Agiles, mais parce que nous avons permis à des gens compétents de se concentrer sur un travail précis du projet plutôt que les garder dans leur niveau habituel de multitâches

Quand nous essayons ensuite d’étendre notre approche sur de multiples projets, les résultats sont moins prometteurs parce que nous n’avons pas adressé combien ce travail habituel simultané sur de multiples tâches consomme de temps et de ressources.

---

Cela ne devrait pas vous décourager de lancer une approche projet pilote dans votre transformation Agile

Cependant, avant de faire la promotion des leçons de ce projet pilote, abordez d’abord les questions fondamentales de la gestion du travail si vous voulez réaliser des bénéfices durables.