Le Rocket Planning: 3 heures pour un Sprint Planning efficace et engageant

Surprise ! il y a quelques mois, je reçois un mail d’invitation d’une équipe (en demande de coach agile, 😊 ) pour participer, ou plutôt observer leur Sprint Planning. 1 heure pour planifier un Sprint de 3 semaines. Rires intérieurs.

Mais je n’étais pas préparé au deuxième effet Kiss Kool ! Le Scrum Master et l’équipe de développement. Pas de Product Owner ! Je pose naturellement la question aux participants. Réponse : « on nous a dit que le Product Owner ne doit pas participer au Sprint Planning ». Au final une Sprint Backlog définit par le Product Owner. Aucune explication des User Stories et un Planning Poker. Malheureusement, ce ne fut pas la seule fois. J’ai même coaché une équipe qui avait complètement supprimer cette cérémonie.

Le Sprint Planning en 1 dessin

Lors d’une formation sur les fondamentaux de l’Agilité, j’ai réalisé ce dessin pour expliquer le déroulé d’un Sprint Planning.

Sprint Planning

Pourquoi ne retenir alors que le moment du planning Poker ?

Lire la suite

Gérer les demandes des clients en cours d’itération

Engagement

Quand on développe en utilisant les méthodes agiles, dans le cas de notre équipe, en SCRUM, on s’engage sur des résultats via le contenu des sprints.

usain-bolt

Ceux-ci permettent de cadrer les développements, mais également de savoir sur quoi l’équipe peut s’engager.

Sauf qu’il y a forcément de l’imprévu, soit les tâches du sprint sont plus complexes que prévues, soit il y a des soucis dans l’équipe, soit il y a d’autres imprévus, comme des demandes clientes, qui eux n’ont pas leurs besoins qui sont rythmés sur le sprint, mais sont présents au jour le jour.

Lire la suite

Et si vous essayiez Scrumban ?

Chaque année, je m’éloigne un peu plus du Scrum traditionnel. J’observe un décalage entre certaines pratiques et les attentes des équipes que j’accompagne. Je me questionne sur certains concepts comme l’estimation, la notion de sprint, la priorisation, etc. J’ai trouvé dans Kanban d’excellentes idées qui ont altéré ma manière de pratiquer Scrum. De plus en plus de personnes se tournent vers Scrumban, une évolution de Scrum, qui combine le meilleur de Scrum et Kanban. Depuis deux ans, j’ai moi aussi franchi le pas et aide des équipes à s’approprier cette approche. Voici comment elles s’essaient à Scrumban. Lire la suite

Le Time To Market, un bon indicateur pour une transformation agile ?

J’ai très souvent lu ou entendu que l’agilité permettait d’avoir un meilleur Time To Market (TTM) que les traditionnelles méthodes orientées cycles en V. C’est un bon argument commercial auquel les décideurs peuvent être sensibles. C’est aussi quelque chose que je crois dans le sens où l’agilité nous donne des clés pour livrer rapidement et fréquemment de la valeur aux clients. Une transformation agile est souvent motivée par une amélioration du TTM. Dans ce cas, comment peut-on mesurer la progression vers cet objectif, peut-on considérer le TTM comme indicateur à revoir régulièrement pour vérifier la distance à la cible? Pas si simple.

12239377734_ee77ec423e

Lire la suite

Vers une entreprise plus agile…

1280px-Corey_vs_Ivan_in_2008
http://fr.wikipedia.org/wiki/Basket-ball#mediaviewer/Fichier:Corey_vs_Ivan_in_2008.jpg

De quoi parle-t-on ?

A ma droite, des décideurs ou des managers souhaitant rendre leur entreprise ou leurs équipes plus agiles. L’agilité attendue correspond à un vague mélange de flexibilité, de réactivité et d’amélioration de la productivité.

A ma gauche, des agilistes qui fondent leur démarche sur le manifeste agile publié en 2001 et la mette en pratique principalement au travers de Scrum. Quasi-exclusivement issus du milieu informatique, ils ont souvent fait leurs armes comme développeurs ou chefs de projets.

Pour limiter les risques d’incompréhension, lorsque les premiers vont faire appel aux seconds, il faudrait commencer par mieux définir ce que l’on entend par agilité, tellement le terme est galvaudé. Même les voitures sont agiles en 2014 !

