Ca Scrum !

Pour ceux qui ne le savent pas encore, j’ai quitté mon précédent employeur il y a maintenant 3 semaines. Cela faisait presque 10 ans que je travaillais dans ce groupe et c’était ma première experience significative. Ce départ est un départ positif : je pars heureux de ce que j’ai appris, de ce que j’ai pu apporter. J’ai chercher des conseils auprès de Jean-Claude Grosjean pour qu’il m’aide à faciliter ce départ. Après notre discussion, j’ai mieux compris l’importance de la « célébration » du départ. Ce n’est pas « naturel » de célébrer une séparation. Divorces, enterrements, licenciements ne sont pas en général des moments très festifs et joyeux. Et justement, une séparation n’est pas un moment triste. Certes, c’est la fin d’un parcours que l’on a fait ensemble, mais d’un parcours qui nous a emmené à des réussites (humaines avant tout). Alors il est important que ce dernier moment soit à l’image de ce que l’on a construit ensemble… (suite…)

Aujourd’hui, Fred m’avait fait le cadeau de pouvoir animer une séance Innovation Games ® avec un groupe de 25 étudiants de MI Miage à Grenoble.

Au programme : 10 minutes de théorie et 7 heures de jeux !

• Personnal Identity Card
• Product Box
• Give Them a hot tub
• 20/20 Vision
• Pré-Mortem

Les étudiants se sont vraiment pris au jeu (ceux qui étaient en partiel à côté aussi, effet de bord :p).  Beaucoup de création, dans un calme raisonnable, de bons moments d’échanges  : que du plaisir ! (suite…)

Je ne suis pas facile.

Il faut le reconnaître, humblement, je ne suis pas facile à manager. Il faut dire que je n’aime pas sentir « tiens, là, on est entrain de me manager ». Je ne sais pas si certaines personnes aiment cela, ou si la plupart des gens trouvent ca normal. De mon côté, je fais partie des personnes qui se sentent sur la défensive dans ces moments là. Et comme je ne suis pas facile, je ne me laisse pas faire. Un exemple ? (suite…)

J’ai planté un chêne
Au bout de mon champ
Ce fut ma semaine
Perdrerai-je ma peine
J’ai planté un chêne
Au bout de mon champ
Perdrerai-je ma peine
Perdrerai-je mon temps…

Depuis 3 ans que je vais à Agile Grenoble, et cette année en plus à Agile Innovation, je me demande toujours ce que je vais découvrir … Et si je vais arriver à apprendre de nouvelles choses. Dans tous les cas, je me force chaque année à ne pas prendre de notes, afin de profiter du moment présent. La plupart des « speaker » mettant à disposition leur présentation, tout est mis en oeuvre pour que je puisse rester « connecter » avec l’évènement. (suite…)

Pour compléter l’article précédent, je vous invite à venir découvrir un « nouveau » jeu : La session dont vous êtes le héros.

J’aurai la chance d’animer cette session avec Emmanuel Etasse … Que j’avais rencontré il y a 2 ans lors d’une formation ScrumMaster. Il y a quelques mois, nous nous sommes lancé le défi d’inventer un nouveau jeu. Après 2 premières présentations au CARA ainsi que dans mon entreprise, nous espérons être à la hauteur le  jour J :)

Ce sera un moment important pour moi : ce sera ma première présentation à la communauté agile, la première occasion de « donner » à la communauté après avoir beaucoup appris pendant plusieurs années. Je suis d’autant plus heureux que ce soit sous la forme d’un jeu.

J’aime l’apprentissage par les jeux. Je suis déjà joueur de nature et la naissance il y a 2 ans de ma fille me prouve chaque jour combien il est « naturel » d’apprendre par le jeu. En grandissant, en devenant « serieux », on a tendance à se censurer … et on ne s’autorise plus à jouer. Alors apprendre en jouant … Au travail … Au lieu de produire du logiciel … Ce n’est pas évident.

(suite…)

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…)

