En discutant avec les Scrum Master, je me suis rendu compte qu’ils n’avaient pas compris l’utilité réelle de la rétrospective … et pourtant certains sont Certifiés … mais quel est ce formateur certifiant qui les a former aussi mal ?

Bon j’arrête sur ce sujet … promis … mais je n’en pense pas moins … et toc !

La rétrospective n’a pas pour objectif de faire un tour de table rapide de l’équipe pour demander simplement si l’itération précédente s’est bien passée ou pas. Si 2 équipes ne pratiquaient simplement pas la rétrospective, par manque d’intérêt et d’envie, pour la 3ème c’était très différent car le Scrum Master m’a indiqué que l’équipe faisait la rétrospective de l’itération précédente à la fin du premier Stand Up de l’itération suivante, soit tous debout et en 5 minutes … J’HALLUCINE !!!!

Mais au moins je lui reconnais un certain mérite … si, si … quitte à faire une rétrospective qui ne sert à rien … au moins la faire vite, c’est mieux

J’aimerais rappeler quelques principes de base des rétrospectives :

• La rétrospective est un moment privilégié pour l’équipe pour aborder ce qui a bien ou moins bien fonctionné durant l’itération
• Une attitude honnête et transparente sont des prérequis indispensables pour chaque équipier
• Les actions décidées d’un commun accord sont concrètes, mesurables et toujours affectées à l’équipe
• Eviter les défauts suivants
• Les vœux pieux : « Il faut réduire la durée des Stand Up »
• Les actions individuelles : « Le PO devrait mieux écrire les story »
• Les actions hors de l’équipe : « Il faut plus de serveurs »
• Timeboxer la durée de la rétrospective (par exemple 1 heure pour un sprint de 2 semaines)
• Identifier à minima une vraie action … et peut être seulement 1 … c’est déjà bien

Il existe de nombreuses façons d’organiser une rétrospective, je vous invite à lire le livre d’Esther Derby et Diana Larsen « Agile Retrospective. Making Good Teams Great », de participer à une session sur les rétrospectives lors des conférences à venir (par exemple celle à venir d’Émilie à Agile Grenoble 2011 le 24 novembre), ou d’utiliser le « Jeu du Père Noël » de mes amis Alchimistes Agiles pour apprendre à votre équipe comment faire une rétrospective, ou encore de lire ce wiki sur les rétrospectives.

Bonnes rétrospectives à tous

Depuis plusieurs années, la Scrum Alliance propose, moyennant finances, une formation de CSM (Certified Scrum Master) sur 2 jours. Petite  amélioration dans le process depuis 1 an, il ne suffit plus de payer les 2 jours de formation pour être certifié, il faut également remplir un questionnaire et obtenir une bonne note. Pour votre info, je connais quelques CSM qui étaient absents lors de leur formation en 2008 (pour cause de maladie) et d’autres qui n’ont pas eu la note minimale en 2010, mais qui sont référencés comme CSM par la Scrum Alliance  … bonjour le sérieux.

Après avoir cautionné ces pratiques durant de nombreuses années, Ken Schwaber s’est finalement fâché avec la Scrum Alliance et s’en est éloigné. En bon Business Man, il s’est empressé de créer Scrum.org et de mettre en place une nouvelle certification PSM (Professional Scrum Master) et ses déclinaisons multiples et variées. C’est vrai qu’il serait dommage de s’arrêter lorsque le pognon est à portée de main et que le Business Model est si facile à décliner (car qui oserait remettre en cause le jugement de Mr Schwaber).

Aujourd’hui, le PMI annonce un programme de certification Agile dont le nom ne sera révélé que plus tard (Cf. PMI Agile Certification). La lecture des raisons invoquées par le PMI pour se faire certifier me font hurler de rire … ou de désespoir … selon mon humeur du moment.

