A remote retrospective Story

a bit of context...

I'm working as a remote ScrumMaster since approximatively 2 years with the same team. This team is a full remote team even if most of the times we are doing our sprint planning together IRL. I went with my product owner to setup a new team in Vietnam six months ago. This new team is a bit different because, compared to "mine", all team members of the new team are working together on the same office.

It was quiet challenging because it was planned to make both teams working on the same project and same code base.

Now, 6 months and a product release together later, we decided to make a retrospective with the two teams. The goal was to find out what was working and what was not regarding the collaboration with the two teams.

So I was responsible to setup this retrospective.

the setup

I wanted to port my usual local retrospective format based on sticky note with a whiteboard using good/bad/questions/suggestions areas.

My needs : 

- a good communication tool.

- a good virtual white board.

We were used to use Google Hangout so we sticked with it as our communication channel. The only problem is the 10 slots limitation that i will have to deal with.

After some googling, i found that google drawing could be my virtual white board. I got some inspiration from here : http://www.iliokb.com/2013/02/facilitating-retrospectives-with-remote.html

So we did end up with this kind of setup and a drawing is better than a long speech :

Due to the quality of the internet connection of the green team and to the google hangout limitation, we decided to use the green team scrumMaster as a proxy of the other teams member and to use only one google hangout slot for the green team.

The plan

Here is what I did :

- the week before : 

• fix the date, not so easy to find a slot which everybody.

- few days before : 

• had setup of the google drawing white board, made some try.
• talked to the product owner to explain how it will work.
• talked to the other scrumMaster to explain how it will work.

- the day before :

• sent an email to all participants to remind the goal and scope of the retrospective and to ask them to start to think about that.
• talked again with the other ScrumMaster. As he acted as team's proxy, we discussed together to try to prepare that as better as we can.

- the D day :

• verified that everybody was able to join the shared google drawing.
• just dot it!

Here is the result :

It was fun to hear when everybody was filling the white board "hey, who has stoled my sticky?" ;-)

the retro of the retro

Bad :

• Hangout Limitation (max 10 slots)
• The scrumMaster of the green team was the proxy of the whole teams. It was ok because he was already used to do that for others meeting we already had. Anyway It would have been better to have the whole green team at the same "level"

good :

• It worked well! Using Google drawing as a virtual shared white board was really successful : simple and efficient.
• It's now decided to do that one time per release.

Notes : 

• the virtual retrospective was no longer than the local retrospective i was used to do locally.
• There was more preparation from me compared to a local retrospective.
• I had to allocate more time than initially planned to allow everybody to fill the google drawing.

Scrum distribué : yes we can!

On parle beaucoup de Scrum, beaucoup en bien et beaucoup en mal. Scrum, ça fait parler les gens :-)

Du côté de ceux qui croient en Scrum, On (oui je me mets dedans évidemment) est tous a peu près d'accord sur le fait que Scrum, ça marche bien bien dans des contextes locaux où tout le monde est dans la même pièce. Les outils liés à Scrum sont d'ailleurs orienté pour fonctionner localement avec le fameux tableau blanc, des murs de post-its partout.

A chaque fois qu'on parle de Scrum distribué, tout le monde s'arrête de respirer. Ceux qui ne croient pas en Scrum se mettent à rire et même ceux qui croit en Scrum ont dû mal à croire que ça puisse marcher.

"Quoi ton PO n'est pas dans la même pièce que l'équipe!"

On pourrait d'ailleurs distinguer deux types de distributions :

• distribution partielle : l'équipe est locale mais est distante du product owner

(scrummaster, team member, team member, ...) | (product owner)

Ce modèle fait penser à un modèle "offshore agile" (les extrémistes de Scrum sont déjà en train de s'étouffer car j'ai osé associer ces deux mots :-))

• distribution totale : tout le monde est distribué

(scrummaster) | (team member) | (team member) | (...) | (product owner)

Comment ça, ça ne peut pas marcher?

Il se trouve que je travaille actuellement dans une équipe qui fait du Scrum totalement distribué et ça fonctionne plutôt pas mal...

Comme je suis sympa, je vais même vous dire quels sont les facteurs qui font que ça marche dans notre cas :

facteur n°1 : Des profils costauds

