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

Fil des billets - Fil des commentaires

Chapitre onze

Dans la série Suppléments en ligne de mon livre sorti, pour la première édition, il y a 4 ans, voici la Définition de fini qui constitue le chapitre 11 de la troisième édition.

Le résumé en fin du chapitre

La définition de fini est la pratique qui permet d’obtenir le niveau de qualité attendu à la fin de chaque sprint, pour éviter d’accumuler de la dette technique.

et aussi

Une bonne mise en œuvre de cette pratique permet aussi de motiver l’équipe et de rassurer les parties prenantes.

Structure du chapitre

Voici le plan de ce chapitre sur la définition de fini (clic pour agrandir).

Définition de fini

Changements dans les éditions successives

Le chapitre fait exactement 12 pages. Il n'en faisait qu'un peu plus de 9 dans la version précédente, c'est dire qu'il s'est épaissi, en étant largement réécrit.

Il a même changé de nom : il s'appelait "La signification de fini" dans les éditions précédentes. J'avais choisi ce titre pour nommer cette pratique, afin d'éviter des phrases du genre : il faut définir la définition de fini. Mais bon finalement devant l'usage constaté, je me suis résigné à revenir à définition.

Les autres nouveautés de cette troisième édition :

  • fini selon le type de story,
  • fini pour une feature,
  • les stories de finition,
  • les critères de finition externes et internes,
  • la définition de prêt.

Je remercie mes relecteurs pour ce chapitre : Laurent Meurisse, Thierry Cros, Nicolas Deverge et Antoine Vernois.

Liens cités dans le chapitre

Lectures en relation

Chapitre douze

Dans la série Suppléments en ligne de mon livre, voici Adapter Scrum au contexte qui constitue le chapitre 12 de la troisième édition.

Le résumé en fin du chapitre

Scrum ne se vend pas en pack de 6. Sélection des pratiques et adaptation au contexte sont les deux mamelles de son application sur un projet.

Structure du chapitre

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

Chapitre 12, adapter Scrum au contexte

Changements dans les éditions successives

Ce chapitre fait 14 pages, comme dans l'édition précédente. Si la taille n'a pas changé, le contenu a subi des mises à jour substantielles.

Il a été ajusté pour être plus cohérent avec le chapitre 18 sur la transition agile : tout ce qui avait trait à la transition d'une organisation plus qu'au projet/produit y a été déplacé.

Toute la fin du chapitre a été revue. En particulier, un nouveau paragraphe porte sur Introduire du Kanban dans le Scrum.

Liens cités dans le chapitre

Lectures en relation

Chapitre treize

gary_langue.jpgLe chapitre 13 de mon livre Scrum s'appelait "De la vision aux stories" dans les deux éditions précédentes. Dans cette nouvelle édition, il devient "De la vision aux features", les stories ayant été poussées dans le chapitre suivant.
Il a été presque entièrement réécrit, pour incorporer les nouveaux outils du Product Owner, ceux que j'ai présentés le mois dernier lors du ScrumDay 2014.

Je me souviens, j'étais en train de finaliser ce chapitre il y a juste un an pour le pont du premier Mai. J'en profite pour remercier ceux qui m'ont bien aidé à l'époque, par leurs conseils et leur feedback : Nicolas Deverge, Pablo Pernot, Laurent Meurisse, Romain Couturier et Jean Lestang. J'espère que je n'oublie personne.

Le résumé en fin du chapitre

Il donne une grande place à l'Impact Mapping.

Scrum permet de bien développer le produit demandé par le Product Owner. Pour développer le bon produit, celui qui répond au but défini par les parties prenantes, l’Impact Mapping apporte une vision stratégique et permet d’aligner le développement sur des impacts métier. Pour un nouveau produit, l’Impact Mapping, accompagné de quelques Innovation Games, contribue à la constitution d’un premier backlog, constitué de features.

Structure du chapitre

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

De la vision aux features

Changements dans les éditions successives

Ce chapitre fait 17 pages, un peu moins que dans l'édition précédente, mais pratiquement tout a changé.

J'ai largement introduit l'Impact Mapping et les Innovation Games, et un peu le Lean Startup.

C'est aussi dans ce chapitre que je donne le plus d'exemples tirés de Peetic. Peetic, une idée de Pablo. D'ailleurs, avec Pablo, nous avons prévu de nous voir en mai, pour enrichir les artefacts de Peetic, qui sont à disposition de tous.

