Pour être “in”, jouez la “retro”

Pour ceux qui ne seraient pas encore au courant à la fin d’un sprint agile on fait (on doit faire ! on devrait faire !) la rétrospective. Son but : mettre en évidence dans le contexte de l’itération que l’on vient d’achever : ce qui a marché, ce qui n’a pas marché, ce que l’on pourrait améliorer.

En voici une (il s’agit d’un mix d’extraits entre plusieurs clients, que j’ai anonymisés), histoire de rendre les choses concrètes. Vous pouvez la juger, la dénigrer, l’utiliser, etc.

Comment : on regroupe toute l’équipe (équipe, scrummaster, product owner). On fixe 4 grands axes : “les plus”, “les moins”, “les optimisations à envisager”, “le plan d’action”. Le plan d’action étant constitué par les optimisations que l’on souhaite mettre en oeuvre dès à présent, ou qui concerne un évènement pour le prochain sprint. Presque une antichambre : si nous envisageons régulièrement la même optimisation il faudra se décider à la basculer dans “plan d’action”. De même on peut rapidement glisser dans “les moins” les éléments du plan d’action que l’on aura finalement pas ou mal mis en oeuvre. Chacun évoque les points qu’il souhaite mettre en évidence. Je n’interviens (en tant que ScrumMaster) qu’à la fin, mais j’ai mon mot à dire et si je peux influencer dans tel ou tel sens je n’hésite pas mais je ne tranche pas.

Mes commentaires en italiques.

Les plus

- Backlog et stories plus complets (Stories plus complètes : au niveau des tests d’acceptation et/ou des scénarios de validation)

- Réorganisation de l’espace, salle, post-it, etc. (chez ce client un espace dédié a été aménagé pour l’agilité durant le sprint).

- Motivation de l’équipe (se passe de commentaire, mais j’explique qu’il est normal avec Scrum d’avoir des équipes plus motivées. Par contre il est essentiel de faire signe quand la motivation n’est plus au rendez-vous, et surtout pourquoi. Tout le monde ne peut pas être motivé 100% du temps.)

- Intégration des tests unitaires dans la notion de fini (se passe de commentaire)

Les moins

- Mauvais découpage des stories et des tâches (trop de dépendances !)

- Ponctualité (se passe de commentaire)

- Un expert externe peut interférer sur le périmètre du sprint sans faire partie de l’équipe. (il faudra résoudre ce point si celui-ci se répète, c’est un point de vigilance)

- Cadence pas assez régulière (coup de collier sur la fin). La validation des stories doit être régulière. (se passe de commentaire, un point du plan d’action est dédié à ce problème)

- Difficulté à concilier le focus du sprint et les demandes externes (il faut protéger cette équipe)

A envisager/optimiser ?

- Intégrer la revue de pair dans la notion de fini (c’est à dire que dans ce cas elle s’applique sur toutes les stories).

- Meilleurs jeux de données.

- Plus/Mieux utiliser des normes de codage/développement/nommage. (XP…le pair programming va suivre…)

Plan d’action

- Validation régulière des stories (pas de coup de collier final) (sur le prochain sprint -3 semaines- on se fixe les premières validations sur la seconde semaine)

- Chaque membre de l’équipe annonce aux autres au début du sprint le nb de jours qu’il estime pouvoir accomplir sur le projet (des soucis d’estimation liés notamment au temps “réel” passé sur le sprint)

- Chart température équipe (un des participants sort d’une formation Scrum, on lui a parlé d’un chart décrivant la courbe du moral des membres de l’équipe, il souhaite le mettre en oeuvre. je vais lui passer le relais en tant que ScrumMaster pour prendre du recul. C’est sa première “mission” de ScrumMaster : établir ce chart et surveiller le moral des troupes)

- préparation en amont de l’arrivée d’un nouveau membre de l’équipe (annoncée le mois prochain il faut préparer cette arrivée, la dernière fois on a perdu un temps fou !)

Voilà. La rétrospective dure une heure max. J’affiche au mur (radiateur) uniquement le plan d’action. Naturellement plus celui-ci sera concis plus il sera suivi.

The prick.

Images : Grotto in an iceberg, photographed during the British Antarctic Expedition of 1911-1913, 5 Jan 1911, http://www.flickr.com/photos/nationallibrarynz_commons/4078337967/

This entry was written by pablo, posted on October 17, 2010 at 1:52 pm, filed under méthodes agiles, scrum, XP and tagged retrospective, scrum. Leave a comment or view the discussion at the permalink.

