Kata-strophe, ou comment gérer les contre-temps durant un sprint

En effet, les quatre teams (De Palma, Joubert, Molko et May) ont dû réaliser un projet simple : un formulaire où des futurs candidats peuvent postuler. Features listées :

• Feature 0 : Mise en place du projet
• Feature 1 : Intégration simple du formulaire, avec respect de la maquette
• Feature 3: Mise à jour de l’image par rapport à la liste de genres Pour les plus rapides, des fonctionnalités optionnelles étaient proposées :
• Feature 4 : Sauvegarde des inscriptions en local
• Feature 5 : Affichage d’une page avec l’ensemble des inscrits À ces développements étaient demandés de gérer les éventuels imprévus et de rester attentifs à leurs e-mails pro et leur téléphone (au cas où…)

Les 70 minutes du kata étaient rythmées de la manière suivante : 5 journées découpées en :

• une matinée de travail de 5 minutes,
• une pause-déjeuner de 2 min,
• un après-midi de travail de 5 minutes et
• une pause de fin de journée de 2 minutes. Les interactions entre les équipes étaient autorisées, mais chacune d’entre elles devaient réaliser les fonctionnalités.

La semaine commence et au bout de quelques minutes, les employeurs de Brian Industries viennent distraire les équipes en racontant leur weekend, raconter des blagues… Tout ce qu’il y a de plus normal.

Puis, petit à petit, certaines équipent reçoivent des mails, afin de signaler des bugs, des idées du client, des demandes d’estimations… Le but du Kata était de voir comment gérer les éléments perturbateurs (e-mails, appels, bug…) et comment gérer les e-mails ou appels reçus sur du temps de pause.

À la suite de cet exercice, beaucoup de réactions et d’actions en sont ressorties : des bonnes surprises mais aussi des éléments à améliorer.

En effet, lorsqu’un e-mail était reçu durant les périodes de travail, les différentes équipes ont échangé entre elles afin de déterminer qui allait prendre cette charge inattendue.

De plus, les demandes d’évolutions ont reçu une réponse proposant une estimation et la réalisation de celles-ci dans un sprint futur.

Néanmoins, certains points demandent encore un peu de travail :

Premièrement, un bug en production a été pris en charge, sans prévenir le rapporteur. Celui-ci n’a été notifié qu’au moment du déploiement du fix en production. Il aurait été préférable d’accuser réception de l’anomalie, afin d’informer et rassurer le client, surtout si la correction est plus longue que prévue.

Deuxièmement, un bug en pré-production a été pris en charge, alors qu’il n’était pas prioritaire. L’équipe a jugé bon de le gérer immédiatement, le client ayant une démo avec ses investisseurs de programmée. Ceci ayant un impact direct sur le sprint en cours, les développeurs ont pensé à prévenir le client du projet en cours de réalisation pour l’informer que ses features ne seraient pas toutes livrées.

Le dernier point nécessitant encore un peu de travail reste le respect du temps de pause. En effet, le bon respect du rythme de travail permet une meilleure efficacité. Il est donc important de respecter les temps de pause pour améliorer sa concentration. Certains développeurs ont traités leurs e-mails professionnels et d’autres ont même développé durant ces moments pour compenser le retard. Cela empêche une véritable coupure et, à long terme, impactera forcement la qualité de son travail (ainsi que sa vie privée).

Les bonnes pratiques concernant la gestion des contacts avec les clients doivent être encore peaufinées, mais à la suite du Kata, différentes philosophies se sont présentées et même si elles restent bonnes, il nous reste à déterminer laquelle suivre afin de garder une cohérence au sein de l’équipe.

En tout cas les réactions et les échanges entre les équipes ont été très instructifs et ont permis d’avancer sur l’optimisation de la gestion de son temps.