Bref, cela ne va pas simplifier la vie des donneurs d’ordre et des recruteurs, car ils avaient déjà du mal à comprendre que la certification ne garantissait aucunement la compétence agile de la personne certifiée, et maintenant il va falloir en plus qu’ils comprennent qu’il y a plusieurs certifications et qu’elles n’ont pas la même valeur (Le PMI indique clairement dans le document pourquoi sa certification à lui est meilleure que celle des autres … du grand n’importe quoi … et j’attends les arguments des concurrents qui ne devraient pas tarder à venir … pour continuer à ricaner !).

Mais après tout, rien n’oblige les sociétés qui organisent ces certifications a de la transparence et de l’honnêteté vis-à-vis des donneurs d’ordre … tant que ceux-ci payent rubis sur l’ongle la certification. Après tout, le business est prioritaire et les valeurs agiles censées être véhiculé lors de ces certification passent en priorité plus faible … nous parlons EUROS … soyons donc un peu sérieux.

Et bien je ne suis pas du tout d’accord, les valeurs passent avant tout autre chose, à bon entendeur, salut

Il y a déjà plusieurs articles sympa sur son site, et je vous recommande d’y faire un tour car on y trouve quelques retours d’expérience intéressants et beaucoup de vécu.

Bienvenue à Dibus

Tout d’abord j’avais hésité à me lancer dans cette initiative car je n’étais pas certain de réunir suffisamment de participants sur Grenoble et je savais que l’investissement commercial pour organiser des formations en Inter est important. Au final j’ai réuni 16 participants (un peu trop ? a twitté Claude) issus de 10 sociétés différentes et venus de Paris, Lyon, Aix-les-Bains et Grenoble … bref un réel succès !

L’importance du Product Owner est trop souvent oublié lors de la mise en place de l’agilité, trop souvent !

Cet oubli est souvent renforcé par la démarche des sous-traitant qui « vendent » de l’agilité au niveau de leur équipe de réalisation, puisque le client en demande, et cela sans regarder si ce client est prêt à jouer le rôle de Product Owner. Voir même, comme celle rencontrée à Toulouse en octobre dernier lors de l’Agile Tour 2010, qui assurent faire de l’agilité sans Product Owner … bref du grand n’importe quoi !!

Les participants ont particulièrement apprécié ces 2 jours puisqu’il ont donné la note de 3,5 sur 4 en terme de satisfaction globale, l’ambiance a été très agréable (même pour le formateur) et certains enseignements sont même déjà en cours d’application.

Les sujets abordés concernaient principalement le rôle du Product Owner et la façon d’obtenir un Product Backlog. L’aspect déroulement de la méthode Scrum n’était que peu abordé et limité à l’aspect contribution du Product Owner lors de l’itération.

Nous avons bien entendu beaucoup pratiqué les post-it et voici quelques photos sympa du résultat d’un dérivé de l’innovation game® « Product Box » et d’une story map en cours de réalisation par 1 des 3 groupes.

…

Il y a bien entendu également quelques points à améliorer et en bon agiliste, je les aurais réglé pour la prochaine session d’avril 2011 … si vous êtes intéressés faites moi signe.

Lors de mes formations j’insiste beaucoup sur cet aspect de la communication en physique que rien ne remplace vraiment, ni les webcam, ni Skype, ni simplement le téléphone … et pourtant, hier l’équipe que je coach a utilisé un outil entre Lyon et Paris … et pour être honnête c’était aussi bien que si nous avions discuté en face-à-face.

Bon d’accord, il ne s’agit pas de n’importe quel outil puisque je parle d’une « télé-présence » (Cf. photo ci-contre) qui permet à 6 personnes sur Lyon de parler à 6 personnes sur Paris comme si tout le monde était dans la même pièce (3 caméras filment les personnes 2 par deux – au milieu en haut – et projètent l’image sur 3 écrans géants de la salle distante).

La taille des écrans permet de voir les personnes à distance avec la même grandeur que si elles étaient dans la pièce, et franchement on se prête au jeu et on oublie que l’on est à distance.

