Note de lecture : Scrum Shortcuts, par Ilan Goldstein

Note : 5 ; Succinct, parfois léger, mais souvent pertinent.

Apporter des réponses directes, tel est le but de ce petit opuscule. Il ressemble donc plus à un livre de recettes qu’à un « guide complet », pour autant qu’une telle chose puisse exister… Ce ne sont d’ailleurs pas des recettes, mais des antipatterns, ou des raccourcis comme l’auteur les appelle. Des raccourcis que je dois avouer souvent rencontrer (peut-être pas tous, mais beaucoup) et pour lesquels l’auteur nous propose des antidotes.

En lui-même, le livre est assez court, avec 162 pages, structurées en 10 chapitres, le tout compilant 30 des raccourcis susmentionnés. Le premier chapitre « Scrum Startup » couvre 3 raccourcis en une quinzaine de pages. Si le premier shortcut n’en est pas vraiment un mais une courte introduction plutôt bien faite, je jette mon dévolu sur le raccourcis n° 2 « fragile agile » reprenant quelques antipatterns d’interprétation erronées de Scrum. Bien vu !

Le second chapitre « attitude and abilities » couvre aussi 15 pages et intègre également 3 raccourcis. Je vais mettre fin maintenant à cet insoutenable suspens : ça continue comme ça jusqu’à la fin ! Le « masterful Scrum Master » relève correctement la posture du Scrum Master, mais l’auteur aurait aussi pu relever les antipatterns du Scrum Master chef de projet et du SM courroie de transmission du management ! Le raccourcis star est sans doute le « Rock Star or Studio Musician » qui pointe ce que doit être la dynamique d’une équipe Scrum. Sur le raccourcis dédié au linup, j’avoue ne pas être fan du T-shape développeur que je trouve une vue réductrice des compétences des membres d’une équipe.

Lire la suite

Note de lecture : The Scrum Field Guide, par Mitch Lacey

Note : 4 ; La promesse d’un accompagnement pour démarrer, mais au final des conseils biaisés et parfois critiquables sur la mise en place de Scrum !

Un livre pour vous accompagner durant votre première année de Scrum, telle est la promesse de Mitch Lacey ! Le livre est bien écrit, et l’auteur sait puiser dans une large connaissance de ses sujets. Chaque chapitre est construit de la même façon : d’abord une histoire, puis « le modèle » et enfin les clés du succès pour conclure. Dommage de ne pas avoir tenté de construire un fil rouge avec l’histoire, car c’est un contexte différent que l’auteur nous propose à chaque fois.

En lui-même, le livre n’est pas une lecture légère ; 350 pages découpées en 30 chapitres sous 4 parties. Rajoutez à cela 10 pages d’annexes pour décrire le framework Scrum. Les 18 pages du 1er chapitre sont en dehors des 4 parties. Il sert à introduire Scrum et fait plutôt bien son boulot. Notons que l’on y parle des valeurs et pratiques Scrum (à distinguer de celles du manifeste).

La première partie elle-même est constituée de 7 chapitres sur 95 pages. La douzaine de pages du second chapitre évoque l’embarquement des personnes sur le projet, la vision, le sentiment d’urgence, tout ça. J’ai trouvé cela bien peu convainquant. Au long des 15 pages du chapitre 3, l’auteur développe un modèle bien à lui, celui du « team consultant ». On s’écarte assez notablement de la Vision Scrum ici. Et pour des nouveaux venus, elle est facile à interpréter incorrectement, avec le mise en place de baronnies au sein de l’organisation ! 15 pages également sont dédiées à la gestion de la vélocité au chapitre 4. Pourquoi traiter ce sujet dès maintenant ? Mystère. Toute la logique du plan est en fait un peu mystérieuse pour moi. Rien de transcendant dans ce chapitre 4, par ailleurs. Mais les rôles de Scrum eux méritent bien d’être traités tôt. Mais on n’en dit presque rien ! Seules 9 pages leurs sont dédiées au chapitre 5. Décidément les priorités et les importances des sujets sont troublantes. On passe un peu plus de temps (mais à peine) sur la détermination de la longueur des itérations, où l’auteur nous propose une impressionnante « scoring key », à mon avis complètement inutile. Dans le même ordre d’idées, 8 pages à propos de la définition de terminé… bof, pas grave, n’est-ce pas ? Le chapitre se termine par un sujet qui tient à cœur à l’auteur : le « full time Scrum Master », sur lequel je suis en complète opposition !

