Scrum et XP depuis les Tranchées

Nous mettons à jour le tableau des tâches pendant la mêlée quotidienne. Pendant que chaque personne décrit ce qu'elle a fait hier et ce qu'elle va faire aujourd'hui, elle déplace les post-its sur le tableau des tâches. Quand elle décrit une tâche non planifiée, elle colle un post-it pour ça. Quand la personne met à jour son estimation de temps, elle écrit la nouvelle estimation sur le post-it et raye l'ancienne valeur. Parfois le Scrum Master s'occupe des post-its pendant que les personnes parlent.

Certaines équipes adoptent comme politique de mettre à jour le tableau des tâches avant chaque mêlée. Cela fonctionne aussi. Choisissez juste une politique est tenez-vous y.

Indépendamment du format de votre backlog de sprint, essayez d'impliquer toute l'équipe en gardant le backlog de sprint à jour. Nous avons essayé des sprints où le Scrum Master est le seul à maintenir le backlog de sprint et où il doit faire le tour chaque jour et demander aux gens leurs estimations de reste à faire. Les inconvénients de cette méthode :

• Le Scrum master passe trop de temps à s'occuper des tâches administratives, au lieu de supporter l'équipe et d'enlever des obstacles.
• Les membres de l'équipe ne sont pas au courant du statut du sprint, puisqu'ils n'ont pas besoin de prêter attention au backlog de sprint. Ce manque de feedback réduit l'agilité globale et la concentration de l'équipe.

Si le backlog de sprint est bien conçu il devrait être aussi facile pour chaque membre de le mettre à jour lui-même.

Immédiatement après la mêlée quotidienne, quelqu'un additionne toutes les estimations de temps (en ignorant celles de la colonne «terminé» bien sûr) et marque un nouveau point sur la courbe du reste à faire du sprint.

Certaines équipes ont un pot pour les pièces et billets. Quand vous êtes en retard, même si c'est juste une minute, vous ajoutez un montant fixe au pot. Aucune question n'est posée. Même si vous appelez avant la réunion pour prévenir que vous serez en retard, vous devrez quand même payer.

Vous échappez à la sentence seulement si vous avez une bonne excuse comme un rendez-vous chez le médecin ou votre propre mariage ou quelque chose dans le genre.

L'argent dans le pot est utilisé pour les évènements collectifs. Pour acheter des hamburgers quand nous passons des nuits à jouer par exemple :o)

Ca marche bien. Mais c'est nécessaire seulement pour les équipes où les gens sont souvent en retard. Certaines équipes n'ont pas besoin de ce type de pratique.

Ce n'est pas rare pour quelqu'un de dire « Hier j'ai fait bla bla bla, mais aujourd'hui je n'ai pas la moindre idée de ce que je peux réaliser » (hé ce dernier vers rime). Maintenant quoi ?

Disons que Joe et Lisa sont ceux qui ne savent pas quoi faire aujourd'hui.

Si je suis Scrum master je passe et laisse la personne suivante parler, mais je note qui n'a rien à faire. Après que tout le monde ait parlé, je repasse sur le tableau des tâches avec toute l'équipe, de haut en bas, je vérifie que tout est synchro, que tout le monde sait ce que chaque élément signifie, etc. J'invite les gens à rajouter des post-its. Puis je reviens vers ceux qui ne savaient pas quoi faire «maintenant que nous avons passé en revue le tableau des tâches, avez-vous une idée de ce que vous pourriez faire aujourd'hui»? Avec un peu de chance ils ont une idée.

Sinon, je considère s'il n'y a pas une opportunité de programmation en binôme ici. Disons que Niklas est en train d'implémenter l'IHM d'admin du back-office aujourd'hui. Dans ce cas je suggère poliment que peut-être Joe ou Lisa pourrait programmer en binôme avec Niklas sur ce sujet. Ca fonctionne en général.

Et si ça ne fonctionne pas, voici l'astuce suivante.

• Scrum master : « OK, qui veut nous montrer la version beta de l'application ? » (en supposant que c'est le but de l'itération)
• L'équipe : silence confus
• Scrum master : « Nous ne sommes pas prêts ? »
• L'équipe : « hmm... non »
• Scrum master : « Ah bon. Pourquoi ? Qu'est-ce qu'il reste à faire ? »
• L'équipe : « Ben nous n'avons même pas de serveur de test pour la lancer, et le script de build est cassé. »
• Scrum master : « Aha. » (ajoutez deux post-its sur le mur des tâches). « Joe et Lisa, comment pouvez-vous nous aider aujourd'hui ? »
• Joe : « Hmm.... au hasard je vais essayer de trouver un serveur de test quelque part ».
• Lisa : « ... et je vais essayer de réparer ce script de build ».

Si vous avez de la chance, quelqu'un va effectivement faire la démo de la version beta que vous avez demandée. Super ! Vous avez atteint le but de votre sprint. Mais que faire si vous êtes au milieu du sprint ? Facile. Félicitez l'équipe pour le travail accompli, prenez une ou deux histoires de la section «à venir» en bas à droite du tableau des tâches, et déplacez-les vers la colonne « non réservé ». Puis refaites la mêlée quotidienne. Avertissez le directeur de produit que vous avez ajouté des éléments au sprint.

Mais que faire si vous n'avez atteint l'objectif du sprint et que Joe et Lista continuent de refuser de se rendre utile. Je considère habituellement l'une des stratégies suivantes (aucune d'elle n'est élégante, mais il s'agit d'un dernier recours) :

• La honte : « Bien si tu n'as aucune idée de comment aider l'équipe, je suggère que tu rentres chez toi, ou que tu lises un bouquin ou quelque chose d'autre. Ou assied-toi jusqu'à ce quelqu'un t'appelle pour l'aider. »
• Vieille école : Assignez leur simplement une tâche.
• Pression collective : Dîtes « prenez tout votre temps Joe et Lisa, nous resterons là jusque vous trouviez quelque chose à faire qui peut nous aider à atteindre l'objectif »
• Servitude : Dîtes « Bien, vous pouvez aider l'équipe indirectement en étant les majordomes aujourd'hui. Faites le café, donnez des massages, nettoyez les poubelles, préparez le déjeuner, et tout ce que nous pourrions demander durant la journée. » Vous pourriez être surpris par la vitesse à laquelle Joe et Lisa réussissent à trouver des tâches techniques utiles :o)

Si une personne vous force fréquemment à aller si loin, vous devriez probablement prendre cette personne à part et faire du coaching poussé. Si le problème persiste, vous devez évaluer si cette personne est importante pour votre équipe ou pas.

Si elle n'est pas importante, essayez de la dégager de votre équipe.

Si elle est importante, alors essayez de la mettre en binôme avec quelqu'un qui sera son « berger ». Joe est peut-être un bon développeur ou architecte, c'est juste qu'il préfère vraiment que quelqu'un d'autre lui dise quoi faire. Bien. Donnez à Niklas la responsabilité d'être le berger permanent de Joe. Ou prenez cette responsabilité vous-même. Si Joe est assez important pour votre équipe l'effort sera moindre. Nous avons eu des cas comme ça et ça marchait plus ou moins bien.