Visuel-Twingo-TF12-tt-width-668-height-325-attachment_id-7478-crop-1

Lire la suite

Le Daily Meeting – les post-it et le tableau

burndownchart
Henrik Kniberg‘s source “Scrum and XP from the Trenches”.

L’équipe fixe ses propres règles, mais voici les nôtres :

 

  • Un post-it passe dans la case « en cours » quand la personne qui prend la tâche en charge démarre le travail; On ne « réserve » pas une pile de post-it pour la journée.
  • Un post-it passe dans la colonne « fait » quand on n’a plus à revenir sur cette tâche dans le contexte du sprint.
  • On peut choisir de mettre les post-it des tâches terminées en cours de journée à cheval sur les deux colonnes « en cours » et « fait ». Ainsi, au moment du daily on déplacera le post-it dans la colonne « Fait » en même temps qu’on expliquera au reste de l’équipe ce que ça induit pour les autres.

Lire la suite

Le daily meeting – Points d’alerte

alerte question

Cette liste n’est pas exhaustive mais ce sont des fonctionnements qui, lorsqu’on les observe, témoignent d’un dérèglement du Scrum :

 

  • Toute l’équipe n’est pas présente au daily, et « c’est pas grave »
  • Certains membres sont en retard et on les attend pour commencer, du coup le daily n’est jamais à l’heure
  • Les membres de l’équipe s’adressent au scrun master, l’équipe fait son daily en mode reporting
  • Une tâche de moins d’un jour reste dans la case « en cours » plusieurs jours de suite, sans faire polémique
  • Les membres de l’équipe font leur marché (ils choisissent uniquement certains types de tâches, sans tenir compte des priorités)
  • Un ou plusieurs membres de l’équipe détiennent plusieurs tâches chacun
  • Le point d’avancement sur une tâche dérive en discussions techniques
  • Un ou plusieurs membres de l’équipe font autre chose pendant le daily (ex : lire ses mails). Souvent lié au point précédent.

 

Dans ce cas le ScrumMaster devrait les repérer, en faire prendre conscience à l’équipe et, si elle le souhaite, l’aider à monter un plan d’action pour les corriger.

Qu’avez vous déjà mis en place ?

 

Le daily meeting les 3 questions

Dialogue

L’objectif du daily meeting est de s’assurer tous ensemble que l’on va bien atteindre notre objectif et non de justifier de son temps.

Chez Goood! on reformule les trois questions :

  • Au lieu de « qu’est-ce que j’ai fait hier ? » (Je suis allé en formation, j’ai répondu aux mails …) on propose de répondre à « Qu’est-ce que j’ai terminé hier ? En quoi le projet a avancé ? Ce que j’ai fait a-t-il des conséquences pour les autres ? »

Lire la suite

Lego4Scrum + Birdie Birdie = Birdie4Scrum

Angry Birds Lego
Construction réalisée par Tsang Yiu Keung

J’ai récemment animé une formation de 2 jours Agile-Scrum pour une des équipes que j’accompagne.

Je suis joueur, j’essaie au maximum d’agrémenter chaque apprentissage par un atelier type jeu d’entreprise.

Durant cette formation, pour illustrer l’organisation Scrum, je voulais faire un atelier avant la partie de présentation et surtout jouer le classique des classiques Lego4Scrum dont le but est de construire une ville avec des Playmobils (petit malin…) en passant à travers tous les concepts du framework.
Des personnes de l’équipe avaient déjà joué cette version. Il fallait donc ruser.

En discutant avec Christophe Keromen, j’ai appris qu’il jouait beaucoup le jeu Birdie Birdie ou un Lego4Scrum avec le backlog Birdie Birdie.
J’eu donc l’idée de fusionner les deux jeux afin de créer (je ne suis peut être pas le seul) le :

Birdie4Scrum Lire la suite

3 manières de découper ses user stories

Slices

S’intéresser à la taille de ses user stories et les découper lorsqu’elles sont trop grandes est une bonne pratique. Cela permet d’éviter l’effet tunnel, de produire de la valeur rapidement et de contribuer à une meilleure organisation du travail de tout le monde. Encore faut-il les découper efficacement afin qu’elles soient testables et créent de la valeur. Lire la suite