Scrum : Ne faites pas de sentiments

Sous ce titre un brin provocateur je ne recherche pas l’affrontement. Au contraire c’est la neutralité que je souhaite mettre en exergue. Ne faites pas de sentiment : soyez totalement neutre.

Exemple, vous déployez Scrum au sein d’une organisation ayant pignon sur rue (disons un grand compte), avec des habitudes, des méthodes, des gens qui ne vous ont pas attendu pour délivrer un produit. Mais vous voilà qui débarque avec votre “agilité”.

Support, documentation, QA viennent aux nouvelles.

Qu’en sera-t-il des spécifications (sur lesquelles la documentation se fonde), qu’en sera-t-il des tests ? qu’en sera-t-il de la documentation ? etc. etc. Ma position est simple (ce qui ne veut pas dire qu’elle est facile à tenir) : voici l’état des lieux, voici nos objectifs dictés par la création de valeur, voici notre planning, voici le périmètre actuel, voici la méthode, etc. Vous estimez que nous devons intégrer ce niveau de documentation pour pouvoir vendre le produit ? Très bien, j’en fais part à l’équipe et au product owner (ou mieux : aller leur en parler !). Ce dernier décidera (probablement pas seul d’ailleurs, il est le représentant investi des pouvoirs d’un groupe de travail plus vaste) de la priorité à donner à cette création de valeur. L’équipe proposera peut-être d’intégrer ce point dans leur notion de “fini”. Il faudra probablement se demander si la documentation que vous réclamez est réellement porteuse de valeur. Pourquoi et comment.

Je n’ai pas la réponse, vous avez réponse, ils ont la réponse. (Le consultant dans sa pose la plus obscène s’écrient certains).

Nous affichons clairement nos objectifs, nos priorités, le contexte, le calendrier, la notion de “fini”, etc. On peut essayer des choses si on n’est pas sur de la bonne solution. On analysera vite si cela a fonctionné ou non.

Transparence, Inspection, Adaptation.

Je réponds finalement souvent : “je ne sais pas, qu’en penses-tu ?”. Mon rôle est d’accompagner, protéger, garantir, expliquer, faciliter, lever les ambiguïtés, mettre en évidence, etc (sur ma mission actuelle et qui sert de décor à ce post j’ai un rôle ambivalent entre le coach agile et le scrummaster, certains vont crier à l’hérésie, perseverare diabolicum). Que les arbitrages et les priorités soient clairs, basés sur les bons indicateurs, communiqués. Que le droit à l’erreur et à l’essai soient permis.

Je n’ai pas de parti pris, pas de sentiment, je suis neutre.

Il m’arrive aussi de dire : à telle date nous aurons un feedback assez conséquent pour estimer si cela marche ou si c’est un échec (sous entendu le déploiement de Scrum fonctionne-t-il ou est-il un échec ?). Nous prendrons une décision en fonction d’indicateurs clairs et transparents.

Transparence, Inspection, Adaptation.

Cela peut irriter. Et là tout dépend de la psychologie (ouh là là comme c’est galvaudé) du Scrummaster ou du coach agile. Est-ce pour cela que Ken Schwaber dans une célèbre vidéo renomme le scrummaster, the prick… (la piqûre, mais en argot : la bite, la queue…) ? Oui très certainement, nous pouvons irriter.

Attention, un dernier point, rester neutre ne veut pas dire ne pas encourager ou féliciter l’équipe, ou au contraire lui dire que l’on est surpris ou déçu dans certains cas.

The prick.

* photo by m4r00n3d

http://www.flickr.com/photos/mar00ned/193863350

This entry was written by pablo, posted on September 26, 2010 at 4:56 pm, filed under gestion projet, méthodes agiles, scrum and tagged adaptation, inspection, prick, scrum, transparence. Leave a comment or view the discussion at the permalink.

Rythme agile

Dans ce petit post je voudrais mettre en évidence un élément fondamental de la démarche agile : la notion de rythme. Une itération c’est comme une portée en musique : elle possède sa vélocité (4/4 par exemple : soit 4 noires dans une portée, ou 8 croches c’est pareil !, enfin vous voyez clairement l’analogie*). D’ailleurs si Ken Schwaber compare souvent Scrum & échec : règle simple, stratégie et jeu complexe ;  on peut faire de même avec la musique : 7 notes : des possibilités sans fin.

