Accueil > Méthodes Agiles > Retour sur le livre : Exploring Scrum, The fundamentals

Retour sur le livre : Exploring Scrum, The fundamentals

En rentrant d’une soirée Novedia organisée autour du thème de la rétrospective, je me suis retrouvé avec ce livre entre les mains : Exploring Scrum, the Fundamentals écrit par Dan Rawsthorne et Doug Shimp. Ayant découvert et utilisé Scrum depuis un peu plus d’un an dans ma mission actuelle, voici donc le premier livre que je lis sur le sujet.

Comme le titre en témoigne, ce livre s’articule autour des fondamentaux de Scrum via les trois parties suivantes :

« Les Individus utilisent des Pratiques (procédures) pour développer un Produit ».

Tout au long du livre, les deux auteurs complètent les définitions théoriques avec leurs expériences en tant que coach et les agrémentent d’exemples auxquels ils ont été confrontés. On évite ainsi un cours magistral sur l’utilisation de Scrum dans un monde idéal.

Je tenterai dans cet article de vous présenter les points importants qui m’ont marqué lors de cette lecture.

Les individus

Une des volontés de Scrum est de donner la priorité aux individus. C’est pourquoi dans cette première partie du livre, les auteurs commencent par définir :

–  les intervenants (membres de l’équipe, clients et intervenants extérieurs)
–  leurs rôles
–  leurs responsabilités
–  les valeurs qu’ils doivent avoir pour prétendre à l’agilité
–  leurs interactions

intervenants d'une équipe Scrum

Les auteurs expliquent notamment pourquoi, lors de l’introduction de Scrum dans une équipe existante, le chef d’équipe ne doit pas assumer le rôle de Scrum Master (SM) mais plutôt celui de Product Owner (PO). En effet, le chef d’équipe est en général la personne tenue pour responsable de la qualité du produit que son équipe développe, ce qui selon Scrum est exactement la définition du PO. De plus, il dispose d’une autorité hiérarchique sur le reste de l’équipe ce qui complique la « facilitation » des discussions internes, responsabilité inhérente au SM. La délimitation des rôles et responsabilités au sein de l’équipe est donc primordiale pour, entre autre, savoir qui a le dernier mot et garder une cohérence au sein de l’équipe.

En lisant cette première partie, j’ai également pu me rendre compte d’un autre phénomène que je pensais contre-productif : le « team swarm ». Le principe est le suivant : certains membres de l’équipe « se déplacent » de tâches en tâches pour aider là où cela est nécessaire. De l’extérieur, un tel phénomène donnerait l’impression que l’équipe est dissipée à cause du bruit constant dû aux conversations entre les membres de l’équipe. En réalité, on limite le nombre de tâches autorisées à être en cours pour forcer les personnes à travailler ensemble. L’équipe s’auto-organise donc au fur et à mesure pour fournir à chaque tâche les ressources dont elle a besoin jusqu’à sa complétion.  Ce phénomène présente deux avantages principaux : il permet de diffuser le savoir et il permet d’avancer plus vite en évitant les blocages (ou en les levant rapidement).

Le produit

La seconde partie du livre s’attaque au produit :

–  la description des différentes parties du backlog (c’est la liste de toutes les tâches). Ces dernières constituent souvent les différentes étapes de la vie d’une tâche
–  tous les processus qui gravitent autour comme les cadrages/études/spécifications techniques, les priorisations, etc.

Pour faciliter cette préparation/cadrage, les auteurs présentent la notion de « storyotype ». C’est en fait des modèles pour les types (stéréotype) de tâches (ou stories) les plus récurrentes. Ils permettent de se retrouver facilement entre les tâches et notamment d’avoir des définitions du DONE communes. Ces définitions sont importantes car elles sont gages d’une meilleure qualité.
Dans la pratique, certaines parties d’une tâche sont souvent oubliées : compléter la documentation par exemple. L’ajouter dans la définition du done (et rendre cette définition visible) permet d’éviter des oublis involontaires et améliore la qualité du produit.
C’est l’une des choses que j’aurai aimé voir davantage détaillée dans le livre : c’est vrai que dans la théorie, cette définition du done permet de garantir que tout ce qu’elle contient est fait avant que la tâche soit considérée comme terminée. Par contre dans la pratique, ce n’est pas toujours le cas. J’aurai aimé voir des exemples sur comment faire en sorte que les membres de l’équipes respectent cette définition. On pourrait imaginer forcer l’action de « cocher des cases » lors de la validation d’une étape. De cette manière, on validerait consciemment chaque étape.

 

