Série - Compléments en ligne du livre Scrum (éd.3)

Fil des billets - Fil des commentaires

Premier chapitre

Je lance avec ce billet une nouvelle série qui a pour but de fournir des suppléments à mon livre Scrum.

Suppléments en ligne, c'est écrit sur la couverture.

supple_mentsenligne.jpg

Alors c'est vrai que mon blog avec plus de mille billets constitue un gros supplément en ligne et c'est que je réponds à ceux qui me demandent : "Où sont les suppléments en ligne ?"

Néanmoins je peux mieux faire ; je vais donc donner plus de suppléments. Je vais essayer en ajoutant plein de choses pour chaque chapitre : une carte avec la structure d'un chapitre, les liens cliquables, les idées qui me viendront... On verra si ça intéresse du monde (et aussi si j'ai envie de continuer).

Donc voilà je commence par le premier chapitre, qui s'appelle "Scrum dans le mouvement agile".

Structure du chapitre

Structure du chapitre 1

Liens

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

  1. Méthode agile par Scott Ambler : http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
  2. Manifeste Agile http://www.agilemanifesto.org et en français http://www.agilemanifesto.org/iso/fr/
  3. Le lien vers le blog de JIm Highsmtih, toujours instructif : http://jimhighsmith.com
  4. Biographie de Tom De Marco : http://en.wikipedia.org/wiki/Tom_DeMarco.
  5. L'enquête annuelle de VersionOne sur le développement agile http://www.versionone.com/state-of-agile-survey-results/, que je cite également dans d'autres chapitres.
  6. Le lien sur ce qu'est Scrum défini par la Scrum Alliance a changé depuis que j'ai réécrit le chapitre au printemps, il mène maintenant à cette page : http://www.scrumalliance.org/why-scrum.
  7. Le lien vers l'article original de Schwaber présenté à OOPSLA 96 : http://jeffsutherland.org/oopsla/schwapub.pdf.

Définitions

Depuis la première édition, je reprends la définition, traduite à ma sauce, de Scott Ambler d'une méthode agile :

Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui produisent, dans un délai contraint, un logiciel de grande qualité répondant aux besoins changeants des utilisateurs.

Complète mais un peu longue, je ne m'en sers pas dans mes présentations. Je note qu'Ambler l'a reprise et adaptée à son nouveau framework DAD.

Et celle de Jim Highsmith de l'agilité :

L’agilité est la capacité à favoriser le changement et à y répondre en vue de s’adapter au mieux à un environnement turbulent.

Courte. J'ai eu tendance à la compléter dans mes présentations en ajoutant une précision (s'adapter à temps) et un but comme "en vue d'enchanter ses clients" (Denning). Maintenant je ne m'en sers plus beaucoup.

Les valeurs

Je cite les valeurs (relatives) du Manifeste Agile, mais je ne donne pas une liste des valeurs propres à Scrum. Je reviendrai sur mes raisons dans un autre billet.

Changements dans les éditions successives

Ce chapitre, un des plus courts, faisait 7,3 pages dans l'édition 1, il est passé à plus de 9 dans la deuxième et presque 10 dans la troisième.

J'ai ajouté la partie "Les gens" dans l'édition 3.

Il comporte maintenant 2 dessins. Un nouveau dessin montre les gens.

Errata

  • Le lien Scrum Alliance ci-dessus n'est pas correct dans la version numérique.
  • Page 10 fin du § L'équipe, il est écrit Product Owenr au lieu de Product Owner.

Chapitre deux

Des sprints pour une release.

Ce chapitre aborde le cycle de développement (appelé aussi cycle de vie) d'un produit avec Scrum.

En résumé

Avec Scrum, un produit est développé selon une approche itérative et incrémentale. Le sprint donne le rythme auquel sont produites des versions partielles potentiellement livrables du produit. La release est la séquence de sprints à l’issue de laquelle le produit est livré aux utilisateurs.

Structure

Structure du chapitre 2

Changements dans les éditions successives

Ce que j'en disais pour le passage de l'édition 1 à l'édition 2.

Ce chapitre est passé de plus de 15 pages dans les éditions 1 et 2 à moins de 14 pour la 3. J'ai supprimé quelques parties qui m'ont semblé inutiles aujourd'hui et revu la formulation de nombreux paragraphes (du refactoring quoi).

Liens

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

Errata

Rien.

Chapitre trois

Dans la série Suppléments en ligne, voici le Product Owner.