Bref il s’agit d’avoir une cadence. Au sein de celle-ci deux éléments importants : une certaine anticipation, une livraison effective. Je traduis là deux concepts mis en évidence par Mary & Tom Poppendieck** et propre à l’agilité : “délivrer aussi vite que possible”, et “décider aussi tard que possible”. Il faut savoir jongler pour éviter le trop tôt ou le trop tard (dans vos livrables, dans votre expression du besoin, etc.). Si vous n’êtes pas dans le rythme vous dégradez la qualité ou vous fournissez trop d’effort pour peu de résultat (ce que j’appellerai sur-qualité). Toute la gamme d’artéfacts proposée par l’agilité est là pour éviter cela : sprint, timeboxes, dailyscrum, user stories, etc.

Dans le schéma ci-dessous (cliquez 2 fois dessus pour le voir en grand…) j’essaye de mettre en évidence de façon macro les effets négatifs dans le cycle du projet. En rouge ce qui génère le plus de problèmes, en vert ce qui propose le plus de valeur, d’efficacité. Toute la difficulté résidant à viser les zones vertes sans tomber dans les zones rouges adjacentes. C’est souvent mal perçu mais je tiens à le préciser : l’expérience y joue un facteur clef, un novice pouvant jouer sur toute la longueur de la barre…

* en fait je vois tellement d’analogies entre musique et scrum (ou plus généralement l’agilité) que je vais y dédier un post…

** je vous recommande encore, toujours, l’excellent “Lean Software Developpement, an agile toolkit“

This entry was written by pablo, posted on September 19, 2010 at 7:51 am, filed under lean, méthodes agiles, scrum and tagged agile, lean, scrum. Leave a comment or view the discussion at the permalink.

fiche de lecture : Scrum, guide pratique, Claude Aubry

En ce début d’été j’ai pu le lire le livre de Claude Aubry. Je consulte régulièrement son blog (j’y retrouve deux sources d’intérêts : l’agilité ET le rock’n roll), lis ses tweets, et j’ai pu croiser celui-ci (assez brièvement) lors d’une présentation Scrum autour de Montpellier.

Ses posts (blog) sont généralement simples (dans le bon sens du terme) et efficaces. Je m’attendais donc à quelque chose du même acabit. Mais en me disant : encore un bouquin sur Scrum, sur l’agilité… Il y en déjà pas mal, et des bons, enfin, la littérature disponible sur le web est pléthore. Bref l’exercice n’est pas facile.

Mais disons le tout de suite, ce livre est une réussite et l’épreuve est passée avec brio.

Premier bénéfice évident :  un livre qui aborde et regroupe beaucoup d’informations concernant Scrum en français. Cela manquait et c’est très bien. Beaucoup de gens ne sont pas forcément à l’aise avec l’anglais et cela pouvait être une source de blocage ou de quiproquo (et donc de rejet de Scrum).

Deuxième évidence : Claude a sacrément creusé son sujet. Il ne mégote pas sur la qualité, mais aussi sur la quantité. Il a beaucoup de contenu. Beaucoup de sujets sont triturés, fouillés (théorie, pratique). Il a une approche très cadencée : thème A, point 1, point 2, point 3, etc. On va donc pouvoir se servir de ce livre comme référence, ce n’est pas un simple ouvrage pédagogique, d’initiation, d’introduction, c’est aussi un manuel (…hum… un guide ? ah oui. c’est ça).

Enfin Claude est un bon vulgarisateur (dans le bon sens du terme). Tout est expliqué clairement et semble couler de source. En cela j’imagine que Scrum l’a aidé.

Pour finir, la réussite du livre tient dans ces 3 facteurs. On a un ouvrage qui va permettre au débutant de se plonger facilement et entièrement dans Scrum, tout en demeurant avec le temps un manuel de références et de rappel des bonnes pratiques pour quelqu’un de plus avancé sur le sujet.

J’en recommande la lecture à tous (avec en fond sonore le dernier album 2009 des Black Crowes qui se transcendent avec l’âge : “Before the frost”).

Amazon ?

ps : En tant que lecteur j’apprécierai pour son prochain livre soit un recueil de retours d’expériences ; soit un approfondissement de la problématique de la conduite du changement à mener dans une organisation avec l’introduction de l’agilité et de Scrum.

ps 2 : Il trouve le moyen de caser Led Zeppelin dans son livre, j’admire.

