Un exemple extrait d’une situation concrète : une formation sur deux nouveautés pour des ressources d’équipes Agile :

1. L’implémentation d’une partie de SAFe (l’incrément de programme) au « dessus » d’un Scrum déjà en place;
2. L’utilisation de JIRA Agile pour la gestion des Epics, User Story, tâches de développement… En remplacement d’un autre système.

Le contexte :

• Équipes habituées au framework de la méthode Scrum (itération de 3 semaines), mais pas à SAFe;
• Mise en place d’un train de livraison et des incréments de programme (6 itérations de 2 semaines + 1 semaine de transition entre deux incréments);
• Mise en place de JIRA Agile pour gérer les artifacts des itérations (carnet de produit, carnet de sprint, User story, tâches), la réédition de compte et la partie programme (carnet de programme, Epic).

Les objectifs :

• Recevoir du feedback sur l’implémentation de la méthode avec une équipe crash-test, avant le déploiement à toutes les équipes;
• Vérifier que l’implémentation dans JIRA répond aux besoins, identifier les manques sur l’implémentation comme sur la gestion du changement;
• Former les participants sur le train de livraison, identifier les savoirs déjà présents et ceux à renforcer;
• Avec l’ajout du hasard : mesurer la capacité des participants à faire face à des situations non-planifiées.
  

La formation permet de simuler 2 incréments de programme de 3 itérations chacun (donc 6 itérations en tout + une transition d’un incrément à l’autre) en l’espace de 2h, alors que normalement il faudrait 13 semaines…

Le déroulement :

• Les participants forment deux équipes (ou plus) et se répartissent les rôles : Scrum Master, product owner, développeur;
• Chacun dispose d’un poste avec un accès à JIRA (un environnement de test avec les données/configurations nécessaires);
• À tour de rôle, les participants réalisent une action sur JIRA en la commentant à voix haute* pour que tout le monde puisse suivre. Une action, c’est par exemple :
  • Découper un Epic en User Story;
  • Déplacer une tache de « prêt » à « en cours »;
  • Terminer le sprint;
  • Changer l’affectation d’une carte.
• Les actions dépendent de la phase dans laquelle est le train de livraison :
  • Répartition des Epics (objectifs de l’incrément) entre les équipes;
  • Découpage des Epics en User Story lors de la planification du program increment;
  • Découpage des User Story en tâches lors de la planification de l’itération;
  • Avancement des tâches lors de l’itération;
  • Clôture d’une itération et passage à la suivante;
  • Clôture d’un incrément de programme et passage au suivant.

L’ajout du hasard

À chaque tour, dans une itération, le participant commence par lancer un dé à six faces avec comme règles :

• Nombre de 1 à 3 : rien
• Nombre de 4 à 6 : prendre une « carte évènement »

Bref, une chance sur deux d’avoir à faire face à l’inattendu. Il est conseillé de faire varier ces règles en fonction du nombre de personnes, du tempo de la formation, du nombre d’événements disponibles.

Les événements peuvent être divers et portent bien sûr sur le sujet de la formation… Voici des exemples dans le contexte de cet atelier :

• Votre Scrum Master sera absent le jour de la fin du sprint en cours. Savez-vous comment terminer le sprint dans JIRA ?
• Un membre de l’équipe est absent pour le reste de l’itération, il faut distribuer ses tâches en cours;
• Un membre de l’équipe est absent pour le reste de l’incrément de programme, mesurez l’impact sur votre objectif d’incrément;
• Un User Story est plus important qu’envisagé, refaites la planification pendant l’itération. Est-ce qu’il y a un impact sur l’objectif de l’incrément de programme ?
• Un User Story est bloqué, comment le signaler aux autres équipes avec JIRA ?
• L’un de vos objectifs d’incrément de programme a une dépendance imprévue avec l’autre équipe, comment réagissez-vous ?

Ici, les événements permettent de solliciter l’Agilité des participants sur un exercice à priori « facile » et sans difficulté (bouger des cartes dans JIRA) et de déclencher des apprentissages sur des façons de s’adapter à l’imprévu.

Les événements peuvent également permettre de vérifier si les participants ont les réflexes attendus sur des pré-requis. Par exemple, un User Story bloqué peut déclencher des questions et le Scrum Master peut jouer un rôle pour débloquer le User Story. Dans ce cas, les cartes peuvent être associées à une sorte de « réponse attendue » (Ex: l’organisation voudrait retirer un développeur dans votre équipe pour le reste de l’itération. Réflexe attendu : Si le Scrum Master joue son rôle, ça s’annule. Sinon, un développeur en moins).

En fonction, la réponse des participants peut être discutée en fin de jeu, dans le cadre d’une phase de retour sur la formation et ouvrir la porte à un complément d’information.

L’ajout du hasard permet de dynamiser les ateliers basés sur la répétition de séquence du même type. L’attention qui est portée dans ce cadre plus ludique est potentiellement plus grande que dans un atelier « linéaire », et donc, l’efficacité de l’atelier n’en sera que meilleure !

Dans le cadre de la mise en œuvre d’une nouvelle façon de faire, cela permet également de confronter la méthode à la réalité des réponses des participants plus rapidement, et donc d’apprendre et d’adapter plus rapidement.

*idéalement l’écran de chaque participant est affichable à tous à tour de rôle