Petit confort supplémentaire, un écran de PC peut être projeté sur le mur blanc sous les écrans (voir photo), donc on regarde face à soi (et donc ceux d’en face) lorsque l’on regarde ce qui est projeté … la classe mondiale !!!

Bon d’accord tout le monde n’a pas la chance d’avoir une téléprésence, d’ailleurs toute l’équipe à du marcher pendant 30 minutes pour rejoindre le batiment qui abrite cette salle … mais cela valait le coup.

La démo de l’itération s’est particulièrement bien passé et durant la rétrospective tout le monde s’est accordé à dire qu’il fallait réitérer cette expérience systématiquement … afin de réduire les problèmes de communication au sein du projet

Dernièrement j’ai eu l’occasion de jouer une demi douzaine de fois le jeu « Artistes et Spécifieurs » dans un contexte universitaire et professionnel, et cela m’a donné l’opportunité de confirmer un argument supplémentaire pour expliquer pourquoi l’agilité génére moins de bugs que les méthodes traditionnelles.

Bien entendu il ne s’agit pas d’une pratique d’ingénierie car le jeu n’en comporte aucune mais bien d’un effet très intéressant lié au processus même de l’agilité.

Lors de la première itération de ce jeu, les équipes n’ont pas vraiment de processus agile et sont mises sous pression par le temps très court de 10 minutes pour réaliser leur objectif qui est une copie d’un dessin prédéfini, et j’avoue contribuer voontairement à cette pression en égrénant les minutes puis les secondes restantes.

Ces derniers temps, j’ai constaté que tous les Artistes (les concepteurs) essayaient systématiquement de rajouter une forme supplémentaire dans les dernières secondes, car en effet, il y a toujours une dernière spécification qui est fournie dans la dernière minute et que les artistes n’ont pas encore eu le temps de comprendre correctement.

Cette dernière forme ajoutée au produit final est toujours fausse puisqu’il n’y a eu aucune analyse du besoin ni discussion avec les Spécifieurs sur le besoin réel. J’en profite alors pour leur faire remarquer qu’ils viennent d’ajouter un bug dans le produit et qu’en tant que client mon attention est entièrement attirée par ce défaut au détriment de ce qui pouvait être bien dans le reste du produit.

La discussion qui s’ensuit est très intéressante car il s’agit de savoir s’il vaut mieux faire plus et moins bien ou moins et mieux.

La plupart des participants pensent généralement qu’il vaut mieux faire plus et moins bien (on me parle de « réflexe » ou « d’apprentissage scolaire » mais sans savoir vraiment expliquer pourquoi) mais lorsque je leur demande si, en tant qu’utilisateurs, ils préféreraient un téléphone avec une icône figée et erronée sur l’écran ou un téléphone sans cette icône, la réponse est systématiquement la 2ème. Etonnant non ?

Lors des itérations suivantes, beaucoup plus agiles, ils arrivent généralement à résister assez facilement à la tentation d’ajouter des bugs à la fin et sont même beaucoup plus sereins vis-à-vis du temps qui passe, car ils savent qu’ils ont toujours un incrément du produit de disponible et donc peu importe le chronomètre et moi qui décompte les minutes.

En conclusion je suis conforté sur le fait que l’agilité introduit moins de bugs dans le produit simplement par le processus qui conduit à faire les choses étapes par étapes (en particulier de petites choses), en les terminant à chaque fois, et en s’affranchissant de la dictature du délai qui conduit à créer des bugs à la fin !

Article librement traduit de l’anglais : Article d’origine chez Pichler

Voici une liste de comportements qui partent d’une bonne volonté mais qui sont en fait des erreurs assez classiques lors de l’application de Scrum et qui influencent négativement la réalisation du produit, et qui de plus, lorsqu’elles sont combinées peuvent conduire à un échec cuisant du produit.