This entry was written by pablo, posted on August 18, 2010 at 6:34 am, filed under méthodes agiles, scrum and tagged scrum. Leave a comment or view the discussion at the permalink.

les non-dits

Dans le meilleur des mondes il n’y aurait aucun non-dit. Qu’il s’agisse de la vie en générale, ou des projets informatiques (c’est le sujet ici !). Aucun non-dit est un idéal, mais cela n’arrive jamais (comme tous les idéaux). Il y a toujours quelque chose que l’on évite sciemment de dire à son client, son partenaire, son prestataire, etc. Généralement on cache une incapacité, une ignorance, une simple incertitude, etc. J’essaye, et je pense que cela est fructueux, d’éviter au maximum les non-dits. C’est toujours, toujours, toujours, un risque que vous faites courir inutilement à votre projet. Cela ne fait que complexifier la réalisation de celui-ci. Cela introduit un flou dans l’expression ou la résolution des besoins. Cela empêche de bien organiser le projet, etc. A partir du moment ou vous jetez une zone d’ombre sur le projet ne soyez pas surpris d’en subir les conséquences.

Sachant qu’au final souvent personne n’est dupe et que le non-dit a un prix : Amplification du stress ? Sur une partie que vous ne dominez pas vraiment mais sur laquelle vous vous êtes vendu ? Amplification du dommage, si vous laissez trainer un aspect technique ou fonctionnel que vous savez pertinemment défaillant ? Amplification de la charge ? l’un des membres de l’équipe n’est pas à la hauteur ? Il faut lui dire. Il devra faire l’effort de se mettre au niveau ou devra quitter le projet, mais dans ce deuxième cas, il aura été informé, et la blessure sera moins forte et plus compréhensible, etc, etc.

N’est-il pas évident qu’un jeune sans expérience répond oui à tout (oh ces CVs que je vois passer ! Messieurs les professeurs d’IUT, d’école informatique, ayez la décence d’expliquer à vos étudiants de ne pas mettre le glossaire de technipedia dans leur CV, ni -au passage- de se proposer Chef de projet des leur première année professionnelle), alors q’un vieux singe expérimenté dira plutôt non,  gage de confiance… (trouvez moi une maxime de Samuraï qui exprime cela en 4 mots).

Ne laissez pas trainer des anomalies, ne laissez pas trainer du code sale, ne laissez pas trainer des incompréhensions, des quiproquos, ils vous reviendront à la figure. Je sais que ce n’est pas simple, je suis le premier à me défausser parfois devant la tâche, mais vous aurez la surprise de voir se renforcer la relation que vous entretenez avec votre interlocuteur, de voir s’éclaircir la gestion du projet, de rendre les choses plus SIMPLES.

On peut rapprocher cela du courage des méthodes agiles. Rappelez vous que Lean demande de ne pas laissez trainer une anomalie. etc.

Le non-dit n’est pas nécessairement de votre fait. Essayez de persuader vos clients de ne pas en abuser, de comprendre où ils se cachent. Devinez les vrais enjeux qui se cachent derrière certaines demandes, derrière certains blocages, etc.

Joker pour les parties commerciales d’avant-ventes : pour ma pomme ces choses sont beaucoup plus simples depuis que je suis consultant (avec mes 2 associés chez SmartView), nous faisons du conseil : la vérité, la franchise sont donc essentielles et naturelles, et surtout je m’engage en mon nom, sur mon travail. Je ne m’engage pas sur une hypothétique équipe qui va réaliser le projet. Mais je ne peux pas jeter la pierre aux commerciaux des sociétés types SSII. Si la partie contractuelle n’est pas toujours juste, ni fair-play  : on va choisir le moins cher sans tenir compte de la qualité, il peut être compréhensible que la réponse ne soient pas toujours vraie. On comprend bien que de trop nombreux projets sont viciés dès la phase de vente. D’où à mon avis le succès des méthodes agiles aujourd’hui.

Je ne vous demande pas non plus de clamer partout et à haute voix tout ce qui se déroule sur le projet. Ce n’est pas le propos*. Je fais appel à votre intelligence pour bien comprendre où se situe la frontière.

Les non-dits dans les projets informatiques, c’est comme les secrets de familles, à la fin ça brise les gens, les dynamiques, les équipes, les projets.

* petite pub pour un ami.

This entry was written by pablo, posted on March 20, 2010 at 5:45 pm, filed under méthodes agiles and tagged agile, lean, non-dits, scrum. Leave a comment or view the discussion at the permalink.