Il semble évident que la mouvance Agile ne produit pas aujourd'hui les résultats et transformations majeures qui pourraient avoir lieu. Si les approches actuelles fonctionnaient réellement, des milliers d'organisations seraient déjà fonctionnelles et autonomes avec Agile.
Ce n'est clairement pas le cas.
On entend beaucoup de retour sur les modèles typiques d'échec. Des entreprises qui semblaient bien parties retournent petit à petit aux pratiques waterfall. Certaines emploient des accompagnateurs et dépensent des millions pour obtenir à peine 25 % à 30 % d'amélioration dans ce qu'elles mesurent !
Le développement logiciel à grand échelle est un projet très difficile. L'état d'esprit d'Agile et les principes, modèles et pratiques qui y sont liés peuvent grandement aider. Le problème est comment s'en servir. Ce qui est clair, c'est que peu de gens (voir personne) ne sait comment apporter une adoption durable d'Agile à grande échelle. Comment fait-on ? Qui sait comment faire ? En tant que communauté de consultants et accompagnateurs, nous n'avons pas tenu la promesse d'Agile faite à nos clients et au reste du monde. Nous sommes coincés.
Les pratiques sont typiquement mises en place comme une obligation. Prescrire des pratiques ne prend pas en compte ce que les gens veulent, ce qu'ils pensent ou ce qu'ils ressentent. La prescription réduit l'engagement et pousse des personnes créatives et intelligentes qui travaillent bien à "essayer", puis arrêter.
Le modèle suivant est généralement utilisé pour mettre en place les méthodes agiles, la plupart du temps après une petite période d'essai avez une équipe réduite :
- Une autorité dit "Nous allons tous faire de l'agile".
- L'autorité dit que telle ou telle pratique sera utilisée, comme Scrum, Kanban et autres pratiques, méthodes ou frameworks. Le message est simple, c'est non négociable.
- L'autorité sélectionne un accompagnateur en fonction de son expérience avec les pratiques choisies, typiquement Scrum. L'accompagnateur est imposé aux équipes, tout comme les pratiques agiles prescrites.
- Les personnes qui travaillent sont poussées au désengagement par une perte du contrôle, une perte du sentiment d'inclusion et d'appartenance. Les nouvelles règles du jeu sont vagues et la participation n'est clairement pas facultative. L'adoption d'agile n'est pas un jeu très amusant parce que celui-ci n'est pas clair et qu'il est impossible d'en sortir.
La participation lors de l'adoption d'Agile n'est généralement pas une invitation mais une obligation et une prescription. C'est la recette parfaite pour une adoption d'Agile ratée. Souvenez-vous que l'une des hypothèses d'Open Agile Adoption est que l'obligation réduit l'engagement alors que l'invitation et une participation facultative le renforcent. Souvenez-vous également qu'une autre hypothèse de cette technique est que l'engagement est essentiel pour une adoption d'Agile rapide et durable.
Les personnes qui écrivent des logiciels ont généralement les caractéristiques suivantes, surtout comparées au reste de la population :
- Un haut niveau d'intelligence
- Une tendance à l'introversion
- Une idée d'eux-mêmes qui inclut les points suivants :
- "Je suis payé pour résoudre des problèmes"
- "Je suis intelligent et créatif"
- "Je suis payé pour mon expertise informatique"
Une adoption forcée d'Agile a tendance à repousser ces personnes intelligentes, qui résolvent les problèmes et font le travail. Une raison pourrait être que ces personnes aiment résoudre les problèmes, littéralement, y compris les "problèmes de processus", par exemple "comment mettre en place Agile dans notre entreprise". Comme ces personnes sont introverties, si on ne leur demande pas ce qu'elles pensent, une chose terrible se produit : elles ne nous disent rien.
Le plus souvent, ces mêmes personnes qui travaillent et résolvent les problèmes ont une opinion ou une idée qui peut aider. En prescrivant une obligation, sans demander leur avis, nous perdons une opportunité d'obtenir leur aide et risquons de surcroît un ressentiment prononcé. Tout pour un résultat négatif. Nous refusons ce qui pourrait apporter les meilleures idées et manquons une opportunité de renforcer l'engagement.
Pour De Meilleures Adoptions d'Agile
Open Agile Adoption™ est une technique basée sur l'invitation et non l'obligation. Une des hypothèses d'Open Agile Adoption est que l'obligation réduit l'engagement alors que l'invitation et une participation facultative le renforcent. Une autre hypothèse d'Open Agile Adoption est que l'engagement est essentiel pour une adoption rapide et durable d'Agile, et qu'un Open Space a tendance à inviter l'engagement et par conséquent le renforce.
Plutôt que d'imposer une pratique Agile spécifique, Open Agile Adoption utilise le modèle suivant, basé sur l'invitation :
- Expliquer l'intérêt business de passer à Agile. Expliquer les challenges auxquels le business fait face en termes de compétition, de pression sur les prix, de produits obsolètes, etc.
- Indiquer clairement que l'entreprise prend une direction Agile et expliquer que cette direction est sûre.
- Inviter tout le monde à participer à l'écriture de l'histoire Agile. Communiquer sur le fait que les dirigeants n'ont pas toutes les réponses et cherchent à rassembler les meilleures idées pour rendre la migration vers Agile naturelle, authentique, rapide et durable.
- Indiquer bien que tout ce qui est tenté comme pratique Agile est une expérience, est optionnel et sera analysé ensuite ; rien n'est gravé dans le marbre. Si l'organisation essaie par exemple Scrum, c'est une expérimentation et ce sera analysé ensuite. Si une pratique toute faite comme Scrum ne peut pas être adaptée au besoin, elle sera rejetée et une autre sera essayée. Il se peut que l'on mette en place nos propres pratiques en utilisant le Manifeste Agile pour nous guider.
En le faisant de cette façon, les équipes se sentent impliquées et gardent le sentiment de contrôle et d'appartenance.
La plupart des problèmes d'adoption d'Agile sont causés par les dynamiques sociales, pas les pratiques. Concrètement, les pratiques doivent s'adapter aux réalités sociologiques. Les Story Points sont généralement la première pratique "proposée" dans les adoptions obligatoires d'Agile. Ce n'est pas l'utilisation des story points qui est problématique, c'est la réalité sociologique qui dirige l'action.
L'une des hypothèses d'Open Agile Adoption est que l'introduction d'Agile peut être traumatisant pour les participants, les poussant à se désengager, voire à résister à l'effort d'adoption d'Agile. Pour les managers et les architectes systèmes, les inquiétudes liées à Agile sont nombreuses. Imposer des pratiques agiles amplifie ces inquiétudes et provoque le désengagement suivi de ressentiment.
Une manière de gérer le stress et les inquiétudes créées par l'adoption d'Agile est de se tourner vers l'anthropologie culturelle pour trouver des pistes d'amélioration. Tous les types de cultures, quelle que soit leur localisation, ont mis en place des rites de passage pour gérer le stress dû à la transition. Passer à Agile est de toute évidence une importante transition.
Open Agile Adoption tire profit de ce constat et crée un rite de passage qui commence par des réunions Open Space. Ce rite est une sorte de jeu. Plutôt qu'une obligation, c'est une invitation à jouer le jeu. Au centre de ce rite de passage, on trouve le principe d'expérimenter pour apprendre. Les gens jouent avec Agile. Finalement, l'apprentissage est récolté et intégré par l'organisation : encore une fois, en Open Space.
La Terminologie d'Open Agile Adoption
Les termes et mots suivants sont utilisés dans Open Agile Adoption, prenez donc le temps de lire ces définitions :
Seuil-limite : (Liminality) Un état de stress dû à une transition. L'adoption d'Agile crée un seuil-limite.
Rite de passage : (Passage rite) Un rituel qui permet de gérer le stress dû au changement culturel. Les rites de passage aident à gérer le seuil-limite crée durant les changements de statuts.
Communitas : L'esprit de communauté. Open Agile Adoption crée ce sentiment d'appartenance et d'inclusion.
Maître de Cérémonies : Un rôle essentiel dans le rite de passage. Celui ou celle qui prend le rôle de Maître de Cérémonies durant un rite de passage agit comme un arbitre, un gardien des "règles du jeu".
Chapitre d'apprentissage : (Chapter of learning) En Open Agile Adoption, cela représente une unité claire d'apprentissage organisationnel avec un début, un milieu et une fin. Les Chapitres d'Apprentissage prennent place entre chaque réunion Open Space.
Open Space : Un format de réunion avec une structure et des éléments spécifiques. Les réunions Open Space périodiques forment un aspect essentiel, au cœur d'Open Agile Adoption.
Compte-Rendus d'Open Space : (Open Space Proceedings) Documentation des événements ayant lieu durant une réunion Open Space. Les compte-rendus contiennent un résumé des événements sous forme de mots, de diagrammes et d'images.
Sponsor d'Open Space : Une personne au sein de l'organisation avec assez de pouvoir pour mettre en place une réunion Open Space d'une journée.
Facilitateur d'Open Space : Dans le format de réunion Open Space, une personne autorisée par le Sponsor à assister au déroulement de la réunion. Le facilitateur aide à créer une atmosphère d'ouverture et à "garder l'espace ouvert" pendant toute la réunion.
Accompagnateur ou "Coach Agile" : Une personne engagée par l'organisation pour accompagner la mise en place des méthodes et pratiques agiles.
Début d'Open Space : Dans Open Agile Adoption, une réunion Open Space qui commence ou ouvre un Chapitre d'Apprentissage.
Fin d'Open Space : Dans Open Agile Adoption, une réunion Open Space qui se termine et ferme un Chapitre d'Apprentissage.
Monter en Niveau : (Leveling Up) Dans la communauté des joueurs, le terme est utilisé pour décrire un changement de niveau ou de statut dans un jeu. "Monter en Niveau" signifie progresser, passer à un niveau de compétence supérieur.
En utilisant cette terminologie, nous pouvons maintenant examiner les concepts et facilités de l'approche Open Agile Adoption que nous aborderons dans le prochain article.
À Propos De l'Auteur
Daniel Mezick est un Consultant en management, auteur et organisateur de communauté. Il a créé la communauté Agile Boston. Il est à l'origine de Open Agile Adoption, une technique pour mettre Agile en place rapidement et durablement en entreprise. Daniel est également auteur de THE CULTURE GAME, un livre décrivant seize modèles comportementaux de groupe qui aident à rendre une équipe plus intelligente. Ce livre se base sur cinq années d'expérience d'accompagnement avec 119 équipes agiles dans 25 organisations différentes. Daniel compte parmi ses clients Zappos Insights, CIGNA, SIEMENS Healthcare, l'Université de Harvard et de nombreuses entreprises plus petites. Pour en savoir plus et contacter Daniel, rendez-vous sur www.DanielMezick.com.