Grâce à ces exemples animaliers, j'ai réussi à caser, dans la partie Personas, une photo de Gary, le basset hound de mon fils dont j'ai la garde de temps en temps, et de Suissi, mon chat préféré. Hé hé.

Gary les beaux yeux

Liens cités dans le chapitre

Il y en a beaucoup dans ce chapitre !

Lectures en relation

C'est probablement sur les idées de ce chapitre que j'ai passé le plus de temps depuis la publication de la troisième édition (j'aime bien essayer les nouveautés et ce n'est pas en restant sur Scrum de base que je vais en trouver…)

Que ce soit avec mes clients ou dans les conférences ce sont sur ces sujets que se porte mon intérêt. Ils font désormais partie de ma formation Product Owner, et dans une moindre mesure ma formation Scrum.

Depuis la publication de l'édition 3, je me suis intéressé au Running Lean d'Ash Maurya et maintenant je pratique beaucoup le canevas.

Impact Mapping, Running Lean et les jeux agiles sont aussi au cœur d'une initiative de Stéphane Langlois, dont je vous parlerai bientôt : Gymkhana.

Chapitre quatorze

Le chapitre 14 de mon livre Scrum s'appelle "La story et ses tests d'acceptation". Dans cette nouvelle édition, le titre a légèrement changé, car le chapitre inclut désormais la présentation des stories.

Il a été presque entièrement réécrit, notamment pour incorporer des nouveaux outils du Product Owner, comme ceux que j'ai présentés le mois dernier lors du ScrumDay 2014.

Le résumé en fin du chapitre

Plutôt court…

Le test n’est pas une activité réservée à la fin des développements. Avec les méthodes agiles, les tests d’acceptation sont passés à chaque sprint.

Associés aux stories, ils guident le développement, servant de spécification par l’exemple.

Structure du chapitre

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

Plan du chapitre 14

Changements dans les éditions successives

Ce chapitre fait plus de 15 pages, soit beaucoup plus que dans l'édition précédente, où il n'en faisait qu'une dizaine. Cela est dû au déplacement de la partie story dans ce chapitre.

Parmi les nouveautés : Story Map §14.1.2, décomposer les features (MMF) §14.1.3, passage des tests au plus tôt §14.3.3. La partie Conseils §14.4 a été aussi largement remaniée.

Liens cités dans le chapitre

Il y en a beaucoup dans ce chapitre !

Lectures en relation

Chapitre quinze

La troisième édition de mon livre Scrum a été publiée il y a un an. Depuis, plus de 2000 exemplaires ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne.

Voici ceux qui portent sur Estimations, mesures et indicateurs, le chapitre 15 de la troisième édition.

Le but du chapitre

Ce chapitre présente les indicateurs d’un développement avec une méthode agile et montre comment les obtenir, avec quelles mesures et à partir de quelles estimations.

Le résumé

Il figure page 226.

Les mesures agiles sont différentes. Elles diffèrent dans leur nature avec l’importance donnée aux résultats visibles (vélocité calculée avec les stories finies). La vélocité repose sur des estimations, faites de façon relative, sans unités. Les indicateurs, élaborés à partir des mesures, sont utiles pour le suivi des plans ; ils servent aussi à l’équipe pour qu’elle évalue ses progrès et améliore ses pratiques.

Structure du chapitre

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

Estimations, mesures, indicateurs le plan

Changements dans les éditions successives

Ce chapitre fait maintenant 14 pages, soit beaucoup moins que dans les éditions précédentes, où il en faisait plus de 18. J'ai élagué pour recentrer sur les quelques indicateurs essentiels.

J'ai aussi revu les notions présentées dans §15.1 sur l'estimation de la taille et de la valeur :

  • je parle de difficulté intrinsèque plutôt que d'effort (employé dans l'édition 2) ou de complexité (on parle souvent de points de complexité, pas moi),
  • j'expose mon scepticisme sur les estimations de la valeur, préférant des mesures sur les impacts attendus (voir le chapitre 13).

Comme indicateur, j'introduis le diagramme de bacs cumulés (empilés), en complément à la notion de bac à stories (voir le chapitre 5).