L'ensemble de l'équipe est constitué de "profils costauds". C'est à dire des gens intélligents, passionnés,  avec de l'expérience, autonomes, impliqués, communiquant et sachant prendre les bonnes décisions avec le minimum d'informations.

Ok, je pourrais presque arrêter l'article là. On pourrait peut être même faire du "waterfall" et peut être que ça marcherait :-). 

En tous cas, c'est un des facteurs de réussite de Scrum distribué : choisir et être exigent sur les profils qui feront partis de l'équipe. L'idée dans ce cas est de plutôt partir à la chasse, chercher des gens connus  plutôt que de publier des offres de missions sur Monster.

On dit souvent que le problème se trouve souvent entre la chaise et le clavier :-). Le développement logiciel est avant tout une histoire de personnes.

Tout découle donc de là. Si on a les bonnes personnes, on avance dans le bon sens... Ca parait évident mais il faut simplement parfois le dire (même si ça peut choquer un peu).

facteur n°2 : par défaut, on fait confiance

Une attitude qui n'est pas toujours facile à avoir dans les entreprises en france. Je ne sais pas à quoi c'est dû et je ne vais d'ailleurs pas essayer d'y répondre. En revanche, je constate que souvent "par défaut tu n'as le droit de rien faire, pour ne pas faire de bêtise".  Il apparait toujours dangereux de responsabiliser les gens alors que je trouve que c'est une des clé de la réussite. C'est vrai que c'est toujours dangereux quand les gens se responsabilisent, se mettent à réfléchir, prennent des initiatives ;-)

Pour en revenir à notre Scrum distribué. Le premier jour où j'ai commencé cette mission, j'ai eu tout mes accès (même certains auxquels je n'avais pas besoin), par défaut je pouvais tout faire, par défaut "j'avais les droits", par défaut on m'a fait confiance. Quand on est tout seul dans son bureau à distance, sentir cette confiance est un facteur de réussite pour faire du Scrum totalement distribué. Evidemment, c'est plus facile grâce au facteur n°1.

facteur n°3 : Des outils fiables

Comme tous le monde est distribué, il faut de bons outils pour communiquer. Ils sont ultra présents pour donner l'impression de proximité.

Nous utilisons alors :

• Skype pour faire du chat : plusieurs espaces de discussion sont à disposition (tout le monde, juste mon équipe,...), 
• Skype aussi pour les communication audio et video.
• Netviewer pour faire du partage d'écran.
• les mails pour laisser des traces.

En terme de forge logiciel, nous utilisons :

• une solution VPN plutôt stable (quand le VPN tombe, il est remonté dans la 1/2 heure).
• une version de redmine modifiée à la sauce Scrum.
• Subversion comme gestion de sources.
• Hudson comme serveur d'intégration continue.

Bref, du très classique mais qui fonctionne avec une gestion des utilisateurs plutôt simples.

Le manifeste Agile dit : "Individuals and interactions over processes and tools". Dans le cas d'un scrum distribué, il faut justement des outils pour mettres en avant les individus et les interactions ;-).

facteur n°4: Un product owner super héros

D'habitude, je n'aime pas les super héros en informatique car en général ça se traduit par si le super héros n'est pas là, on ne peut rien faire. Comme c'est de toute façon le cas lorsqu'on fait du Scrum avec un product owner, ça ne me dérange pas ;-). 

Un des facteurs clé de succés est d'avoir un Product Owner qui sache clairement ce qu'il veut. Je ne dis pas qu'il ne peut pas se tromper car Scrum est fait pour ça. En revanche, c'est clairement lui qui doit donner les directions à chaque Sprint et être le guide de l'équipe sur ce qui est à produire.

Il faut qu'il ait totalement confiance en son équipe encore plus quand celle-ci est distribuée. Evidemment, c'est plus facile grâce au facteur n°1.

facteur n°5 : Des réunions incontournables tous ensemble

Un des facteurs clé de succès qui fait que notre Scrum totalement distribué fonctionne est qu'il y a malgré tout des éléments incontournables qui se font localement tous ensemble.

Nous avons des sprints de 3 semaines et nous nous rencontrons pendant 1 à 2 jours pour effectuer de manière intense :

- la fin d'un sprint : démo et retrospective

- le début d'un nouveau sprint : sprint planning, planning poker, ...

C'est assez dense et pour ne rien oublier, en général on "plan the plan" (on planifie le plan) :

Certes cela fait perdre du temps et donc de l'argent car tout le monde voyage pour se retrouver dans un même lieu. En revanche cela en fait ensuite gagner. Faire ce type d'échange de façon distribués prendrait plus de temps que le temps perdu à se regrouper et serait moins efficace.

Une fois de plus le développement logiciel est avant tout une histoire de personnes. Si les personnes se connaissent "IRL" tout devient plus facile.

Ces rencontres tous ensemble sont aussi l'occasion de construire et d'entretenir un esprit d'équipe, de parler d'autres choses que les projets et de pourquoi pas aller manger un bon fish&chips ;-)

