Ca Scrum !

Je ne sais pas pour vous, mais il existe des moments où les galères s’accumulent. Tout avait pourtant bien commencé dans le Sprint précédent. On savait que le contenu du Sprint devrait absolument être mis en prod ce lundi car il contenait 2 fonctionnalités attendues pour l’ouverture de 10 nouvelles agences, dont la fonctionnalité « MAGAM ».

Bon, personne n’est alarmé plus que ca :

• On vient d’installer en prod la version précédente : nous n’avons pas de stock :)
• Le besoin métier est facile : l’équipe évalue les 2 fonctionnalités à 1 point chacun et nous produisons 60 points par itération.

On commence le Sprint par le plus prioritaire et après 4 jours (sur 15) on a une version stable contenant le minimum obligatoire. L’application est alors mise à disposition du P.O qui valide le fonctionnement. On continue alors le reste du Sprint. J-1, tout le contenu du Sprint est prêt. C’est le début des ennuis : (suite…)

The End

Il y a 7 mois, presque jour pour jour, j’ouvrai ce blog en évoquant combien celui de Frédéric Doillon avait été important dans ma découverte du métier de ScrumMaster. Mon objectif était le suivant :

« Mon objectif principal reste de me fournir un outil me permettant de prendre du recul et de garder une trace du fonctionnement de Scrum sur un projet : du début à la fin :) »

Je n’avais pas imaginé ce jour là combien l’écriture de ce blog allait aussi être une expérience humaine : découverte d’autres équipes, d’autres ScrumMaster, d’autres pratiques agiles … Merci à tous (@nmartignole , @CyrilleDeruel , @jcQualitystreet , @claudeaubry , @NAJard , @agilex ) pour vos commentaires, vos encouragements !

Ce jour, nous venons d’installer en production le projet Marguerite sur lequel l’équipe travaillait depuis début Janvier 2011 en 37 secondes.

Hommage à Frédéric Doillon

Nous venons de démarrer ce matin le dernier Sprint de la release 1 du projet Marguerite. Je voulais organiser un jeu/évènement afin que l’équipe reste focalisée sur la qualité du produit et qu’elle réflechisse à la gestion des risques. Ayant découvert récemment le jeu « Remember the Future« , je voulais organiser un jeu placant l’équipe 1 semaine après une mise en production « ratée » de notre produit et que l’on cherche les causes de cet échec.

Je partage cette idée avec notre « Super P.O » qui trouve cette approche « anxiogène » à quelques jours d’un évenement important. Je repars un peu frustré. Quelques jours plus tard, je tombe sur Alex qui se promenait dans notre entreprise et je lui raconte cette histoire.

Moi : « Ben, euh, il parait que c’est anxiogène comme idée, t’en penses quoi »

Alex : « Faut pas faire un Remember the Future, mais un Pré-Mortem ! »

(suite…)

Lors de notre dernière rétrospective, nous avons pas mal discuté de la gestion des « incidents de production ». En effet, en tant que client final, nous développons nos outils mais nous devons aussi en assurer le bon fonctionnement, parfois en temps réel (on ne peut pas attendre le prochain Sprint pour résoudre un problème).

Dans ce genre de cas, toute l’équipe n’est pas forcement mobilisée sur la résolution de l’incident de production !

L’équipe a donc proposé d’investir dans un nouvel outil de visualisation : le gyrophare, et le fonctionnement suivant : lorsqu’un membre de l’équipe est informé d’un incident de production, il allume le gyrophare et TOUTE l’équipe se réunit afin d’identifier et de trouver au plus vite la meilleure solution au problème.

Il ne nous reste plus qu’à trouver une solution pour ne pas perturber les équipes voisines :)

Début de semaine dernière, on discute de l’avancement du projet avec le P.O :

* L’équipe semble s’améliorer dans ses pratiques de développement
* Les tests automatisés (Selenium) sont de mieux en mieux maitrisés par l’équipe et cela renforce la qualité de l’application
* L’application fonctionne !

Bref, on est plutôt content … et l’équipe aussi. On décide de célébrer cela en début de Sprint en s’organisant une p’tite bouffe à la fin du Sprint Planning Meeting, histoire de bien démarrer cette (courte) semaine.