Les pratiques

La dernière partie traite de certaines pratiques utilisées dans la méthode Scrum en proposant des trucs et astuces pour mieux les comprendre et les utiliser. On y voit donc la vision des auteurs sur le DSM (daily scrum meeting), la démo/rétro/sprint planning ou encore l’utilisation de tâches « d’enveloppes » pour anticiper les futures tâches dont on ne connaît pas encore le contenu (comme les bugs).

Les auteurs nous présentent également une méthode pour suivre la progression d’un sprint. C’est en fait un graphe qu’ils opposent au burn-down-chart (image ci-dessous).

monitoring Scrum : exemple taskhour burndown

 

Ce dernier représente généralement la somme des reste-à-faire (en heures) des tâches du sprint en fonction du temps. L’un des inconvénients est que cette somme dépend d’estimations (des reste-à-faire) des membres de l’équipe. Un autre est que le graphe peut présenter des pics (si une tâche est estimée bien plus complexe que prévue, son reste à faire augmente au lieu de diminuer).
Pour résoudre ces problèmes, les auteurs présentent un graphe basé sur les définitions du done (image du checklist Item burnUp plus bas). On ne représente plus le reste-à-faire mais le nombre d’étapes validées sur tout le sprint. Une étape correspond à un élément de la définition du done d’une tâche.

monitoring Scrum : exemple checklist item buildup
Ce graphe résout bien certains problèmes du burn-down-chart dont ceux cités plus haut. En revanche, selon moi, le burn-down permet, en plus de mesurer la quantité de travail fourni, d’avoir une idée du temps nécessaire pour terminer les tâches du sprint. Le graphe proposé par les auteurs ne permet pas ce genre d’interprétation puisque les étapes ne sont pas uniformes : elles ne demandent pas toutes le même effort/temps. Ce point n’étant pas abordé dans le livre, il faudra chercher la réponse ailleurs…

Pour autant, les auteurs anticipent d’autres problèmes dont un que je rencontre tous les jours et qui semble assez répandu : les difficultés de planning. Notre équipe travaillant sur plusieurs actifs, nous mêlons développement et maintenance (et supports…). Les plannings sont bousculés toutes les semaines (malgré l’utilisation d’enveloppes !) et on se retrouve sans réel objectif de sprint.

Pour résoudre ce type de problème, on nous présente ici l’intégration de la méthode Kanban dans celle du Scrum. L’idée principale est d’accepter de travailler sur une tâche (donc de la planifier) qu’au moment où l’équipe a les ressources pour la commencer immédiatement. Ainsi, on n’est plus préoccupé par les descopages ou par l’impossibilité de terminer toutes les tâches auxquelles on s’était engagé. Une tâche prioritaire qui arriverait en milieu de sprint pourra donc être commencée (presque) immédiatement sans bouleverser le contenu du sprint.

Conclusion

Pour conclure, j’ai trouvé ce livre à la fois intéressant et frustrant.
D’un côté, on se surprend à changer notre manière de penser. On pense davantage « agile » parce qu’on comprend mieux pourquoi Scrum est ce qu’il est. On y apprend avec du concret (nombreux exemples) et on collecte des conseils avisés à expérimenter sans tarder dans son équipe.
D’un autre côté, on se rend compte que pour qu’une équipe soit vraiment agile, tout le monde doit avoir cette même manière de penser. C’est là que ça devient frustrant : changer l’état d’esprit des gens peut s’avérer très difficile voire impossible.

Justement, ce livre est un bon agent du changement. Les auteurs ont essuyé les plâtres pour vous. Si vous en connaissez déjà un rayon sur Scrum et sur l’Agilité, il vous aidera en consolidant votre expérience avec ses exemples et trucs et astuces. Si vous avez vaguement entendu parler de Scrum ou que vous avez commencé à l’appliquer en entreprise, il vous aidera à y voir plus clair. Enfin, si vous faites partie d’une équipe qui migre vers Scrum, il vous aidera à faire les choses le mieux possible.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


quatre × 2 =