Vers un catalogue des odeurs de Scrum (M. Cohn 2003)

Je viens de tomber sur un article de Mike Cohn que j’avais conservé dans mes archives:

Toward a Catalog of Scrum Smells, publié en 2003. En grande partie, certains de ces éléments sont toujours d’actualité.

succeeding with agile

Voici l’article de Mike Cohn

Même avec certaines choses Scrum peut se tromper. Comme Scrum Masters véloce, notre responsabilité est de constamment garder un œil sur nos projets et de rechercher les petits problèmes avant qu’ils peuvent devenir de gros problèmes. Dans son livre Refactoring, Martin Fowler a introduit le terme « odeur » pour désigner quelque chose qui n’est peut-être pas bonne. Juste parce que quelque chose sent ne signifie pas qu’il y a un problème, cela signifie, cependant, qu’une enquête plus approfondie s’impose. Cet article est un premier pas vers la collecte d’un catalogue des odeurs de Scrum ; autrement dit, signes que quelque chose peut être mauvaise sur un projet Scrum.

Perte du rythme

Symptôme : les Sprints ne sont pas toujours de même longueur.

Discussion : Sur un projet Scrum bien exécuté, l’équipe établit un rythme naturel. Chaque sprint a la même longueur. Chaque sprint commence avec un Sprint Planning Meeting où sont discutées les exigences et le sprint prévu. Chaque sprint se termine par une revue de Sprint où l’équipe démontre un incrément de produit potentiellement livrable. Entre ces deux phases le rythme du projet est soutenu par une mêlée quotidienne (daily scrum). Si les sprints sont parfois de deux semaines et parfois de quatre semaines alors ce rythme naturel n’est jamais établi. Les Sprints alors commencent à être ressentis comme des unités arbitraires de temps avec des points de terminaison davantage  sélectionnés par des éléments extérieurs (peut-être politiques ou concurrentiels) plutôt que d’être conçus pour améliorer la productivité globale de l’équipe. Lorsque la durée du sprint est autorisée à varier les équipes ont alors plus de difficulté de choisir la bonne quantité de travail pour le Sprint Backlog, ce qui entraîne moins d’engagement à compléter tous les items du Sprint.

Bavardage des poulets (explications ici)

Symptôme : Les poulets participants au Daily Scrum sont autorisés à poser des questions ou formuler des observations.

Discussion : Au cours du Daily Scrum les seuls participants autorisés à parler sont les cochons (ceux impliqués au projet) ; poulets (autres participants au projet) peuvent assister et observer, mais ne sont pas autorisés à prendre la parole. Permettre aux poulets de parler peut être une pente glissante. Si un poulet est autorisé à faire un commentaire une fois (lorsque le commentaire est utile), comment pourrions-nous plus tard empêcher un poulet de commenter (lorsque le commentaire n’est peut-être pas utile) ?

Absence de cochons

Symptôme : Pas tous les cochons assistent à la réunion quotidienne Scrum.

Discussion : Lorsque  j’ai commencé à travailler il y n’avait pas de chose comme le « flex time». Toutes les entreprises avaient un horaire de départ et tout le monde devait être au travail à ce moment-là.  « Flex time », combiné avec les habitudes nocturnes des nombreux développeurs de logiciels, rend fréquent d’avoir certains membres d’une équipe arriver à 11:00, ou même plus tard. J’ai travaillé avec une équipe qui avait surnommé un programmeur « Capitaine Midnight » parce qu’il avait l’haditude de venir travailler vers minuit chaque jour. Tout cela peut rendre très difficile pour une équipe de se réunir pour un « Daily Scrum » tous les jours.

Cependant, une réunion quotidienne, l’avoir à la même heure et dans le même lieu chaque jour aide un projet à établir et maintenir son rythme. Si trop de cochons manquent la « mêlée quotidienne » , la réunion peut prendre trop souvent trop de temps ou dévie de la norme des trois questions. Les « bons » Daily Scrum ne devrait presque jamais dépasser quinze minutes et devra apporter presque toujours une valeur pour chaque cochon.