Lire la suite

Note de lecture : The Elements of Scrum, par Chris Sims & Hillary Louise Johnson

Note : 6 ; Bien écrit et pertinent, mais aussi sans beaucoup de surprises.

Cet ouvrage est le grand frère du « Scrum, a Breathtakingly Brief and Agile Introduction », ou plutôt est-ce l’inverse ! Cela reste un ouvrage descriptif sur Scrum. Au moins celui-ci est-il vivant et bien écrit.

La première partie (introduction à l’agilité) est précédée d’un petit storytelling « a week in the life of a Scrum Team ». Il me rappelle le « Scrum in action » de Jeff Sutherland. Mais ici il n’a qu’un objectif de mise en jambe et c’est plutôt original et réussi. Le premier chapitre de cette seconde partie a trait (tarte à la crème des temps modernes) à la comparaison entre cycle en cascade et agile. On échappe toutefois aux lieux communs et le propos est même éclairé !

Le second chapitre (3ème en fait) introduit l’agilité (classiquement aussi) par l’écriture du manifeste agile. Là encore bien écrit et documenté il constitue une bien sympathique synthèse historique. Il n’est guère surprenant de voir un chapitre dédié aux principes et valeurs agiles lui succéder. Le propos sur les valeurs agiles n’est guère original, mais les 12 principes sont plus rarement évoqués. Ils intéresseront les nouveaux venus à l’agilité.

L’agilité est-elle rentable ? C’est ce qu’explore ce 5ème chapitre en comparant le déroulement en parallèle d’un projet en agile d’un côté et en cascade de l’autre. Cette histoire montre la valeur de l’approche agile d’un point de vue financier. Cela dit, ce chapitre aborde ce cas de figure de manière un peu simpliste.

Lire la suite

What is Scrum ? Par Henrik Kniberg

Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.

Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.

Optimiser l’utilisation des ressources

Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances…

Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !

Lire la suite

Agile Tour Lille – 15 octobre 2015

Agile Tour Lille 2015, j’y serais !

Les retours d’expérience sont rarement aussi passionnant qu’ils devraient l’être ! Ils me donnent trop souvent l’impression d’être pour une entreprise, un projet, l’occasion de vanter leur réussite. Une opportunité de raconter une histoire dont ils sont les héros et dont il sera difficile de tirer parti une fois rentrer chez nous.

C’est donc à partir de vécu, mais sous forme de « patterns » , de recettes venues du terrain, que je vous proposerais cette session qui n’a rien de théorique.

Voici le « teaser » de cette session.

Teasing, teasing…

Basculer en agile un très gros projet est un challenge, pour certains cela peut même apparaitre comme une ineptie. Pourtant c’est que le projet Linky a décidé de faire ! Un tel choix fait émerger des difficultés souvent absentes de projets plus petits : culture « cycle en V » omnisciente, grandes équipes, intégration dans l’architecture du SI, etc.

Mais si la route reste longue, les signes de succès sont réels. Plutôt que d’exposer l’histoire du projet, nous allons voir ensemble 12+1 leçons apprises, sous forme de « patterns » opérationnels : des recettes que vous ne trouverez dans aucun livre. Les patterns que nous vous proposons sont tous directement utilisables pour votre propre transition agile dès demain.

A bientôt

Rendez-vous le 15 Octobre à Lille !

Agile Tour Lille – 15 octobre 2015

Note de lecture : Scrumban, par Corey Ladas

Note : 8 ; Réflexions sur la transition de Scrum à Kanban, la vraie nature d’un processus agile et les moyens de l’adapter.

J’entends beaucoup de personnes parler du Scrumban, mais bien peu ont lu les essais de Corey Ladas compris dans ce volume, car il ne s’agit pas de ce dont ils pensent. Car avant tout, Scrumban est une compilation d’essais (souvent des reprises de posts de blog) sous la forme d’un livre au format très court, moins de 175 pages, celles-ci étant par elle-même assez courte, du fait de la mise en page. Mais court ne signifie pas sans valeur, car le texte de ce praticien très chevronné de l’agilité nous propose des réflexions très profonde sur le passage de Scrum à Kanban et la vrai nature des processus que nous utilisons !