Pendant les vacances, j'ai commencé une série de billets visant à apporter des informations additionnelles aux lecteurs de mon livre Scrum. Après le premier chapitre, le chapitre deux, voici le chapitre trois.

Ce chapitre est le premier que j'ai vraiment écrit. C'était en juin 2009. J'avais déjà publié plus de 500 billets de blog à l'époque, dont un nombre significatif évoquaient le Product Owner. J'avais commencé par ce chapitre parce que le PO était un sujet que j'estimais bien maîtriser. J'espérais vaguement réaliser mon livre en compilant des billets déjà écrits. Je me suis vite rendu compte que ça ne se passerait pas aussi facilement...

Structure du chapitre

Voici le plan de ce chapitre sur le Product Owner (clic pour agrandir).

Le Product Owner

Le résumé en fin de chapitre

Dans une équipe Scrum qui développe un produit, le Product Owner est le responsable du résultat auprès des parties prenantes. Il apporte sa vision à l’équipe et définit les priorités de façon à obtenir un produit apportant le maximum de valeur.

L’implication d’un bon Product Owner est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il donne l’impulsion à l’équipe. En faisant la promotion du résultat de chaque sprint auprès des utilisateurs, il fournit à l’équipe une reconnaissance qui la motive. En collaborant avec l’équipe, il fait converger les énergies pour maximiser la valeur ajoutée au produit.

Changements dans les éditions successives

Ce chapitre n'a pas énormément évolué depuis la première édition. Il fait toujours environ 15 pages.

Sur les sujets à discussion à propos du Product Owner, j'avais déjà pris le parti de présenter le PO comme membre de l'équipe, participant aux scrums quotidiens et s'impliquant avec les développeurs pour finir les stories pendant le sprint.