Ce qui marche moins bien

Il y a évidemment des choses qui fonctionnent moins bien.

Daily Scrum trop long :

Nous effectuons tous les matins un daily scrum distribué via skype + partage d'écran netviewer du ScrumMaster pour que tout le monde ait le "focus" sur les mêmes choses. Une des problèmes assez récurrents est qu'il est vraiment difficile de le timeboxer. Le DailyScrum a tendance a durer longtemps.

Papier vs Logiciel de ticket

Nous travaillons de manière distribué avec un système de ticket "numérique" alors que nous nous rencontrons et travaillons sur des post-its localement durant les sprints planning.
La préparation du sprint planning prend alors un peu de temps de préparation pour passer de la version, numérique à la version papier. De la même manière la mise à jour du système de ticketing est juste long et ennuyant...

Sprint planning parfois un peu court

Nous avons parfois du mal à tout boucler lors de nos sprint planning, nous devons dans ce cas le terminer de façon distribuée.

 Pour conclure

Je vous propose une fois de plus mon humble retour d'expérience sur le sujet. Un simple retour d'expérience d'un Scrum distribué qui fonctionne.

Attention :  Ca ne veut surtout pas dire :

• que si vous faites exactement la même chose, ça marchera
• que si vous faites différemment ça ne marchera pas

Agilité par contamination

Lorsqu'on souhaite mettre en oeuvre Scrum la première fois, il est souvent dit de mettre en place la totalité du framework et dans un second temps de l'adapter quand l'ensemble des acteurs possèdent le recul nécessaire (pour justement l'adapter favorablement). Cette mise en place totale a pour but de ne pas tomber dans les fameux "Scrum But", souvent cause de l'échec de la mise en place de Scrum. Les "Scrum But" pour simplifier représentent les entorses au framework (Exemple : c'est le ScrumMaster qui fait les estimations et affectent les tâches, oui ça c'est de la très grosse entorse ;-)).

Je vous propose ici de vous raconter un de mes retours d'expérience sur le sujet qui est très différent de l'approche dont je viens de vous parler.

Il y a bientôt un an, j'ai intégré une équipe de développement chez un éditeur logiciel qui ne pratiquait pas "l'agilité". Ce nouvel environnement me paraissait idéal pour mettre en place Scrum couplé avec un peu d’Extrême Programming pour plusieurs raisons :

• une petite structure (moins de 25 personnes).
• une équipe de développement de moins de 6 personnes.
• une forte croissance.
• la volonté de développer une nouvelle version d'un produit.

Il faut avouer que Scrum est très déroutant dans ces pratiques quand on ne les a jamais mises en oeuvre. Comme je ne m'appelle pas Jeff Sutherland (un des papas de Scrum) et que je ne suis pas un extrémiste (enfin j'estime ne pas l'être, ce qui est différent, je vous l'accorde), je n'ai pas forcé pour la mise en place de Scrum.

En revanche, je travaillais sur un sujet isolé et avec une liberté totale sur ma façon de travailler. J'ai donc fait du Scrum et de l'Xp seul (ok ce n'est pas vraiment du Scrum). Tiens ça me fait penser à Jean Jacques.

Hey hop, c'est parti, je récupère un tableau en carton, j'ai un mur juste derrière moi, impeccable,  ça sera mon scrum board. Un petit tour par la compta : "Heu, vous auriez des post-its? Ha, vous n'avez que cette couleur, ok ça ira très bien pour commencer. Vous pouvez en commander d'autres? et de plusieurs couleurs?".

Un ou deux jours passent...

Réaction 1 : "Ha c'est comme ça que tu travailles?"
Réaction 2 : "C'est jolie tous ces post-its derrière toi, c'est quoi, ça marche comment?"

Côté pratique d'ingénierie, pas d'intégration continue, pas de DVCS (en tous cas pas celui que je voulais :-)), pas de suivi de qualité, pas de déploiement continu. Ok, qu'à cela ne tienne, "Just Do It". C'est parti pour mettre en place une forge logicielle complète sur une machine virtuelle dans un coin de serveur (apache, jenkins, git, sonar, maven, ...).