Il n’y a pas vraiment de chapitres au livre, mais plutôt des espèces de thèmes qui sont au nombre de 7. Le premier d’entre-eux concerne Kanban lui-même. L’auteur y explore les mécanismes fondamentaux : le WIP et le flow, bien sûr, mais aussi la synchronisation et les buffers. On termine avec une réflexion sur la notion d’itération : pourquoi son avènement était inévitable, tout comme maintenant … sa disparition !

Le workflow est le second thème. C’est l’occasion de réfléchir sur la vrai nature d’un processus, en commençant par souligner qu’un workflow n’est pas une planification (les 2 concepts sont orthogonaux). L’auteur va plus loin en étudiant le PSP du SEI par rapport à Kanban et en mettant en relief les … similitudes ! Enfin l’auteur termine cette partie en dénaturant le kanban en le transformant en un processus à un ticket : c’est un cycle en « V » !

Lire la suite

En finir avec le stand-up ?

Le stand-up, ou scrum meeting, quelque soit le nom que vous lui donniez, est un élément prépondérant du framework Scrum (et d’autres approches agiles également). C’est lui qui permet de maintenir le cap de l’itération et de s’assurer que tout reste dans les clous de ce qui a été prévu en début de Sprint et de faire des choix ou des actions correctrices le cas échéant.

Vous connaissez sans doute le principe : à heure fixe chaque jour, les membres de l’équipe se rassemblent, souvent devant leur Scrum Board. C’est un rendez-vous court d’une dizaine de minutes (c’est pourquoi tout le monde reste debout) et chacun répond à 3 questions :

  • Qu’ai-je fait hier ?
  • Qu’ai-je l’intention de faire aujord’hui ?
  • Quelle problème ai-je rencontré ?

Tout est dans l’efficacité. Qu’est-ce qui pourrait mal tourner ?

De l’équipe à l’individu

Scrum insiste beaucoup sur la notion d’équipe et l’auto-organisation. C’est la raison principale pour laquelle il n’y a pas d’autre rôle qu’équipier au sein de l’équipe de développement. On doit travailler ensemble pour traiter une User Story et c’est ensemble que l’on escompte atteindre l’objectif de Sprint.

Et soudain, au stand-up, c’est à l’accomplissement individuel que l’on s’intéresse. Pas à la user story si on y a travaillé à 3, mais à la part que chacun y a pris. Une bonne façon d’induire les comportements individualistes dont on voulait se débarrasser en premier lieu. Plus souvent, cela conduit les équipier à s’approprier individuellement des items de backlog. Autant pour l’esprit d’équipe !

Mais ce n’est pas fini.

Les auteurs de Scrum nous suggèrent aussi de mettre à jour le reste à faire des tâches. En heures. Nous nous éloignons encore un peu plus du regard vers l’objectif de sprint. De la valeur ou de l’impact, nous portons maintenant notre attention sur la quantité de travail.

Du Scrum praticien au Scrum Zombie

La mise à jour du reste à faire induit aussi une autre logique : celle de la justification. Finalement notre logique du reporting, celle que nous avions sorti par la porte, est de nouveau rentrée par la fenêtre. Une logique encore agravée par les fameuses 3 questions. Car la première d’entre-elle est : « qu’ai-je fait hier ? ». Comme il s’agit de la première question, ce sera celle à laquelle on accordera le plus de temps et d’attention. Pourtant ce point est purement informatif, et ce sont bien les deux autres questions qui doivent nous aider à prendre des décisions et à nous organiser. Ce devrait être le but premier du stand-up. cette adhésion aveugle à une consigne est aussi la manifestation d’un autre phénomène : Le Scrum Zombie.

Le Scrum Zombie dévoile sa face hideuse lorsque la forme prends le pas sur le fond. Ses lieux de manifestation favoris sont la rétrospective et le stand-up. En focalisant sur la routine et la tyrannie du chronomètre, l’équipe finit par perdre de vue le contenu lui-même :

  • Quel intérêt offre l’information sur ce que j’ai fait ? En quoi cela va aider un de mes équipier à prendre une décision ? Cela va-t-il leur permettre de me donner un feedback qui va m’aider ?
  • Les informations sur les problèmes que j’ai rencontré ou sur ce que je compte faire peuvent-ils influer d’une manière ou d’une autre sur l’adaptation tactique de notre plan d’action ? Cela peut-il aider mes collègues à me proposer leur aide, ou à moi-même de proposer la mienne ?