Ce jour, 16h, « Atchoum » et « Timide » pendant qu’ils binomisent devant les tests : (suite…)

Lors du dernier Sprint du projet Marguerite, l’équipe avait l’impression de ne travailler que sur des User-Story peu importantes (d’un point de vue métier), pour ne pas dire cosmétique. Elle avait l’impression d’avoir perdu la « vision » du produit et ne comprenait plus les priorité métier.

En tant que ScrumMaster

Je veux que l’équipe projet ait le sentiment de produire de la valeur métier dans un logiciel utile

Afin que l’équipe reste mobilisée sur le projet !

Je suis donc allé voir le P.O pour parler avec lui du Backlog (et du manque de compréhension qu’en avait l’équipe). (suite…)

Déjà 7 Sprints consacrés au projet « Marguerite ». Nous avons une vélocité de 31 points pour un sprint de 1 semaine. Les tests automatisés sont entrain de rentrer dans les habitudes de développement, même s’il reste encore une marge de progression :)

Avant le démarrage du projet, l’équipe n’était pas « en forme » : le projet « Chardon » était laborieux, plusieurs départs dans les équipes et le projet (ca reste entre nous hein) n’est pas des plus sympa.

J’ai donc mis en place, dès le début du projet « Marguerite » un Niko-Niko : lors de la démo de fin de Sprint, tous les membre du projets (Equipe, PO et ScrumMaster) votent anonymement sur leur humeur de la semaine. (suite…)

Lors d’un précédent projet (Le projet Génépi), l’équipe a exprimé, lors de la rétrospective, sa difficulté à s’approprier les Users Story. En effet, nous affichons sur notre « Dashboard » Scrum les Users Story (entre 3 et 8 Users Story par Sprint).

Dans un premier temps, ces Users Story étaient rédigées sur des post-it. Globalement, ca ressemblait à ca :

(suite…)

Le projet marguerite a commencé, mais nous devons toujours faire vivre le projet précédent : le projet Chardon (Oui, Marguerite et Chardon sont dans le même pré d’application :p) Comme son nom le sous-entend, le projet Chardon est un projet critique pour l’entreprise, mais c’est un aussi un projet épineux ;) Avec le P.O, nous nous sommes posés la question suivante : Le projet Marguerite va nous occuper pendant plusieurs mois. Il ne nous parait pas possible de ne rien livrer pendant cette période sur le projet Chardon : son Backlog contient une centaine d’item, certaines importantes d’un point de vue business ! Alors comment s’organiser ? (suite…)

On continue le Sprint 0 ! Notre objectif est toujours d’avoir un Backlog, plus ou moins affiné selon les thèmes, mais valorisé et priorisé.

Nous avions, la semaine dernière, une collection de MindMap où chacun a présenté sa vision, ce qu’il avait retenu de nos visites. Pour arriver au Backlog, la première étape va être de synthétiser la contribution de chacun. Pour cela, l’équipe a proposé que l’on utilise des outils ultra modernes : Brown Paper, Post-it ! (suite…)

Aujourd’hui se termine le Sprint 0. (Durée du Sprint 1 semaine).

Quel était l’engagement de ce Sprint ? Obtenir 7 MindMap décrivant le projet Marguerite.

Quels étaient les critères d’acceptation ? Chaque MindMap devait être numérisé pour être projetable lors de la démo (ce matin) et imprimable afin de le mettre au mur pendant quelques jours encore.

Qu’avons nous livré ? Seulement 5 des 6 MindMap répondaient aux critères d’acceptation (pourtant très très simples :p). (suite…)

Aujourd’hui, nous avons commencé le projet « Marquerite ». Comme je l’ai expliqué, ce projet commence par une phase de rencontre de nos utilisateurs sur leur lieu de travail. Objectif : découvrir leur manière de travailler et leur utilisation de l’outil actuel.

Sur le fond, la journée s’est bien déroulée. La première équipe était dans les Hautes-Alpes et nous dans la Drôme. Pour certains développeurs qui travaillent avec nous depuis plusieurs années, c’était leur première rencontre avec les utilisateurs ! Il était plus que temps !! (suite…)