Réaction 3 : "C'est quoi l'intégration continue?"

J'avais maintenant tous les outils que je souhaitais pour développer. C'est parti. Les semaines passent, les post-its s'entassent...

Réaction 4 : "C'est pas mal ton tableau avec les post-its pour voir l'avancement du travail"

A force de question et de discussion autour de Scrum avec l'équipe de développement, je me propose de leur faire une présentation de Scrum. C'est parti pour une présentation de 2h très conviviale. L'objectif est de faire découvrir les principes du framework. Rien de plus.

Réaction 5 : "C'est vraiment très différents, ça n'est pas du tout aujourd'hui notre façon de travailler, ça fait un peu peur"

Les semaines passent... et qu'est-ce que je vois sur le bureau du collègue à côté de moi, le livre "Scrum" de Claude Aubry. Je lui dis que c'est un super bouquin qu'il a bien fait de l'acheter.

Réaction 6 : "C'est ma compagne qui me l'a acheté car je lui avais parlé de la présentation que tu avais faite"

Alors là je suis scotché!

Les semaines passent... et un gros sujet à traiter par toute l'équipe nous tombe dessus. On ne sait pas par quel bout le prendre. Je propose aux membres de l'équipe qui connait le mieux le sujet de faire un mind map pour modéliser le travail à effectuer ainsi qu'une réunion tous ensemble où l'on ajuste le Mind Map pour tous obtenir une bonne vision de ce qu'on va devoir faire.  J'extrais ensuite le contenu du Mind Map dans un fichier Excel.

Réaction 7 : "C'est un peu comme un Backlog ce fichier Excel, non?"

Je l'ai ensuite renommé en "Backlog".

Réaction 8 : "Par quoi on commence?"

Je propose de refaire une réunion avec toute l'équipe pour qu'on priorise les sujets/tâches tous ensemble pour traiter les tâches les plus urgentes.

Réaction 9 : "On priorise tout, tout de suite?"

Je propose alors de faire un point tous ensemble toutes les semaines et de prioriser/reprioriser les sujets.

Réaction 10 : "On migre les applis existantes sur git"?

Yes!

Réaction 11 : "Comment on fait pour rajouter un Job dans Jenkins"?

Yes! Je te montre!

Les semaines passent... et je discute avec le directeur général. Il m'apprend qu'il s'est documenté sur Scrum et les méthodes Agiles qu'il trouve ça très intéressant et qu'il souhaite qu'on fasse des petites réunions tous les matins.

Aujourd'hui, nous ne pouvons pas dire que nous "faisons du Scrum" mais tous ce qui est mis en place nous aident réellement au quotidien. L'utilisation d'un backlog et la réalisation du Daily Scrum du matin sont maintenant une évidence. J'espère que cette démarche (non préméditée) de contamination va se poursuivre.

Alors que je pensais que Scrum ne pouvait fonctionner sur le principe du tout ou rien, je me rends compte que l'agilité progressive est un succès dans notre cas.

Vous en pensez quoi?

Il est beau mon scrum board

Le scrum board est un élément central au niveau d'un projet agile. Il est déjà fort utile sur des projets dit "non agile". Dans un contexte agile, c'est tout simplement INDISPENSABLE. Cela ne sert à rien d'en dire plus à ce sujet!

J'ai déjà pu lire des débats sur la forme qu'il doit prendre surtout dans des contextes un peu complexe d'équipes distribuées où il peut devenir numérique. Dans mon cas, sur un projet avec une équipe centralisée, on est resté très KISS : un simple tableau blanc aimanté de 2m * 1m est impeccable.

Scrum Wall

Vous parler seulement de notre Scrum board est trop réducteur. Il faut que je vous parle de notre "Scrum Wall". Un tableau blanc est un peu juste pour tout ce dont nous avions besoin. Comme nous avions de la place, nous ne nous sommes pas privé.

Voici donc notre Scrum Wall :

La photo est prise après la fin du projet, le partie tableau blanc est un peu vide :-).