Quand pour la dernière fois avez-vous pensé à l’une des questions ci-dessus en prenant la parole lors du stand-up ?

C’est bien, vous utilisez le stand-up pour synchroniser l’information au sein de l’équipe. L’information échangée a de la valeur. Hélas, même là le stand-up peut dégrader la qualité de l’interaction au sein de l’équipe !

Quand le stand-up retarde la circulation de l’information

Pour certains, le stand-up est le moment réservé pour parler avec les collègues afin de ne pas déranger ceux-ci durant la journée. C’est plutôt une bonne idée : ne pas déranger ses collègues et ne pas perturber leur concentration pour une information qui peut attendre.

Mais toutes les informations ne peuvent pas attendre. Il y a des choix de conception qui peuvent impacter ce que font vos coéquipiers si ils dépendent du module sur lequel vous travaillez. Certains refactoring assez larges entrainent des modifications qui ne sont pas anodines pour vos voisins. Vous avez pu obtenir une information importante pour l’ensemble de l’équipe et qui remet en cause un de vos postulats. On pourrait trouver bien d’autres exemples.

Dans les cas que nous avons cité, attendre pour informer le reste de l’équipe est le meilleurs moyen pour générer du gâchis et du délais, sans parler de la frustration générée…

Bref le stand-up se transforme parfois en mécanisme pour traiter l’information en mode batch au sein de l’équipe. C’est exactement l’effet inverse de ce que nous souhaitons obtenir.

Alors le stand-up, c’est mal ?

Nous n’avons même pas évoqué le stand-up détourné, par exemple comme outil de pouvoir. Même utilisé dans son but premier, le stand-up peut avoir des effets contre-productif. Mais qu’essayons-nous de faire réellement avec le stand-up, au-delà du folklorique petit cercle ?

L’un des principes majeurs de Scrum, c’est « inspect and adapt ». Le stand-up est notre boucle de feedback journalière, comme je l’avais déjà évoqué. C’est un point de synchronisation qui nous permet d’adapter continuellement notre plan d’itération à une maille qui n’est pas plus longue qu’une journée. Et ce mécanisme est réellement important.

Pourrait-il prendre d’autres formes ? Sans doute. Déjà, lorsque les situations sont tendues il n’est pas rare de voir des équipes opérer spontanément des stand-up deux fois par jour. Des équipes très matures peuvent aussi développer leur propre protocole de resynchronisation au fil de l’eau, rendant le stand-up inutile.

La forme la plus simple à mettre en oeuvre du protocole de synchronisation reste le point journalier. Quand il opère son rôle de synchronisation et d’adaptation du plan d’itération, il est une pratique importante de n’importe quelle approche agile. Mais pas quand la forme prends le pas sur le fond et qu’il se transforme en une pantalonnade ou en reporting.

Water – Scrum – Fall … la réalité d’aujourd’hui ?

Le constat

Oui, l’agilité gagne en popularité dans les organisations ! Du moins, apparemment. Les idées qui en sont à la base comme le « people centric » génèrent un réel intérêt. Aujourd’hui plus encore qu’hier, « agile » rime avec « Scrum ». Cet article met en exergue ce qui était déjà un soupçon fort, ce que j’appelle le Scrum « Canada Dry » dans mon article Scrum Shu Ha Ri :

  • La MOA rebaptisée « Product Owner ».
  • L’organisation matricielle, avec les développeurs devant partager leur temps sur plusieurs projets (je l’avait raté celle-ci)
  • Des itérations qui ne couvrent que partiellement le cycle logiciel
  • La « culture projet » où les équipes se font et se défont régulièrement au grée des projets.

Les organisations elle-même créent un carcan dans lequel inscrire un projet agile devient compliqué, à moins d’en pervertir la logique : logique budgétaire, silotage des activités, prédominance de la « logique document » et des releases parcimonieuses pour d’apparentes raisons économiques et culturelles.

Pourquoi ?

