  |
(Anglais) Broché – 24 novembre 2015 Henrik Kniberg
|
Les informations ci-dessus, ainsi que la note des utilisateurs Amazon sont en provenance d’amazon.fr. Données valides au moment de la création de l’article.
Le livre, l’auteur
Ce livre est préfacé par Jeff Sutherland et Mike Cohn. Rien que ça !
L’auteur est un coach de la société Crisp, à Stockholm. Le site, et notamment le blog, présente de nombreuses ressources très utiles, notamment à un Scrum Master. Jimmy Janlén, un membre de la société, a, entre autre, produit un jeu de carte que j’utilise souvent en temps que Scrum Master ou Coach agile. Il me permet par exemple de proposer des thèmes pour des lean coffees ou des fire camps à des gens intéressés mais… sans beaucoup d’idée de thèmes de débats. Bien sûr, je m’en sert aussi pour plein d’autres de jeux…
Dans la préface, l’auteur nous explique que de nombreuses choses ont étées apprises depuis la première édition du livre une dixaine d’années au paravent. Depuis, la date de la première édition, l’auteur a été mentoré par quelques petits noms de l’agilité et du lean : Jeff Suthreland, Mary and Tom Poppendieck, Jerry Weinberg, Alistair Cockburn, Kent Beck, Ron Jeffries, et Jeff Patton. Juste les dieux laïcs que la profession ! No comment !
Cette seconde édition, nommée Director’s Cut, nous introduit au résultat des expérimentations de l’auteur au cours des huit années suivant la rédaction initiale…. et c’est toute la force du livre. Scrum n’est pas une méthode mais un framework. A ce titre, c’est à nous de créer une méthode qui entre dans le cadre fixé par Scrum. Il s’agit donc de créer/tester/améliorer continuellement nos pratiques. L’auteur nous présente dans son livre original (que je ne vous recommande pas !) le résultat d’un an d’expérimentations dans ce domaine. Dans cette édition (director’s cut), il à jouté énormément de remarques, de corrections, d’explications, qui permettent une meilleur appréhension de Scrum, de la démarche d’amélioration continue, et des pratiques “d’aujourd’hui”.
Notre avis
Si vous être junior en Scrum, ce livre n’est surement pas le plus adapté à votre cas (contrairement à ce qu’on peut lire ici ou là). En effet, il ne décrit pas Scrum en lui même, mais présente comment l’auteur l’implémente. De plus, certaines pratiques sortent du cadre strict de Scrum… C’est pourquoi je pense que ce livre est plus adapté au lecteurs ayant déjà une bonne pratique de Scrum et auront un avis éclairé sur le sujet (un profil plus expert sera plus à même de repérer les adaptations allant à l’encontre du guide Scrum et en mesurer les impacts).
Parmi les points pouvant heurter les “puristes” (sans parler les ayatollahs), on trouve :
- les technical stories ne sont pas des items de backlog produit comme les autres, et le PO n’est pas forcément tenu informé ou décisionnaire (p46),
- sélection de 5 amélioration de processus lors de la rétrospective (p86),
- rôle de “knowledge bridge” avec une position d’autorité pour la gestion des impediments du système (p87),
- des pauses entre les sprints (p91),
- confusions entre “time estimates”, “size estimates”, “story points”, et même adjonction d’un “focus factor” (notamment p98/99, mais dans tous le livre. Pourtant l’auteur à lu Agile Estimating and Planning et le recommande !),
- le PO n’est pas le “customer” (p101),
- le PO est un “chicken”,
- un rôle de “team lead”,
- le PO et des outsiders participant aux daily scrums.
Je trouve aussi qu’il manque cruellement le traitement des points suivants :
- pas un mot sur les “sanity cheks” (revue de périmètre) à proprement parlé (simplement une liste de choses à faire ensuite, et une liste de choses non prévue),
- pas un mot sur l’essaimage à proprement parlé(dans le sens création d’essaims -de sous équipe temporaires-).
Toujours sur le fond, la partie sur le sprint planning semble bien longue comparée aux autres parties. Ok, cet évènement peut être long si mal géré, demande pas mal de travail (en particulier au Scrum Master dans son rôle d’enseignant puis de coach) avant d’être pleinement efficace. Mais comme le dit l’auteur, si vous réglez tous les autres problèmes (en particulier les problèmes d’affinage -précédemment appelé backlog grooming- insuffisant), cette réunion se passe sans soucis et dans le respect de la “timebox” !
Sur la forme cette fois, c’est donc moins gênant, on remarque aussi que la numérotation de page n’est pas alignée avec le sommaire, et qu’il y a un problème récurent avec les puces !
En résumé, j’ai trouvé ce livre très intéressant dans sa version “Director’s cut”, car il met bien en évidence l’évolution des pratiques. Le fait qu’il n’explique pas directement Scrum le rend d’autant plus intéressant pour quelqu’un qui a déjà les bases de Scrum. Pourtant, les nombreuses divergences avec le canon Scrum m’empêchent de lui mettre une note plus élevée. Comme le disent les auteurs de Scrum, vous devez respecter l’intégralité du framework tel que décrit dans le guide pour prétendre “faire du Scrum” ! Et à ce titre, je ne suis pas sûr que l’auteur conduise ses équipes à “Scrumer”.
-
Note des utilisateurs Amazon
-
Note de JServices-IT
Mise en garde
Attention, livre en anglais.
L’article à été catégorisé “Etude de cas”, mais c’est plutôt un retour d’expérience, notamment de chez Spotify (mais pas que !).