1. Etre trop pragmatique dans l’application du rôle de Product Owner : Pour essayer de répartir la charge de travail sur plusieurs individus ou un comité représentatif
2. Viser à maximiser la diffusion du produit : Pour essayer d’avoir un produit qui contienne un maximum de fonctionnalités et qui puisse être distribué à un maximum d’utilisateurs différents
3. Ne pas savoir dire NON : Pour essayer de ne pas désappointer les utilisateurs et mettre en péril le succès du produit
4. Collecter et détailler tous les besoins dans le Product Backlog lors de l’itération 0 : Pour essayer d’être exhaustif afin de réduire les incertitudes et les risques, et permettre de planifier précisément la réalisation du produit
5. Ne pas définir de priorités : Car de toutes façons, toutes les fonctionnalités doivent être dans le produit
6. Ne pas demander très tôt du feedback aux utilisateurs : Car de toutes façons vous savez ce qui est le mieux pour eux puisque vous leur avez posé la question il y a quelques mois
7. Planifier un livraison « Big Bang » : Pour essayer de surprendre vos compétiteurs, impressionner vos clients et dominer le marché en 1 seule nuit
8. Lorsque l’on approche du jalon de livraison, mettre des fonctionnalités supplémentaire « à l’arrache » au détriment de la qualité : Car ce n’est pas important de s’occuper de la « dette technique » maintenant, et de plus les utilisateurs aiment bien les produits avec plein de fonctionnalités même si elles ne marchent pas très bien, et puis il sera toujours temps de corriger les problèmes dans une version ultérieure.
9. Demander au Scrum Master d’agir comme un Chef de Projet : Car il est important que l’équipe soit dirigée pour donner son maximum et peu importe qu’elle explose en vol

Pour éviter ces erreurs, regardez vos projets à la loupe et cherchez ces comportements spécifiques, documentez vous en lisant des livres, des blogs et des articles, et participez à des conférences comme AGILE GRENOBLE 2010

J’avoue ne pas avoir été très bon dans ma réponse en live, et en bon Agiliste, je me suis fait une rétrospective le soir même pour identifier la cause du problème et définir une solution pour que cela ne se reproduise pas !

Cause : Méconnaissance de la définition des mots RIGUEUR et DISCIPLINE

Solution : Ouvrir un Dictionnaire

Parmi les différentes définitions existantes, voici celles que j’ai retenu :

DISCIPLINE

1. Ensemble de lois, d’obligations, qui régissent une collectivité et destinées à y faire régner l’ordre; règlement
2. Règles de conduite que l’on s’impose, maîtrise de soi, sens du devoir.

RIGUEUR

1. Caractère de quelqu’un, de quelque chose, qui se distingue par une exactitude, une logique, une précision parfaite.

Bien entendu les 2 définitions ne s’opposent pas, voir même peuvent être complémentaires.

Il apparaît clairement que la discipline a rapport au groupe, donc à l’équipe agile, et a pour objectif de définir des règles communes, que tous les membres partagent, pour assurer que le groupe fonctionnera correctement (i.e. : le respect des feux rouges et verts fait partie de la discipline des automobilistes pour que la circulation soit possible et la plus fluide possible).

La rigueur est plutôt individuelle mais contribue fortement à la qualité de ce qui est produit, ce qui est également très important lorsque l’on réalise une tâche, quelle qu’elle soit (i.e. : Un créneau bien fait est le résultat de la rigueur du conducteur dans les manœuvres réalisées).

CONCLUSION

A partir de maintenant, j’utiliserais le terme de DISCIPLINE pour tout ce qui a rapport aux règles liées à l’application de la méthode par l’équipe (i.e.: Respect du Daily Stand Up, Poker Planning en équipe, Pair Programming …) et le terme RIGUEUR pour ce qui a rapport à l’exécution des tâches (i.e.: Respect du Terminé, Correction du Build au plus tôt …)

Si je vous dis : super héros moustachu, chronomètre, sprint, rires, agilité et compétition. A quoi pensez-vous ?