Ce constat met en relief un aspect quasi schizophrénique de l’adoption de l’agilité (d’où le titre de l’article). Celui-ci s’explique du fait de l’adoption des processus agiles par les praticiens qui tend à cloisonner l’agilité dans les équipes de développement, les équipes connexes restant attachées à leurs anciens processus. La réalité du « water-scrum-fall » se traduit par :

  • En amont : de lourds processus budgétaire et cadrage qui engagent les développements sur des besoins mal connus ou erronnés mais définis à l’avance. Non seulement ce passage de relai anihile la flexibilité que l’on attend des processus agiles, mais il démobilise les équipes.
  • Un développement « agile » mais au mandat amendé :
    • Moins de « cross-fonctionnalité » car les besoins sont traités ailleurs.
    • Pas réellement de « potentiellement déployable » car le test est déféré hors du sprint.
    • Pas d’interaction avec le client, car c’est l’objet du cycle amont.
    • Pas d’adaptation au changement car le plan est fixé quand le développement arrive à l’équipe.
  • En aval : Une ligne de démarcation importante stigmatisée par une « séparation des responsabilités » qui crée une situation de confrontation entre développement et opérations conduisant à des releases moins fréquentes. Ces deux équipes ont par ailleurs des objectifs différents : la réponse aux besoins du business pour l’un, la stabilité et le maintient en conditions opérationnelle pour l’autre.

Quelles recommandations ?

Pour l’auteur, on peut enclencher les bénéfices de l’agilité avec ce modèle à 3 bandes :

  • Faire maigrir la phase amont. La plus grande partie de la production de cette phase est du gâchis.
  • Rendre l’équipe de développement réellement pluridisciplinaire. Donc en intégrant les capacité d’analyse et la relation avec l’utilisateur.
  • Accroitre la fréquence des déploiements en aval.

The New New Product Development game, par takeuchi et Nonaka

Cette publication est connue pour être la source d’inspiration des créateurs de Scrum. Il fut publié en 1986 dans le Harvard Business Review et Hirotaka Takeuchi et Ikujiro Nonaka en sont les auteurs. Ils viennent du marketing et non du développement logiciel.

Les 6 caractéristiques du “Scrum”

On parle bien déjà de Scrum ! Et l’on prête à ce processus 6 propriétés fondamentales :

  • Une instabilité intrinsèque : le top management ne donne aux équipes qu’une direction générale avec un challenge très élevé à relever. Par ailleurs ce management donne une grande liberté d’action et d’interprétation. Cela crée une tension dans l’équipe à même de favoriser la créativité.
  • Des équipes auto-organisées. Elle apparait quand sont réunies 3 conditions :
  • L’autonomie : peu d’intervention du top management, son rôle est de fournir les ressources adéquates. L’entité fonctionne comme une startup.
  • L’auto-transcendance : L’équipe est dans une quête continuelle pour dépasser ses limites.
  • L’auto-fertilisation : une équipe pluri-disciplinaire renforçant leur connaissances respectives à l’image d’un impact hub.

Des phases de développement en chevauchement : le rythme de développement agit comme le poul de l’équipe. Pour permettre le développement selon ces phases courtes, il faut adopter le “sashimi system”. Le multi-apprentissage : il s’effectue à différents niveaux (individuel, collectif, entreprise) et dans les différents domaines d’expertise de l’équipe.

  • Le contrôle subtil : le management influe par petites touches sur l’équipe pour prévenir le chaos. Les auteurs identifient 7 axes d’action :
  • La sélection des membres de l’équipe
  • L’environnement de travail
  • L’encouragement à voir ce qu’il en est sur le terrain (où l’on rejoint le Lean…)
  • Une évaluation et des récompenses au niveau du groupe et non au niveau individuel
  • Gérer des différences de rythmes entre le début et la fin du projet.
  • Tolérer et anticiper les erreurs.
  • Encourager les fournisseurs à devenir eu-même auto-organisés.

La gestion du transfert de connaissance : Il est réalisé de manière osmotique, en réaffectant les membres de l’équipes sur d’autres équipes une fois le projet terminé.

Limitations et implication du management

  • On parle ici d’efforts extraordinaire, de journées de 60 heures ou plus … on est loin du “sustainable pace"…
  • Ce processus ne s’applique pas aux projets d’innovation disruptive
  • Il ne s’applique pas aux organisations centrées autour d’un "génie”.