Le projet Marguerite, le projet chardon, etc … Tous ces projets composent notre Système d’information. La plus grande contrainte dans le développement d’un S.I tient au fait qu’il n’existe pas de date de fin à la création du S.I. L’agilité nous propose différents outils permettant de revoir régulièrement nos priorités facilement, ce qui a été une révolution ! Il est cependant important pour l’équipe, le P.O mais aussi les stackholders d’avoir régulièrement une « vision » des prochaines étapes : le Release Plan.

Quel outil ? Comment construire / échanger / travailler cette définition du produit sur les mois à venir ?

L’idée toute simple m’a été soufflée par Jean Claude GROSJEAN, dans un article lu il y a quelques mois concerant son backlog D.E.E.P et physique.

(suite…)

 Pour bien démarrer cette rentrée, je prépare ma présentation pour l’Agile Grenoble 2011. La date de clôture étant le 15 septembre, il commence à y avoir urgence :)

Et oui, il va bien falloir que je sorte de l’anonymat un jour …

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…)

En ce début de semaine, les équipes étaient réunies avec notre encadrement pour un « séminaire » avec pour objectif de définir ensemble les objectifs pour les années à venir.

Tout d’abord, je trouve cette approche hyper sympa (et hyper agile) d’associer en amont les équipes à ce genre d’évènement (Traditionnellement réservé aux cadres stratosphériques).  Les bénéfices sont énormes sur la motivation des équipes ; mais surtout l’intelligence collective permet d’aboutir à des résultats probablement plus crédibles et plus performants.

Mais comment répondre à cette question, lorsque l’assemblée est composée d’une trentaine de personnes (fonctionnels, techniques, manager, …) ?

Pour cela, Fred nous a proposé un « Innovation Game » appellé « Remember the Future ».

L’idée principale est de réaliser une sorte de Story Map, mais en partant de la date de fin :

Nous sommes en juin 2014. Rappellez-vous tout ce que nous avons fait depuis 3 ans pour en arriver là :)

Ok, présenté comme cela, pas de quoi s’en relever la nuit. Mais en essayant, on se rend compte que notre cerveau est un petit coquin : nous ne réfléchissons pas de la même manière selon que l’on se projette dans le futur (ou serons nous dans 3 ans) ou bien dans le passé : nous priorisons mieux, nous ne nous sommes pas focalisé sur les détails, le consensus m’a paru plus facile.

Quelques itérations, une présentation (démo), une rétro : et hop, nous produisons une vision partagée, engagée et motivante !

Le tout dans un cadre sympathique, accompagnée d’une partie de pétanque : les batteries sont rechargées :)

Lors d’un moment d’échange entre équipes agiles, nous avons eu de vives discussions sur « les tests fonctionnels ».

D’un côté, certaines équipes prônaient la validation fonctionnelle dans la définition du terminé. Cela pouvait se faire de plusieurs manières :

1 – Par délégation : La User Story est claire pour l’équipe, le P.O partage ce sentiment et les critères d’acceptation sont écris et non ambigus. La « simple » écriture d’un scénario avec Sélénium servira de validation fonctionnelle.

2 – Par participation : Le P.O est sollicité pendant le Sprint afin de validé la Story.

3 - Par la démo : Le P.O valide pendant la démo.  :)

Dans tous les cas, il s’agit de validation et non de remise en question de la fonctionnalité. Si le besoin change, on laisse tomber la fonctionnalité : elle ne sera pas produite (terminée) lors du Sprint et le P.O pourra de nouveau la présenter lors du prochain SPM.

De l’autre côté, d’autres équipes prônaient la validation fonctionnelle en dehors du Sprint. Le principe est le suivant :

1. La User Story est développée lors du Sprint X : elle est présentée au P.O lors de la démo.
2. Le P.O prend le temps de la valider pendant le Sprint X+1.
3. Si la Story ne « marche pas » ; alors il y aura une « Bug Story » lors du Sprint X+2. S’il faut la compléter ou modifier son fonctionnement, alors il y aura une nouvelle « User Story »

Ces 2 approches ont leurs avantages :

• Dans la première, la définition du « done » est claire : on peut mettre en production. Comme lu sur Twitter cette semaine :