Dans l'édition trois, j'apporte des précisions sur son implication pendant le sprint (et avant le sprint aussi, j'y reviendrai dans le chapitre cinq sur le backlog). Le guide Scrum 2013 n'érige pas en règle la participation du Product Owner au scrum quotidien.

Ma position, celle que je défends dans le livre, est qu'il est souhaitable que la personne qui joue le rôle de Product Owner soit également membre de l'équipe de développement et cela en fait un participant à la réunion quotidienne.

Liens cités dans le chapitre

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

Autres lectures en relation

Errata

Rien pour l'instant.

Chapitre quatre

Dans la série Suppléments en ligne, voici ceux du chapitre "Le ScrumMaster et l'équipe".

Pendant les vacances, j'ai commencé une série de billets visant à apporter des informations additionnelles aux lecteurs de mon livre Scrum. Après le premier chapitre, le chapitre deux, le chapitre trois, voici le chapitre quatre.

Ce chapitre a failli être divisé en deux, un pour le ScrumMaster et le deuxième pour l'équipe. En 2010, je m'étais d'abord dit que je parlais de l'équipe dans tout le livre et qu'il n'était pas nécessaire d'en faire un chapitre dédié. Cependant, au moment de commencer l'édition deux, j'ai réfléchi au contenu de ce que je pourrais mettre dans un chapitre sur l'équipe.

En lisant ce qu'en écrivait d'autres (Lyssa Adkins, Tobias Mayer), je me suis rendu compte que ce n'était pas là que j'allais apporter le plus de valeur à mes lecteurs. Je perçois bien les relations entre les gens dans une équipe (notamment pour les avoir longtemps vécues), mais je pense que je n'ai rien d'original à écrire sur le sujet.

Donc ce chapitre s'appelle toujours le ScrumMaster et l'équipe, équipe dont je parle abondamment dans tous les chapitres.

Structure du chapitre

Voici le plan de ce chapitre sur le ScrumMaster et l'équipe (clic pour agrandir).

Le ScrumMaster et l'équipe, plan

Le résumé en fin de chapitre

Le ScrumMaster ne gère pas des ressources interchangeables, il guide les femmes et les hommes de l’équipe. Son rôle essentiel est de les faire progresser collectivement pour la réussite du projet.
Les méthodes agiles reprennent l’idée d’organisation sans hiérarchie autoritaire : on y parle d’équipe investie avec le pouvoir et l’autorité pour faire ce qu’elle a à faire, ou qui s’organise par elle-même. C’est une des différences majeures avec les méthodes traditionnelles. Elle est mise en pratique avec le ScrumMaster qui n’est pas un chef mais un facilitateur.

Changements dans les éditions successives

Ce chapitre a gagné deux pages supplémentaires dans l'édition 3, il fait un peu plus de 14 pages. Cette croissance est essentiellement due aux nouveaux dessins et schémas.

Pour le texte, l'ensemble a été refactoré ; j'ai ajouté un § sur l'équipe pluridisciplinaire et du texte relatif à la sociocratie.

Liens cités dans le chapitre

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

Autres lectures en relation

Errata

Rien pour l'instant.

Quiz rugby

Page 43 du livre, dans la photo 4.1, quel est le nom de l'arbitre, connu, et alors en pénitence en Fédérale 1 ?

Chapitre cinq

Dans la série Suppléments en ligne, voici ceux du chapitre "Le backlog".

Dans les éditions précédentes, le chapitre s'appelait "Le backlog de produit". J'ai revu le titre et plus encore le contenu.

Pourtant le backlog, ça a l'air simple, certains se disent que c'est juste une liste de stories. En fait, il y a quelques subtilités si on veut avoir un backlog vraiment utile pour les sprints.

C'est d'ailleurs le sujet de ma présentation à Agile tour Toulouse, intitulé "La culture du backlog" que de montrer comment passer du gros backlog monolithique aux petits bacs limités.

Structure du chapitre

Voici le plan de ce chapitre sur le Backlog (clic pour agrandir).

Le backlog

Le résumé en fin de chapitre

Le backlog contient la liste des futures réalisations de l’équipe, les stories. C’est l’élément pivot d’un développement avec Scrum qui permet de définir le produit et de faire la planification.

Cette liste unique des choses à faire, ordonnées par priorité, est au cœur de la mécanique de mise en œuvre de Scrum lors des sprints. Le backlog de produit est pour beaucoup dans l’élégance et la simplicité du cadre de développement que constitue Scrum.

Avoir un backlog bien entretenu est essentiel et cela passe par une collaboration poussée entre le Product Owner et l’équipe. La présentation du backlog en plusieurs bacs et l’identification des types de story y contribuent fortement.

Changements dans les éditions successives

Ce chapitre a été presque complètement réécrit dans l'édition 3. Il est passé à plus de 19 pages. Il avait 13 pages dans les éditions précédentes, il a donc bien grossi.

L'introduction est plus succincte. Le §5.2 sur les types de story a été revu, incluant le remboursement de dette technique.

Le §5.3 sur les parties du backlog est nouveau. J'évoquais seulement le bac à sable dans l'édition 2, alors que la présentation des 5 bacs court sur 8 pages dans cette dernière édition.

Liens cités dans le chapitre

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont, pour la plupart, cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

  • Le premier livre de Mike Cohn, sur les User Stories : User Stories Applied: For Agile Software Development – Mike Cohn, Addison Wesley 2004
  • What Color is your Backlog ? les idées de Philippe Kruchten résumées dans un article d’InfoQ

Autres lectures en relation

Errata

Rien pour l'instant.

Les suppléments des chapitres précédents

Chapitre six

Dans la série Suppléments en ligne, voici ceux du chapitre "La planification de release".

C'est dans ce chapitre qu'est abordé le sujet toujours délicat de l'estimation des stories en points. C'est aussi là que je présente la notion de vélocité et qu'on voit pour la première fois un burndown chart.

La planification de release est optionnelle dans Scrum. On n'en a pas toujours besoin. Cependant la plupart des équipes que je connais souhaitent en disposer, ce qui demande des efforts.

Structure du chapitre

Voici le plan de ce chapitre sur la Planification de Release (clic pour agrandir).

Planification Release, plan du chapitre 6

Le résumé en fin de chapitre

Une caractéristique importante des méthodes agiles est leur capacité à prendre en compte les changements. Cela implique que les plans sont remis à jour régulièrement. C’est particulièrement vrai pour le plan de release, qui est actualisé à chaque sprint.
Cette adaptation au changement s’accompagne d’anticipation : le plan de release permet de prendre des décisions sur le produit.

Changements dans les éditions successives

C'est un chapitre que j'avais beaucoup travaillé pour la première édition. Il faisait presque 20 pages. Il n'avait pas bougé dans la deuxième édition. Cette fois, je l'ai un peu dégraissé à environ 18 pages. Il a aussi été actualisé pour prendre compte les bacs présentés dans le chapitre précédent sur le backlog.
Le bac de culture rend finalement les choses plus faciles à comprendre pour la planification de release.

En plus de l'apparition des bacs, ce qui a changé :

  • le moment où l'équipe fait la culture du backlog (ma nouvelle traduction de backlog grooming) s'appelle la revue de backlog et je conseille d'en faire régulièrement plutôt que vers la fin du sprint,
  • l'estimation porte sur la taille des stories et non pas sur l'effort (c'est un retour à ce que je disais dans l'édition 1)

Liens cités dans le chapitre

Dans mon livre, les liens apparaissent souvent dans les notes de bas de page. Dans la version numérique, ils sont, pour la plupart, cliquables. Je les présente ici pour faciliter l'accès à ceux qui ont la version papier.

Autres lectures en relation

C'est finalement un sujet assez peu abordé. La référence reste le livre de Mike Cohn, Agile Estimating and Planning, que j'avais dévoré en 2005.

Errata

  • §6.4.2 Éviter de donner trop d'importance à la vélocité : le même texte se retrouve dans les 2 derniers paragraphes. Il est resté par erreur en dessous de "La vélocité est une mesure d'équipe, pas de personnes individuelles" pour lequel le dessin suffit.

Les suppléments des chapitres précédents

Chapitre sept

Dans la série Suppléments en ligne de mon livre Scrum, voici la réunion de planification de sprint, qui constitue le chapitre 7.

Ce chapitre fait partie de ceux que j'ai réécrits pour l'édition 3.

Structure du chapitre

Voici le plan de ce chapitre sur la planification de sprint (clic pour agrandir).

La réunion de planification du sprint

Le résumé en fin de chapitre

La planification du sprint est la première réunion du sprint, celle qui permet à l’équipe de s’engager sur le but du sprint et s’accorder sur les stories associées.
C’est aussi la plus délicate : son bon déroulement conditionne le succès du sprint. Pour la réussir, il convient de ne pas la voir uniquement comme une séance de planification, mais aussi comme un exercice collectif pendant lequel l’équipe apprend à s’auto-organiser et à partager la connaissance sur le produit et sur la solution pour le développer.

Changements dans les éditions successives

Ce chapitre a été complètement revu dans l'édition 3. Il a pris de l'ampleur, passant à plus de 17 pages (plus 10%).

Voici un aperçu des nouveautés :

  • les bacs et notamment le bac de départ, qui a un impact sur la planification du sprint,
  • le résultat de la planification est basé sur l'accord entre le PO et les développeurs, pas sur la vélocité du sprint précédent,
  • la définition de prêt, complètement redéfinie,
  • les conditions de départ d'une story pour le sprint comportant 3 parties,
  • nouveau : les conditions de réalisation,
  • nouveau : l'essaimage,
  • changement : je présentais des tâches non liées à une story (appelées tâches récurrentes), je recommande désormais de créer une story,
  • changement : je conseille plus énergiquement de ne plus estimer les tâches,
  • changement : je déconseille l'engagement sur des stories pour un sprint[1],
  • importance donnée au but du sprint, défini collectivement, non pas au début mais en fin de réunion,
  • rendre visuelles les conditions d'acceptation dans le tableau.

Liens cités dans le chapitre

Autres lectures en relation

Errata

Rien pour l'instant

Les suppléments des chapitres précédents

Notes

[1] L'engagement dans Scrum ne doit pas être pris au sens de Kant (il impose alors une obligation contre nature et va produire inexorablement de la dette technique, en plus de la frustration), c'est un engagement au sens tentative à faire de son mieux collectivement.

[2] Le seul billet invité que j'ai jamais eu sur mon blog. Merci Bruno.

[3] The Definitive Guide to Scrum: The Rules of the Game, publié après ma 3ème édition, en juillet 2013. On pourra lire sur ce sujet : Scrum 2013 et pablotages.

Chapitre huit

boiteameuhetable.jpgDans la série Suppléments en ligne à mon livre Scrum, voici le scrum quotidien, qui constitue le chapitre 8.

On dit aussi "daily scrum" ou "standup".

Structure du chapitre

Voici le plan de ce chapitre sur le scrum quotidien (clic pour agrandir).

Scrum quotidien, le plan

Le but du scrum quotidien

Cette fois je ne mets pas le résumé de fin de chapitre, mais l'objectif de cette pratique, présenté page 116 :

… En fait, son but principal est d’optimiser la probabilité que l’équipe atteigne les objectifs du sprint. Les moyens pour atteindre ce but s’appuient sur l’inspection et l’adaptation, ils consistent en :

  • Identifier les obstacles nuisant à la progression de l’équipe.
  • Préparer les discussions d’équipe pour éliminer ces obstacles.
  • Garder l’équipe concentrée sur l’objectif du sprint.
  • Évaluer l’avancement du travail pour le sprint en cours.
  • Préparer les travaux nécessaires pour finir les stories.

Changements dans les éditions successives

Ce chapitre a été sensiblement revu dans l'édition 3. Il fait une demie page en plus, passant à 13,6 pages.

Le changement essentiel porte sur la nouvelle façon de conduire le meeting : orientée stories comme alternative à la séquence habituelle des membres de l'équipe qui répondent aux trois questions. Elle est cohérente avec l'essaimage présenté dans le chapitre 7. Pour la faire pratiquer depuis quelque temps, elle s'avère efficace.

Il a été aussi complété de nouveaux conseils pratiques ayant fait leur preuve pour des équipes sur le terrain. Par exemple l'usage de la boite à meuh.

dessin On ne dit pas boite à meuh, on dit étable.

Globalement, l'accent est mis sur le message important pour éviter les dérives parfois constatées : le scrum quotidien n'est pas un point d'avancement pour les managers.

Liens cités dans le chapitre

Lectures en relation

Chapitre neuf

Dans la série Suppléments en ligne à mon livre Scrum, voici la revue de sprint, qui constitue le chapitre 9.

Revue et pas seulement démo. La démonstration ne constitue qu'une partie de la revue de sprint.

Le résumé du chapitre

La revue de sprint est l’occasion de faire partager les réalisations de l’équipe avec le reste de l’organisation. Elle permet de communiquer un avancement objectif sur la release. La visibilité apportée et le feedback reçu permettent d’augmenter les chances que le produit soit un succès.

Structure du chapitre

Voici le plan de ce chapitre sur la revue de sprint (clic pour agrandir).

La revue de sprint

Changements dans les éditions successives

Ce chapitre a été relativement peu revu dans l'édition 3. Il fait quand même une demie page en moins, passant à moins de 9 pages, ce qui en fait le chapitre le plus court des 20 de mon livre. Ce qui ne veut pas dire que c'est le moins important, la revue étant un événement majeur pour obtenir du feedback.

Les principales modifications portent sur :

Liens cités dans le chapitre

Ah, tiens il n'y a aucune note de bas de page dans ce chapitre. Pas de références, c'est peut-être parce que la notion de revue m'a semblé bien connue.

Lectures en relation

Note

[1] J'ai choisi l'option texte finalement.

Chapitre dix

Dans la série Suppléments en ligne à mon livre Scrum, voici la rétrospective de sprint, qui constitue le chapitre 10.

Quelques extraits du chapitre

…on peut comparer la rétrospective à la discussion sur « on refait le match », mais à laquelle participeraient uniquement les joueurs.

La rétrospective constitue un moment particulier où l’équipe s’arrête de produire, prend le temps de réfléchir et parle de ses expériences…

Le résultat essentiel de la rétrospective est qu’elle contribue à avoir une équipe plus soudée…

C’est la porte d’entrée dans l’amélioration continue[1], dans l’agilité, dans le travail en équipe...

Structure du chapitre

Voici le plan de ce chapitre sur la rétrospective de sprint (clic pour agrandir).

La rétrospective de sprint

Changements dans les éditions successives

Ce chapitre a pris une page de plus dans l'édition 3, il dépasse les 10 pages. Un peu plus de contenu et d'illustrations.

Les changements dans cette édition trois viennent d'abord de mon expérience ; en effet en tant que consultant qui accompagne des équipes, j'anime fréquemment des rétrospectives.

Ce chapitre a aussi été amélioré grâce à mes relecteurs. En particulier, je remercie Alexandre Boutin (à qui je dois la formule "démo rétro apéro") et Jacques Couvreur, l'alchimiste agile.

Liens cités dans le chapitre



J'aurais ajouté Retr-o-mat s'il avait été publié à l'époque où j'ai écrit le chapitre.

Lectures en relation

Note

[1] la rétrospective n'est pas la seule pratique d'amélioration continue : la visualisation des obstacles, leur résolution et l'analyse de leur cause racine en est une autre, pratiquée au quotidien ; c'est l'intraspective.

page 1 de 2 -