Au niveau managérial, il faut 3 changements :

  • Un style de management promouvant ce processus.
  • Le management doit accepter que le développement des produits ne s’opère pas linéairement mais itérativement.
  • Le processus implique une suite d’essais / erreurs.

Les entreprises ont pour habitude de voir les projets innovants comme de nouvelles sources de revenus. Mais ils sont en fait avant tout des agents du changement. C’est donc avant tout un changement culturel.

Note de lecture : Essential Scrum, par Kenneth S. Rubin

Note : 8 ; La référence sur Scrum, à la hauteur des ouvrages de Mike Cohn

Le nom de l’auteur ne m’évoquait rien jusqu’à présent. Mais Kenneth Rubin n’est pas seulement un vieux routier de l’informatique et de l’agilité, il fut aussi le premier chairman de la Scrum Alliance ! La motivation de l’auteur était, pour cet ouvrage, de réaliser un texte de référence sur Scrum, que l’on puisse prendre avec soi et qui suffise lorsque l’on se pose une question sur la mise en œuvre de Scrum. Je vais certainement casser le suspens, mais c’est pour moi mission accomplie. En prenant un peu de recul, on peut constater que les points abordés tombent dans 3 catégories.

  • Les éléments et pratiques qui font partie du cœur de Scrum. C’est ce que l’on va trouver dans le Scrum Guide, par exemple, ou dans les 3 ouvrages de Ken Schwaber.
  • Les pratiques généralement admises dans la mise en œuvre de Scrum, mais qui ne font pas partie du framework officiel. Ce sont par exemples les pratiques empruntées à l’Extreme Programming. A ce titre, c’est ce que nous pourrons rencontrer dans l’excellent « Scrum from the Trenches » de Kniberg ou le livre en Français sur Scrum de Claude Aubry.
  • Les pratiques avancées qui peuvent compléter Scrum. Nous pouvons penser au Management 3.0 de Jurgen Appelo ou au Lean Startup…

Ce livre vise à couvrir complètement les deux premiers aspects et une bonne partie du 3ème. C’est un vrai texte pratique qui ne se limite pas à ce que l’on doit faire, mais surtout développe le « comment ». On s’appuie ici sur une prose de bonne qualité (je l’ai comparé à Mike Cohn tout à l’heure), mais aussi sur une abondante illustration. Le tout pèse benoitement ses 400 pages, c’est le prix à payer ! Au niveau du contenu, il faut compter avec 23 chapitres regroupés en 4 parties principales.

Le premier chapitre est une courte introduction sur la raison d’être de Scrum. Un peu ce que l’on retrouve dans « Software in 30 days », mais mieux écrit. C’est expédié en 10 pages.

La première partie regroupe 7 chapitres sur un peu plus de 150 pages et est dédiée aux « core concepts ». On commence très classiquement par un chapitre 2 justement nommé « the Scrum Framework » de 15 pages. Juste Scrum, rien que Scrum. C’est ce que couvre le Scrum Guide, rien à ajouter.

Ce sont aux principes agiles qu’est consacré le chapitre suivant. Par principes on entend : gestion du changement, taille des lots (WIP size) ou coût du délais, le tout comparé aux approches « plan driven ». Un chapitre un peu dense, dont les 30 pages ciblent plutôt le middle management et les décideurs. On reste encore beaucoup dans les principes avec les 17 pages du chapitre 4 consacré aux sprints : à quoi sert le timeboxing, les conséquence d’un changement en cours de sprint, etc. On retrouve un propos plus en phase avec les préoccupations du praticien. « requirements et user stories » qui est le titre du chapitre 5, c’est un bon condensé de ce que l’on trouvera dans l’ouvrage de Mike Cohn sur le sujet. C’est une sorte de MVP des stories pour partir du bon pied. Le chapitre 6 consacré au backlog continue sur cette lancée mais couvre également les cas particuliers de backlogs multi-équipe et autres spécificités. Les 20 pages destinées aux estimations sont aussi un condensé d’Agile Estimating and Planning de Cohn. Mais c’est très bon et suffisant pour démarrer. Le sujet des dettes techniques tient visiblement à cœur pour l’auteur, les 23 pages qui sont dédiées à ce point sont un peu en décalage avec les chapitres précédent. Le sujet est traité sous l’angle économique, qui distribue la nature de cette dette en 4 catégories.