Il est constitué (en partant du porte manteau, de gauche à droite) :

• d'un A4 de rappel sur le daily Scrum :

Cette feuille n'était pas là au début, je l'ai rajoutée en cours de projet. Avec l'habitude du projet, nous oubliions parfois les fondamentaux. Ca fait toujours du bien de les avoir sous les yeux pendant notre Daily Scrum :-), même de dire que "je n'ai pas rencontré de problème particulier".

• La partie gauche du tableau blanc : 

La partie gauche du tableau blanc est purement réservée au sprint. Dans cette partie se trouvent 4 colonnes : 

- To do

- In progress

- QA

- Done. 

J'ai dû rajouter une feuille en dessous car je n'arrivais pas à tout faire tenir sur une colonne pour un sprint. Haaa... ces équipes hyperproductives, je vous jure :-). La dernière colonne de cette partie hébergeait un ensemble de zones qui ont évoluées au cours du temps. Nous avons commencé avec :

- identification du sprint (numero et contenu)

- technique (problèmes)

- organisationnel (problèmes)

- RE7 (remontées d'infos suite à la recette)

Pour au final terminer avec : 

- identification du sprint (numero et contenu)

- corbeille (permet de faire le ménage quand la colonne "Done" devient trop remplie sans pour autant enlever les tâches du sprint en cours du Scrum Board).

- Actions après rétro (actions à effectuer sur le sprint par rapport à la rétro précédente).

- Problèmes (tous)

- Stockage des aimants : il faut bien les mettre quelque part. Au lieu de les retrouver dans la zone des problèmes organisationnel par exemple...

La partie droite du tableau blanc : 

C'est l'espace "temporaire", il sert un peu à ce qu'on veut. Comme vous pouvez le voir, comme la photo a été prise après la fin du projet, l'emplacement est déjà "squatté" pour un autre projet. Cette espace permettait de réfléchir ensemble, d'expliquer, de schématiser, d'y mettre les horaires de la prochaine démo et de la prochaine rétro.

• La partie droite du mur : 

C'est le "A3 du projet". L'objectif est de proposer une vue synthétique du projet (la vision, les enjeux, la méthodologie, l'architecture globale, un mot sur Scrum, ...).

• Et il manque??? Le burndown du Sprint que nous mettions entre le tableau blanc et le A3 du projet mais qui n'est plus là au moment des photos que j'ai prises.

• Et en bonus, au dessus du tableau blanc, nous y avons mis des goodies que nous avions sur le projet, les cartes postales envoyées par les membres de l'équipe en congés,...

Beau et "clean"

Que vient donc faire la notion du "beau" dans un projet Scrum? 

Le principe d'affichage est à double tranchant. Il offre d'une part une transparence sur le projet et d'autre part justement, on ne peut rien cacher. Les apparences sont trompeuses mais elles ne laissent pas forcément une bonne impression :

Vous y croyez vous si la personne qui possède cette chambre est bibliothécaire? C'est possible mais c'est dur à croire avec cette seule vision:-) 

• Vue de l'équipe : Le Scrum board est le seul outil qui permet aux membres de l'équipe de travailler ensemble de façon efficace sans se marcher dessus. De plus, c'est aussi cette même équipe qui s'en sert quotidiennement. le désordre attire le désordre et inversement!

• Vue de l'extérieur, Scrum souffre parfois de son image. Les clichés ont parfois la vie dure :

-Le framework Scrum est parfois vue comme une méthode de gestion de projet exotique mais qui n'est pas applicable. On en arrive même à préférer ne pas dire qu'on fait du Scrum...
- "C'est quoi cette bande de rigolos qui joue avec des pos-its."
- "Et en plus ils font un poker au boulot"

- "Cela manque de rigueur"

- On a parfois du mal à comprendre que le fun peut faire partie du boulot.

Si on associe à cela un Scrum Wall qui n'est pas "clean", on a dû mal à projeter un image de qualité logiciel sur ce qu'on livre...

Il faut donc que le Scrum Wall soit beau!

CQFD

Des astuces

• Un "A3 projet" de qualité : Sa réalisation est un exercice délicat qui nécessite de prendre du recul et du temps mais il est la carte de visite de votre projet vu de l'extérieur. Il facilite aussi l'intégration d'un membre dans l'équipe ainsi que la présentation du projet.
• De la couleur : N'hésitez pas utiliser des couleurs différentes pour vos post-its d'un sprint à l'autre. En revanche, sur un sprint, essayez de vous y tenir.
• Des couleurs et des tailles différentes :  Utilisez des post-its de tailles et de couleurs différents permet d'identifier rapidement des fonctions différentes. Nous utilisons par exemple des pos-its carré (76mm*76mm) pour décrire une User Story et des petits post-its rectangulaire (38mm*51mm) d'une autre couleur pour les tâches.
• Utilisez un stylo feutre pour écrire. Ca augmente la lisibilité.

Une petite illustration : 

en haut : BAD / en bas : GOOD

• Eviter d'avoir le post-it qui rebique : http://www.bouzin-agile.fr/?post/2010/10/15/Evitez-d-avoir-le-post-it-qui-rebique
• Notez vos initiales sur les tâches en cours (ou un autre moyen d'identifier une personne sur une tâche en cours).
• Faites le ménage régulièrement sur le Scrum Board: Est-ce que ce schéma est encore utile, est-ce que le problème est toujours d'actualité, ...

Voici quelques illustrations de notre projet :

• Un début de sprint (d'une semaine) :

• Un sprint en cours (de 15jours, nous avons fait évoluer la durée de nos sprints) :

(Nous remontions la colonne de gauche au fur et à mesure des Users Storys terminées en haut).


Sur ce, bonne année à tous!

Scrum Box : la caisse à outil d'un projet Scrum

Avez-vous déjà remarqué la rapidité avec laquelle vos pos-its, vos stylos et autres fournitures disparaissent sur votre bureau. C'est d'autant plus gênant sur un projet utilisant Scrum car justement assez gourmand en fournitures.

Pour éviter ça, j'ai créé sur notre projet la "Scrum Box" :

C'est quoi donc "une Scrum box"? : 
On peut la voir comme la caisse à outil Scrum de notre projet.

Qu'est-ce qu'elle contient : 

• Un assortiment de bloc de post-it carré 76mm*76mm. "les standards"
• Un assortiment de bloc de pos-it rectangulaire 38mm*51mm. "les petits"
• Un assortiment de marqueur pour tableau blanc.
• Un assortiment de marqueur pour paper board.
• Un ou deux stylos feutre.
• Une dizaine de stylos à bille.
• Un jeu de carte de Planning Poker.
• l'adaptateur vga de mon mbp pour le video projecteur.

Elle doit être identifiée en tant que telle et porter le nom du projet!

Qui s'en sert?

L'équipe et uniquement l'équipe! Il peut y avoir des dérogations si c'est demandé gentiment :-)

Quand s'en sert-on?
Au quotidien, tous les membres de l'équipe viennent y piocher des post-its, prendre des stylos, et choses assez cool : les remettre une fois utilisé.

Et plus particulièrement lors des rituels de début de de fin de sprints : Nous effectuons le sprint planning, la démo et la rétro dans une salle un étage en dessous de celui où nous travaillons. Dans cette box, j'ai quasiment tous ce qu'il me faut pour mener ces rituels.

Est-ce vraiment utile?
Oui! C'est une évidence sur notre projet. On n'y prette même plus attention.
On peut se poser la question de savoir si ça permet de ne pas se faire piquer les fournitures par d'autres collègue sur d'autres projets, hé bien oui ça marche et pourtant la box est en libre service et juste en carton.

Avec elle, impossible d'avoir oublié son stylo lors d'un sprint planning!

Cela me permet d'avoir un stock intermédiaire et dédié au projet de fournitures. Elle permet d'être "toujours prêt". Il y a déjà pas mal de chose à préparer et à transporter lors d'un rituel de début ou de fin de sprint (entre le portable, son chargeur,  le video projecteur, des éléments pour faire la démo, ...), la box simplifie le transport de toutes les fournitures :-).

En tant que ScrumMaster sur le projet, ca a été un réel obstacle en moins pour moi ou pour les autres membres de l'équipe. Evidemment, il faut relativiser, il y a d'autres obstacles plus importants et plus compliqués à enlever sur un projet :-).

Formation certifiante Scrum Master avec Jeff Sutherland

J'ai participé à la formation certifiante Scrum Master du 1er et 2 Octobre dernier organisé par Xebia à Paris La Défense avec Monsieur Jeff Sutherland (le papa de Scrum).

Je ne peux que trop vous conseiller de faire cette formation!

J'étais déjà convaincu par ce peut apporter Scrum (couplé avec XP par exemple), et après la formation, ça ne s'est pas arrangé.

Il faut par contre, à mon avis avoir, déjà débroussailler le terrain sur Scrum et les grands concepts pour assister à cette formation. Je vous conseille par exemple : "Scrum and Xp From the trenches" de Henrik Kniberg. C'est une bonne première approche. Le livre est disponible gratuitement en version numérique. Prenez la version original en anglais, ça vous aidera aussi si vous voulez assister à la formation qui est en anglais :-).

Pour en revenir à la formation, Jeff ne s'attarde pas plus que ça sur les grands concepts en début de formation. Il les aborde tout au long de la formation. En revanche, il insiste plus sur ces retours d'expériences et sur le fait que cette méthode, pardon ce framework, est sacrément efficace. Jeff est un bon évangéliste sur le sujet :-). Les références sont quand même Google, Apple ainsi que de très grand groupe.

J'ai bien aimé la partie concernant les projets en échecs et qui disent utiliser Scrum et qui en grattant très légèrement ne l'utilise pas vraiment, voir pas du tout.


J'ai bien aimé le planning poker avec l'application sur mon Iphone :-). C'est totalement "In".