Oui, parfois nous aurons des délais précis qui sont si urgents et tellement imminents que nous pouvons être tentés d’ignorer une mêlée quotidienne. Et ce n’est pas grave. C’est quand la situation devient chronique, ou quand trop de cochons manquent les réunions que la situation commence à « sentir ».

Signatures persistantes

Symptôme : Les fluctuations sauvages visualisées sur les Sprint Burndown initiaux se perpétuent  sur les sprints suivants.

Discussion : Dans « Agile Software Development with Scrum »,  Ken Schwaber et Mike Beedle ont écrit que chaque équipe a une signature unique — certaines équipes apportent trop de travail au départ d’un sprint, d’autres trop peu, et ainsi de suite. Cependant, il est important qu’une équipe apprenne de ses derniers sprints.

Par exemple, supposons qu’une équipe de cinq a commencé le dernier sprint avec environ 600 heures de travail (le premier point sur leur graphique d’avancement sprint). Au milieu de ce sprint, ils ont réalisé qu’ils tentaient de trop faire, ils ont ensuite travaillé avec le Product Owner pour enlever 100 heures de travail. Maintenant, dans la planification du sprint suivant, encore une fois, ils veulent porter à 600 heures de travail. Ils ont besoin de prendre cela en considération et de répondre eux-mêmes pourquoi ils pensent qu’ils peuvent atteindre 600 heures de travail estimées pour ce sprint alors que l’estimation précédente était trop importante.

Au fil du temps, comme les équipes en savent plus sur elles-mêmes et leur projet,  leurs sprints burndowns devraient perdre ces variations sauvages qui peuvent avoir existé dans les premiers  sprints et commencent à se rapprocher un peu la ligne droite idéalisée.

Si cette tendance n’est pas évidente pour une équipe, alors elle manque des occasions d’apprendre de ses propres performances passées.

ScrumMaster assigne le travail

Symptôme : Le travail est assigné par le ScrumMaster plutôt que par l’engagement des développeurs.

Discussion : L’auto-organisation est l’un des principes fondamentaux de Scrum. Quand un ScrumMaster assigne le travail et qu’il « sape » les développeurs de leur responsabilité cela suppose que ceux-ci ne sont pas autorisés à s’organiser pour la réalisation d’un objectif.

Le vrai danger ici, c’est que même une affectation occasionnelle d’un ScrumMaster peut faire beaucoup de dégâts. Les équipes doivent se sentir totalement en contrôle de leur propre travail.

Le Daily Scrum est pour le ScrumMaster

Symptôme : Le Daily Scrum se ressent comme une mise au point du stratus  des membres de l’équipe pour le ScrumMaster (ex. réunion de chantier).

Discussion : Parfois le daily scrum  commence à se ressentir comme s’il n’existait uniquement pour le ScrumMaster. Vous verrez le ScrumMaster couvrant furieusement de gribouillis les notes au sujet de qui a « exécuté» ce travail et pourquoi une autre tâche n’a pas été terminée. Des réunions quotidiennes comme ça donnent le sentiment d’une  réunion de mise à jour des autres processus de développement.

Il y a deux principaux objectifs de la mêlée quotidienne et aucun n’est de fournir des informations de stratus au Scrum Master. Le but premier de la « mêlée quotidienne » est de fournir un mécanisme de coordination pour tout le monde sur le projet. Une fois par jour, il peut être très utile pour tout le monde d’entendre où tout le monde se situe.

Idéalement il y a beaucoup de discussions de couloir ou de conversations tout au long de la journée, mais aucunes qui incluent l’équipe au complet. Au cours de la mêlée quotidienne, tout le monde obtient une idée où tout le monde se situe. Le deuxième but de la mêlée quotidienne est pour chaque membre de l’équipe de prendre des engagements devant ses pairs. Quand un développeur répond à la question « Qu’allez-vous faire aujourd’hui? » celui-ci fait un engagement devant ses pairs, et non au Scrum Master.

