Kata Agile - Atelier du 21 avril 2022

Organisé par Scrumlife

Référence: https://scrumlife.tv/katagile le lien contient notamment un ensemble d’exercices pour aller plus loin.

Objectif

Apprendre à

• savoir gérer ces situations,
• être prêt à tout,
• prendre conscience de ses possibilités, et
• vaincre le syndrome de l’imposteur.

Un jeu de rôle

L’équipe est pilotée par un scrum master, les autres seront là pour mettre des bâtons dans les roues.

Le groupe (de 5 à 6 personnes) doit se mettre d’accord sur le cadre (rétro, daily, à la machine à café; type d’entreprise; domaine d’activité; etc.). Il doit mettre en scène les rôles (et le Scrum Master va introduire).

L’exercice dure environ 20 minutes, élaboration du cadre inclut.

Il se termine par un débrief sur ce qui aura été apprit, il faut donc prendre des notes au cours de l’exercice.

Le cadre choisit

Il s’agit du cadre choisit pour notre équipe de 6 personnes (sur environ 30 personnes actives dans le groupe, en tout), chaque groupe ayant choisit son propre cadre pour l’exercice.

Nous sommes parti sur une PME, développant du Cloud, souhaite mettre en place une offre Function as a Service par interface web.

Le patron a “recadré” le Scrum Master en lui expliquant qu’une interface web, c’est nul, on veut de l’API.

En plus du rôle de Scrum Master, nous avons rapidement ajouté un Product Owner et des développeurs (dont le développeur web, fort marri de la réaction du patron… Le Scrum Master a tenté de le rassurer en lui proposant de développer l’API sur la base de technos comme le Node JS).

Solutions retenues

Les membres de l’équipe étaient réticent à revoir la stratégie de l’équipe. Néanmoins, elle était d’accord pour mettre en place des démos à chaque fin de sprint. Cependant, nous étions assez d’accord sur la difficulté à obtenir le droit d’impliquer directement les clients (dans le contexte de notre entreprise).

• S’aider du support pour remplacer les clients si on ne peut pas les impliquer directement.
• Travailler la communication avec le support, plutôt que d’échanger uniquement via des tickets.
• Mettre en place un MVP pour le soumettre au support lors du sprint review / démo.
• Essayer de récupérer de l’existant.
• Planifier une réunion pour définir les calls et commencer à construire la nouvelle solution.

Feedbacks

le Scrum Master propose des solutions pour essayer de faire avancer les choses.

L’exercice a mis en relief la difficulté d’avancer contre le système, face à une équipe qui va perdre 6 mois de travail.

Parmis les qualités importantes :

• Rester calme, être patient, etc.
• Faire preuve d’empathie.

Image de la bataille navale : au lieu d’envoyer toutes les torpilles et de constater le résultat à la fin, observer à chaque torpille, aka itération.

Qui va aller chercher des ressources ? ça dépend du besoin / de la posture des gens. Si l’enjeu est trop important, plutôt le Scrum Master, sinon, on peut avoir quelqu’un de l’équipe faisant la démarche. Utiliser la sprint review pour communiquer sur les besoins de l’équipe.

Le Scrum Master va faire le constat, puis devra prendre en compte et récupérer les pistes proposées par l’équipe.

Ne pas hésiter à présenter les faits, communiquer, pour faire réagir l’équipe sur les problèmes de l’approche actuelle, et inciter à évoluer.

Capter l’attention et obtenir l’avis des développeurs qui sont prêt à s’impliquer au niveau produit.

Voir aussi où on en est par rapport au cycle de vie du produit (début, évolution, “vache à lait”), quelle est la prise de risque impliquée par le(s) changement(s).

Attention à l’impact de la pression : ce n’est pas parce que la situation est catastrophique qu’il faut passer plus (trop) de temps en réunion.

L’avantage des sprints (court) : Fail Fast -> plus vite on voit ce qui ne va pas, plus vite on peut ajuster le tir.