J'ai bien aimé le léger focus sur le rôle de Product Owner qui est très très très important.
Il nous a d'ailleurs posé la question : "Who is the best Product Owner in the World?" la réponse ici. J'adore...

J'ai bien aimé enfin le fait qu'on ai réellement le temps de poser toute nos questions. pas de langue de bois.

Les mises en situation tout au long des 2 jours de la formation sont très intéressantes. Le XP game en fin de formation est top.

La prochaine session en France est normalement prévu le 3 et 4 décembre 2009. Vous trouverez plus de détails ici.

J'ai rarement vu une formation où tout le monde veut prendre sa petite photo avec le formateur à la fin de la formation. C'est peut être une preuve de la qualité de la formation... ou pas... bon ok j'ai été faible, j'ai la mienne aussi...

Bon maintenant le problème, c'est que je ne vois pas comment je vais faire rentrer Scrum chez mon client autrement qu'en allant voir le CEO :-).

Scrum fait peur

Et plus largement les méthodes Agiles.

C'est le constat que je peux faire dans le contexte dans lequel j'évolue.

Je me suis longtemps dit qu'en effet, se lancer dans un premier projet en Scrum peut faire peur alors que l'on n'a jamais fait cela auparavant. En revanche, lorsque le contexte le permet, que des gens compétents sur le sujet y participent et qu'il n'y a pas réellement de risques à faire "un essai" ( :-) les experts comprendront...) , j'ai plus de mal à comprendre...