@danielbrolund If « done » doesn’t mean 100%, « donedone » is less and « donedonedone » even less. Compare 0.99>0.99*0.99>0.99*0.99*0.99. :-)

• La deuxième solution a aussi son avantage : elle réduit la « pression » mise sur la validation fonctionnelle et permet à l’équipe d’avancer !

Je vous propose donc le jeu suivant :

 Loading ...

Fin du jeu Dimanche 29 à 23h59 :)

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 :)

Cela fait maintenant plusieurs mois que je voulais faire cet article sur la rédaction des tests selenium (et en plus, c’était plutôt bien noté dans mon backlog :p). J’espère que les commentaires seront nombreux !

Voici un exemple de scénario que l’on peut facilement générer avec Sélénium et son IDE. C’est déjà chouette ! On a largement de quoi repenser notre manière d’organiser les projets ; comme mettre en place du Développement Piloté par le Comportement (BDD).

Après quelques projets, quelques points négatifs demeurent :

1 – Peut-on dire que la lisibilité est suffisante ? Peut-on échanger avec un P.O ou des fonctionnels sur la pertinence de tel ou tel scénario ?

2 – Lorsque l’application évolue, il faut reprendre beaucoup de tests : il n’y a aucune factorisation du « code » des tests.

Je vous propose donc un exemple d’organisation des tests Selenium. Pour cela, je vous propose de « tester » la vente en ligne du site fnac.com (J’ai choisi ce site pour sa célébrité et sa « complexité » ergonomique) (suite…)

Baleine et banc de poissons

Lors de ma formation Scrum, j’ai retenu 2 éléments concernant Scrum et le management :

1 – Le ScumMaster n’est pas un chef de projet qui fait obéir son équipe au doigt et à l’oeil : il ne manage pas l’équipe mais le processus.

2 – Les rôles « utiles » pour le produit sont le P.O, le ScrumMaster et la Team (auto-gérée et possédant toutes les compétences nécessaires à la réussite du projet) : tout autre rôle est inutile à Scrum.

Durant cette première année de pratique de Scrum, j’ai tout de même eu quelques interrogations :

• En mettant en place un Niko-Niko, en « protégant » l’équipe, en l’incitant à mettre en oeuvre certaines pratique d’ingenierie (BDD, Pair programmning, …), en mettant en place des entretiens OneOnOne, ne suis-je pas entrain de faire du management d’équipe  ?
• Mon manager, son manager, les autres services ainsi que la direction générale, même s’ils ont compris notre mutation vers l’agilité, fonctionnent toujours de manière traditionnelle. Et pourtant, la communication doit avoir lieu entre « eux » et « nous ». Quelle type de relation dois-je mettre en oeuvre entre mon management hiérarchique (ainsi que celui de l’équipe) ? Est-il possible d’aller plus loin et d’envisager une entreprise agile ? (suite…)

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…)

Pour ceux qui me connaissent, j’aime beaucoup faire des « expériences ». Celle que je vous propose aujourd’hui est simple : m’aider à valoriser mon Backlog.

Lorsque l’on fait un blog (comme CaScrum), l’auteur est seul pour assumer les 3 rôles de Scrum. En tant que Product Owner, je suis représentant des clients : vous. Je vais donc essayer d’obtenir de votre part un retour pour m’aider à prioriser les « besoins », c’est à dire les articles qui seraient les plus intéressant à lire.

Voici la règle du jeu que je vous propose : chaque visiteur pourra « voter » pour 2 articles qu’il souhaite lire. Le vote sera ouvert pendant 1 semaine. A la fin de cette semaine, je choisirai en fonction des résultats (et de l’effort correspondant) l’article que je rédigerai.

Je laisse les commentaires ouverts sur cet article afin que vous puissiez vous aussi me suggérer des thèmes.

Voici mon (petit) backlog :

 Loading ...

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…)

Comme je l’avais fait il y a (presque) un mois, voici ma « rétrospective » de blog !

Lors de la rétrospective précédente, j’avais mis en évidence 3 points à travailler. Quels sont les effets sur le site ? Est-ce que les axes d’améliorations ont été travaillé ? Comment améliorer le blog ? Il est l’heure du bilan ! (suite…)