Peut-être à votre prof de gym de 5ème, ou plus probablement à vous refaire une partie de SuperMario Kart sur votre console favorite. Et pourtant, la vérité est ailleurs… Mais pas si loin !…Pour être exact, la vérité était même dans la péniche… Car c’est bien une sorte de super héros moustachu, que nous avons reçu fin juin : un vrai champion de l’agilité venu éclairer la R&D.

Et même si d’ordinaire, un geek n’a rien d’une gymnaste asiatique, ce n’était pas de cette agilité dont il était question. Pendant 4 jours, notre éminent coach (Alexandre Boutin) est venu nous parler de notre méthode de développement (Scrum), qui fait partie des méthodes dites agiles (parce qu’elle permet au développement de s’ajuster au besoin du client).

Pendant ces quelques jours, vous avez peut-être noté la chaude ambiance qui régnait en salle Lumière, et pas seulement à cause de la clim’ en panne. Car notre formateur a utilisé la meilleure pédagogie qui soit : le jeu. En guise d’exemple de projets ? Faire en équipe des tas de chapeaux en papier en un temps record, gonfler le plus vite possible des baudruches à un diamètre minimum, construire des châteaux de carte sous la pression du chronomètre…. Pas si facile, et très formateur : l’air de rien, nous avons revu de manière très ludique chaque phase de la méthode, et précisé les différents rôles des intervenants du projet.

Et en particulier celui de ScrumMaster (mot à mot : le maître de la mêlée). Hein ? Quoi ? Une mêlée ???  Eh oui, la mêlée (scrum en anglais) correspond à ces petits groupes qui fleurissent tous les matins devant les tableaux de post-it à la R&D. Comme dans une mêlée, on se serre les coudes pour arriver à l’objectif à la fin du Sprint (3 semaines de boulot). Et le ScrumMaster est celui qui fait vivre le sprint :  il organise les réunions, s’occupe de la paperasse et veille à ce que la méthode agile soit fidèlement appliquée, afin qu’elle garde son efficacité.

Car nous avons appris une chose dans cette formation : chez nous, nous ne faisons pas assez de SHU (prononcer chou). Et même si on n’en a jamais assez (de SHU), il n’est pas ici question d’argent. Ni même de soupe (au SHU), en vue d’attirer un improbable extra-terrestre. Non, ce SHU là est asiatique, il vient des arts martiaux : il correspond à la phase où l’élève copie consciencieusement les gestes du maître. Plus tard, lorsque l’élève aura appris et compris (HA), il pourra modifier et ajuster les geste de son maître (RI).

Mais la route est longue et aujourd’hui, nous suivons encore les gestes du maître. Nous avons humblement repris les bases de Scrum et essayons de les appliquer au mieux. Et vous avez sûrement remarqué des changements : ils sont sur nos murs ! La nuée de post-its verts et roses est toujours là, mais elle est tellement mieux rangée. Et avez vous remarqué toutes ces jolies courbes qui ressemblent à celle du CAC40 pendant la crise ? Mais attention, contrairement au CAC40, plus ça descend vite et plus on est content : car c’est le travail qui nous reste à faire !

Les points clés de ce succès sont :

• L’utilité du nouveau produit et l’innovation technologique
• La tenue des jalons très courts et un coût final inférieur au budget initial
• Le fonctionnement en « équipe » avec une implication très forte des utilisateurs finaux.

Le choix d’une réalisation en mode agile a donc fortement contribué à ce succès car elle a permis :

• D’établir une réelle collaboration entre MOA et MOE
• D’obtenir une implication active des utilisateurs (toutes les 2 semaines pour donner du feedback sur l’incrément de produit réalisé)
• De faire émerger une équipe de réalisation performante et fortement proactive
• De piloter via une métrique simple et fiable : La vélocité !

C’est vrai que je ne cours pas après les prix, mais quand même, cela fait vraiment plaisir quand cela arrive, alors autant le célébrer un peu