Une des grosses évolutions par rapport à des méthodes de gestion de projet dites "traditionnelles" (ou plutôt celles qui ne fonctionne pas ou peu) concerne le métier de chef de projet qui n'existe plus car il est remplacé/transféré par le rôle du ScrumMaster.

En se mettant un peu à la place d'un chef de projet, il est plus facile de comprendre (mais pas forcément d'accepter) leurs points de vue. Imaginons qu'on vienne vous dire que votre façon de travailler depuis des années soit totalement remise en questions, que des retours d'expériences vous démontre que c'est presque une évidence et que vous n'y avez pas pensé. Cela ne doit pas être évident à encaisser...

Messieurs les chefs de projets, je vous le dit :
Scrum ça n'est pas l'avenir, c'est tout de suite! Allez-y!

Juste pour le fun, une petite tendance à la google :


en bleu : rational unified process
en rouge : Scrum agile

Comme le précisez Claude Aubry sur son blog dans ce billet en 2007, il faut faire attention à ne pas créer un Buzz autour de Scrum et le transformer en une méthode un peu originale et à la mode. Scrum c'est avant tout un ensemble de pratiques simples et pragmatiques à mettre en œuvre pour réussir un projet.

Une métaphore de Scrum

Le Touilleur Express vient de publier une métaphore permettant d'expliquer les grands concepts autour de Scrum.

Pour Simplifier, Scrum : c'est une machine à laver. J'adore.

Je vous laisse aller lire le billet du Touilleur Express sur le sujet pour avoir plus d'infos.