Comme on me l’a fait remarqué dans un précédent article, l’entretien d’un jeu de test est une problématique à part entière.

Je n’ai pas la prétention d’avoir trouvé « LA » solution miracle, mais disons que nous avons trouvé une organisation qui nous simplifie grandement l’entretien de nos cas de test : « nous n’en avons pas » ! (suite…)

La mise en place « des tests » au sein de l’équipe est un vrai challenge : nous partons de 0. Les réactions ont rarement été positives : « Ca sert à rien », « De tout façon, je ne fais pas de Bug », « Le projet existe depuis 5 ans sans tests, donc soit on fait tout, soit on fait rien … Et comme on n’a pas le temps de faire des tests sur tout l’existant, ca sert en rien d’en faire » et le dernier « De toute façon, tout ne peut tester : on n’est pas dans la tête des utilisateurs ».

Bon, une fois qu’on a dit ca, qu’est-ce que l’on fait ? Et bien pour ma part, je prend mon bâton de pèlerin et on essaye d’expliquer :

• Il faut être pragmatique dans les tests : Entre rien faire et tout faire, il y a évidemment un compromis à trouver.
• Il y a des tests souvent plus prioritaire que d’autres (En tout cas, avec une valeur métier plus importante que d’autres)
• Il pourrait même être envisageable d’être piloté par les tests ! (Sisi, j’vous assure .. ça existe !).

Bref, on est parti pour faire œuvre de pédagogie avec l’équipe (Est-ce le rôle du ScrumMaster ?). (suite…)

La semaine dernière, je posais sous forme de jeu une question qui semblait très simple, avec seulement 2 réponses, incompatibles entre elles : Soit on implique l’équipe, soit on ne l’implique pas).

Tout d’abord, je suis très content de la « réussite » de ce jeu : le taux de participation a dépassé mon objectif et les résultats montrent qu’il n’y a pas d’évidence dans la réponse, dans l’action à mener !

Évidemment, la réponse doit tenir compte du contexte (Que veux exactement le manager ? Quelle maturité à l’équipe ? Quel relation de confiance existe entre l’équipe et Le ScrumMaster, etc …). Aucune formation Scrum (certifiante ou non) ne donnera la « bonne » réponse ! Scrum est là pour nous faire nous poser des questions ! Scrum nous suggère d’essayer et de mesurer quels seront les effets. Dans mon contexte, j’ai choisi de prendre un risque !

(suite…)

Avant de rédiger un article sur Scrum et le management, je voulais vous proposer un petit jeu. Mon objectif est d’atteindre 40 réponses en 1 semaine, alors prenez quelques secondes pour jouer !

Votre manager vous convoque : il a le sentiment qu’en ce moment l’équipe n’est pas très productive.

 Loading ...

Lorsque l’équipe a exprimé l’envie de faire de « l’intégration continue », je me suis bien demandé de quoi ils pouvaient me parler. Wikipédia étant notre ami, voici ce que nous avons lu :

L’intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement. Bien que le concept existait auparavant, l’intégration continue se réfère généralement à la pratique de l’extreme programming.

Et là, l’équipe était bien embêtée : « Ben, euh … On voulait surtout que notre application soit plus facilement packagée et installable. On peut faire quelque chose quand même ? Et puis t’as vu, c’est agile ! « .Touché. (suite…)

Cela fait un peu plus d’un mois que « Ca Scrum ! » est maintenant un blog actif. Ce blog, je l’ai voulu agile dans son contenu, mais aussi dans sa forme : Certaines propositions d’articles sont issues de « demandes utilisateurs », j’essaye autant que possible de privilégier la qualité (hum hum) à la quantité … J’essaye aussi d’obtenir le plus de « feedback » possible : les commentaires sont libres et un ROTI est en place (dont les résultats sont visibles sans voter).

Je vais essayer de conserver l’approche « Agile » de ce blog en faisant ma première p’tite rétrospective et en mesurant les effets.

(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…)