La seconde partie est consacrée aux rôles de scrum, enfin à une couverture un peu plus large que les rôles officiels. On leur dédie 5 chapitres sur un peu moins de 100 pages. Contrairement à moi, l’auteur s’accroche à la séparation des rôles « by the book », avec un chapitre 9 consacré au Product Owner, complet et bien fait, où il est toutefois admis que l’ensemble des compétences demandées ne se retrouvent pas forcément en un seul homme… Le chapitre 10 est logiquement dédié au Scrum Master. Là aussi je diffère de l’auteur qui préfère le SM « professionnel » quite à se qu’il s’occupe de plusieurs équipes. Les 8 pages dédiées au sujet paraissent étrangement peu. L’équipe est traitée au chapitre 11. Il est beaucoup question de polyvalence au long de ces 16 pages, mais aussi de « profil en T » que je vois rarement évoqué. Le modèle a ses limites, à mon avis. Une dizaine de pages sont consacrées à la question du « team structure ». Sceptique sur l’intérêt du sujet de prime abord, j’avoue que l’auteur fait du bon boulot à opposer le « feature team » au « component team » et à évoquer le travail en équipes multiples. Le chapitre 13 qui clot cette partie est dédié au management. On sort un peu de Scrum pour aborder des questions qui sont reprises du Management 3.0 de Jurgen Appelo.

La troisième partie sort en grande partie du « Scrum by the book ». Elle est intitulée « planning » et couvre 5 chapitres sur 90 pages. Le chapitre 14 sert d’introduction et aborde sur 8 pages les principes économiques sous-tendant la manière d’aborder la planification agile. Le chapitre 15 sert de guide au reste de cette 3ème partie en reprenant le « multi-level planing » que Rallye Software évoquait déjà en 2006. Le chapitre 16 embraye donc sur la planification de portefeuille qui sort du cadre projet. Disons que le sujet n’est pas mal abordé sur une vingtaine de pages, bien qu’il lui manque un volet réellement pratique. Le chapitre 17 « envisonning » semble être un sujet qui passionne l’auteur. Il lui dédie même un début d’étude de cas, ce dont on n’a pas eu le droit avant. Et on y évoque aussi le release plan du projet et le « validated learning » du Lean Startup ! Ce sont 25 pages qui sont consacrés au release planning traité au chapitre 18. Je ne suis pas fan du sujet, mais il est fort bien traité en y intégrant plusieurs stratégies de contraintes.

J’aurais préféré voir cette quatrième partie « Sprinting » plus tôt dans l’ouvrage, car c’est quand même le cœur de Scrum ! 11 pages semblent suffire pour couvrir le Sprint planning au chapitre 19. C’est très concret, à la limite de la recette de cuisine, donc réellement exploitable. Le chapitre 20 « sprint execution » n’est pas facile à aborder car il doit traiter de ce qui se passe entre le début et la fin de Sprint. Bien sûr on y évoque le Daily Stand-up, mais aussi la communication dans l’équipe et la manière de se distribuer les tâches. Bon boulot, finalement. Très logiquement le chapitre 21 aborde la démo, pardon le « sprint review » ! Pas trop de blabla sur cette dizaine de pages et l’auteur y aborde aussi des points épineux comme le « rien à montrer » ou la démo de réalisations sous le capot ! Enfin c’est à la rétrospective que se consacre le chapitre 22. Le contenu reprend plus ou moins la trame d’Esther Derby, mais l’auteur consacre un peu plus de développement à la timeline. Pourquoi pas ? C’est mieux que de paraphraser un ouvrage déjà bien connu. Aller plus loin, c’est le thème du chapitre de clôture. C’est un peu mon « Scrum Ri ». Une bonne façon de terminer l’ouvrage.

De mon point de vue, l’objectif est atteint. Ce livre vise le même créneau que l’ouvrage de Claude Aubry : être un livre de référence sur Scrum. Je pense qu’il est un cran au dessus de son équivalent Français déjà fort honorable. Son seul réel défaut est peut-être que sa cible naturelle est constituée d’un public peu enclin à avaler un ouvrage de 400 pages.

image

Référence complète : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3

Essential Scrum: A Practical Guide to the Most Popular Agile Process

https://www.goodreads.com/book/add_to_books_widget_frame/0137043295?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on