Ce que je changerais si j'écrivais une édition 4

  • J'approfondirais l'idée, déjà évoquée, de compter plutôt que d'estimer, dans le sillage du mouvement #noEstimates. Pas d'estimation, mais des mesures et des indicateurs quand même.
  • Je proposerais un indicateur permettant de suivre l'avancement sur les features (pas des stories) dans un cadre contractuel.

Liens cités dans le chapitre

Lectures en relation

Chapitre seize

La troisième édition de mon livre Scrum a été publiée il y a un an. Depuis le lancement de la première édition, près de 10.000 exemplaires ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne.

Voici ceux qui portent sur Ingénierie du logiciel, le chapitre 16 de la troisième édition.

Ça tombe bien ce chapitre, je me remets au code en ce moment. Sous l'impulsion de Stéphane, j'essaie de développer des applications Web avec Meteor. Je commence mon apprentissage en esquissant, en binôme avec Stéphane, un site pour le Klub de lecture d'Agile Toulouse.

Le résumé

Il figure à la fin du chapitre, page 237.

L’usage de pratiques d’ingénierie du logiciel est obligatoire pour une équipe Scrum qui développe un produit logiciel.

Les pratiques de développement venant d’Extreme Programming comme l’intégration continue, le développement piloté par les tests et la programmation en binôme s’intègrent bien dans le cadre Scrum.

Avec Scrum, l’équipe fait de l’architecture évolutive et de la conception émergente. L’objectif de ces pratiques d’ingénierie est de limiter le nombre de bugs et la production de dette technique.

Structure du chapitre

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

Scrum et l'ingénierie du logiciel

Changements dans les éditions successives

Ce chapitre est passé de 8 pages dans l'édition 1 à 9 dans l'édition 2 et plus de 10 pour l'édition 3. C'est dire que l'importance que je donne à l'ingénierie du logiciel ne diminue pas.

Grâce à la relecture de Nicolas, les différentes pratiques présentées ont été actualisées. J'ai aussi complété la partie maintenance du logiciel, en précisant la façon de gérer les bugs avec Scrum.

Ce que je changerais si j'écrivais une édition 4

Si j'écrivais une édition 4 dans quelque temps, en supposant que j'aie poursuivi mon apprentissage de JavaScript, alors je mettrais des exemples de code que j'aurais écrit moi-même. Je pourrais aussi exposer l'impact de ces nouvelles technos comme Meteor sur la façon de développer agile, avec du Lean Startup.

Liens cités dans le chapitre

Lectures en relation

Chapitre dix-sept

Depuis son lancement, plus de 10.000 exemplaires de mon livre Scrum ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne.

Voici ceux qui portent sur Scrum et les outils, le chapitre 17 de la troisième édition, qui a été publiée en juin 2014.

Le but du chapitre

L’objectif de ce chapitre est de vous parler de tous les outils qui aident à faire ce qui a été présenté dans les chapitres précédents. Applications informatiques, mais aussi des jeux, des tableaux physiques et, bien sûr, des post-it.

Le résumé, extrait

Le succès d’une équipe passe par son plaisir au travail. Le jeu est l’outil essentiel qui y contribue.

Structure du chapitre

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

Scrum et les outils

Changements dans les éditions successives

Ce chapitre a été complétement changé dans l'édition 3. Il faut dire que c'était le chapitre le plus critiqué. On m'avait en particulier reproché d'y parler trop d'iceScrum, "mon outil". C'est fini, iceScrum n'est définitivement plus mon outil, s'il l'a été un jour.

Donc j'ai tout refait en m'efforçant d'être concret et pratique.

J'ai profité de la réécriture pour faire plaisir à mes lecteurs en ajoutant plein de nouveaux dessins de Patrice. Il y en a six dans ce chapitre.

Liens cités dans le chapitre

Lectures en relation

Chapitre dix-huit

Le chapitre 18 de mon livre s'appelle La transition à Scrum. Les chapitres précédents ont traité de la mise en place de Scrum au niveau d'une équipe. Celui-ci évoque les impacts au niveau de l'organisation.

Le sujet "Scaling Agile" est devenu à la mode, c'était par exemple le thème de l'Agile tour Montpellier. C'est devenu un sujet fourre-tout, qui regroupe des préoccupations bien différentes. Dans mon livre, j'ai choisi de différencier l'Agilité à grande échelle pour des gros projets, qui fait l'objet du chapitre 19, de l'Agilité au niveau des organisations, ce chapitre.