Lors de la prochaine réunion si cet engagement n’a pas été rempli, ce n’est pas rôle du Scrum Master de dire, « Tatatata, Lucie, hier vous nous avez dit vous ferait ceci. » Si Lucie a déclaré que la tâche serait effectuée et que celle-ci ne l’est pas probablement, elle se sentira suffisamment mal. Elle sait ce qu’elle a dit devant ses pairs et elle sait que si elle n’a pas terminé en raison de la malchance ou au hasard, un manque d’effort, de la taille de la complexité de la tâche, ou d’une myriade de malentendus autres raisons.

Rôles spécialisés

Symptôme : Une équipe de projet a des rôles de travail fortement spécialisés ou des descriptions comme Architecte, Designer, DBA ou Testeur.

Discussion : Les équipes scrum doivent avoir une attitude « nous sommes tous ensemble».

Cela peut parfois être sapé si une équipe dispose de  rôles ou des descriptions de poste spécialisés.

Par exemple, si une équipe comprend un « testeur » dédié, cela peut donner au reste de l’équipe l’occasion de se dérober à la responsabilité de tester.

Avec les technologies hautement complexes du monde contemporain, il est trop simpliste de penser que tout le monde peut être un DBA et tout le monde peut écrire côté serveur du code J2EE ou  .Net. Une équipe Scrum ne doit pas nécessairement être composée entièrement de généralistes. Cependant, pour qu’une équipe de spécialistes puisse réussir,  chaque spécialiste doit accepter la responsabilité générale du système en tant que tout. « Je ne sais pas comment faire pour résoudre les problèmes d’Oracle plus compliqués dans notre projet, mais je vais faire tout ce que je peux pour aider, ce qui peut inclure simplement faire appel à un de nos spécialistes de base de données et le libérer pour résoudre des problèmes complexes.

2011-04-27_069

Vélocité fixe (ajout de Pierre)

Symptôme : L’équipe de développement s’engage sur une vélocité fixe pour chaque Sprint.

Discussion : La vélocité correspond à l’ensemble de la valeur des items de Product Backlog « Done » que l’équipe délivre à la fin d’un Sprint. Cette vélocité, mesurée par le Product Owner, permet à ce dernier de mesurer la consommation du Product Backlog ce qui lui permettra de projeter la date de livraison théorique du Product Backlog.

La mission du Product Owner est de préparer certains items du Product Backlog (fonctionnalités) pour les 2 Sprints suivants dans l’hypothèse où se dernier serait absent ou malade. Pour parvenir à cette projection, il utilise la dernière vélocité ou la vélocité moyenne pour proposer un Sprint Backlog à l’équipe de Développement lors du Sprint Planning 1. Ceci n’est qu’une information pour l’équipe, mais jamais une contrainte ou une nécessité : dans certains cas, les Sprints ne peuvent livrer de fonctionnalités.

Par exemple, une équipe de Développement « s’emballe » dans livraison de fonctionnalités à la fin de chaque Sprint pour contenter le client. Cependant, celle-ci n’a pas tenu compte des contraintes venant de l’intégration de chaque incrément de Sprint et elle a contracté une « dette technique » : l’architecture technique et fonctionnelle est en péril, les tests ne sont pas ou mal faits, la « definition-of-done » n’est pas respectée, le Product Owner a laissé faire. Dans ce cas (fréquent), le Product Owner doit arrêter le Scrum, le Scrum Master doit organiser une Rétrospective et discuter sur le stratus du projet et des solutions discutées ensemble et un plan d’action (ou Backlog) de sortie de crise constitué : faire venir un expert pour une revue de code, vider la bug liste, revoir l’architecture, faire appel à un coach, redécouper le plan de livraison, etc.…

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s