Pour mes lecteurs, voici le supplément en ligne au chapitre 18.

Le but du chapitre

La transition d'une organisation à Scrum, sa transformation agile, cela pourrait faire l'objet d'un livre entier. Le but de ce chapitre est de donner, plus modestement, des pistes pour diffuser Scrum au-delà de l'équipe.

Structure du chapitre

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

Le plan du chapitre 18

Changements dans les éditions successives

La taille de ce chapitre a été légèrement réduite dans cette troisième édition. Il fait une douzaine de pages. Mais cette diminution est due à la suppression de la carte heuristique qui tenait sur 2 pages dans les éditions précédentes. Cette carte montrait comment j'évaluais les pratiques de mise en œuvre de Scrum; sa suppression vient du fait qu'elle n'était pas très lisible et qu'aussi j'ai changé la façon d'évaluer, moins axée sur les pratiques.

Cela mis à part, le chapitre a été enrichi avec l'évaluation du contexte des organisations, a été "refactoré" pour être pus lisible et enrichi avec des références aux nouveautés apparues dans le domaine de la transformation agile.

Liens cités dans le chapitre



Pour aller plus loin

En relisant le chapitre pour écrire ce billet, je le trouve finalement pas mal. Si je l'écrivais maintenant je donnerais juste plus de place à l'Open Agile Adoption de Dan Mezick, lancée par Pablo.

Une bonne façon d'accélérer la transition est d'envoyer des agents du changement (ScrumMasters, PO, managers) participer au Raid Agile.

Compléments

Chapitre dix-neuf

Le chapitre 19 de mon livre s'appelle "Scrum à grande échelle". C'est un sujet délicat.

Le but du chapitre

Il est présenté dans l'introduction :

On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’équipes, de backlogs et de cycle de vie.

Structure du chapitre

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

Scrum à grande échelle, ch.19

Après avoir revu la notion de projet à l'aune de Scrum, j'ai essayé de présenter le passage à l'échelle de façon progressive : programme, produit, portfolio.

Changements dans les éditions successives

Ce chapitre n'existait pas dans l'édition 1. Il a été introduit dans l'édition 2 et il m'avait demandé beaucoup d'efforts.

La taille a été réduite dans cette troisième édition - il est passé de presque 16 à un peu plus de 14 pages- pour simplifier le message dans un domaine qui n'est pas simple.

Liens cités dans le chapitre



Ce que je changerais si j'écrivais une édition 4

On ne sait jamais, ça peut arriver…

  • Je parlerais de LeSS, le "framework" de Scrum à grande échelle qui me paraît le plus intéressant, alors que la première version du chapitre est plutôt basée sur les idées de Leffingwell (à l'origine de SAFe).
  • La notion d'Epic. Je présente une organisation hiérarchique epic – feature – story, alors que maintenant j'utilise la notion d'epic autrement : feature - epic - story. Une organisation que j'accompagne parle de "SoS items" pour ce que j'appelle epic dans le chapitre 19. SoS items pour indiquer que ce sont des gros morceaux, affinés lors des Scrums of Scrums.

Chapitre vingt

Le chapitre 20 de mon livre s'appelle Scrum en France.
Un sujet hexagonal.

Le but du chapitre

Montrer ce qu'il y a de particulier dans l'usage de Scrum en France : vocabulaire, diffusion, spécificités des usages, contraintes organisationnelles, culture, éducation…

Structure du chapitre

Voici le plan de ce chapitre :

Scrum en France, plan du chapitre

Changements dans les éditions successives

Ce chapitre avait grossi dans la deuxième édition. Il est revenu à environ 9 pages, ce qui en fait le plus court de tous les chapitres de mon livre.

J'ai supprimé l'enquête sur l'usage de Scrum faite par le FSUG en 2009, qui datait un peu.

La première partie (Ze French Touch) a été largement revue avec l'introduction des éléments de langage, un retour sur le vocabulaire qu'on utilise en France pour Scrum. Les estimations du nombre d'utilisateurs et d'équipes ont été actualisées.

Liens cités dans le chapitre

Ce que je changerais si j'écrivais une édition 4

  • J'approfondirais les différences culturelles.
  • J'ajouterais des données factuelles sur les usages, peut-être celles de la nouvelle enquête du FSUG.
  • Je parlerais d'évaluation du niveau de Scrum.
  • Je tenterais une prospective.

- page 2 de 2