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.
J’ai proposé à mes camarades Niko, Antoine et Jeff de jouer “aux bacs, façon puzzle”.
J’étais déjà content d’avoir trouvé ce titre et j’ai aussi été content de leur entrain à jouer. Je les remercie bien chaleureusement.
Trier des pièces de puzzle pendant le déjeuner, en mangeant une flammeküche et en buvant une bière, ce n’est pas très pratique.
Mais c’est fun ! Le premier objectif était de s’amuser et il a été atteint.
Une story est prête à prendre le départ du sprint si son comportement attendu (conditions d’acceptation) et la qualité requise (critères de finition) sont suffisamment connus de l’équipe. Un autre volet essentiel pour s’assurer de la capacité de l’équipe à développer la story pendant le sprint porte sur les conditions de réalisation.
Qu’y a t-il dans la définition de prêt d’une story ?
C’est dépendant du contexte et c’est à chaque équipe d’établir sa propre définition de prêt.
Eddy m’en a fait gentiment la demande, alors je transmets son appel à participer aux ScrumBeer en Suisse Romande :
Bonjour ,
Pour ceux qui ont aimé la SoftShake et qui veulent en savoir plus sur l’agilité, il y a des Scrum Beer à Genève, Lausanne et dans le Valais.
Le meetup ScrumBeer Suisse Romande vous donnera plus d’information.
L’agilité s’applique à des domaines tels que le management, la gestion de projets, la gestion d’équipe et les flux de travail.
Plutôt que de proposer plein de dates dans un catalogue et d’en annuler les 3/4 comme le font la plupart des organismes de formation industrielle, j’ai décidé, en accord avec les camarades de la Fédération Agile qui animent avec moi, de n’officialiser la date d’une session qu’une fois sa viabilité assurée.
Pour en savoir plus sur la MVS, relisez le billet Artisanat de la formation inter.
Voici la situation sur les sessions potentielles, en toute transparence :
J’avais entendu parler du PODojo, atelier destiné aux Product Owners pour s’améliorer par la pratique. Le PODojo est au PO ce que les coding dojos sont aux développeurs. Il s’en était déroulé quelques uns lors des conférences agiles l’an dernier.
Lors d’une formation PO que nous animions ensemble, Alexandre Boutin m’a proposé d’inclure un PODojo. Les 16 participants ont travaillé en 3 groupes, tous sur la même story. Je ne rentre pas dans les détails mais cela s’est très bien passé.
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…
On s’y retrouve d’une année sur l’autre, avec seulement quelques nouveaux.
On chante tous ensemble le matin pour partir sur une bonne note. Ou alors on se colle des stickers sur le front pour ensuite se regrouper en hordes.
Il y a aussi dessin, sur les murs évidemment. Heureusement pour la fresque que ce n’est pas obligatoire, cela évite les gribouillis. D’ailleurs rien n’est obligatoire et chacun devient un moniteur quand il a envie.
L’agilité a popularisé l’amélioration continue, avec les rétrospectives.
À chaque fin de sprint, donc en général toutes les 2 ou 3 semaines, l’équipe s’arrête de développer, pour réfléchir à la façon dont elle a travaillé, dans le but de s’améliorer.
Ce qui est moins connu que la rétrospective, c’est l’intraspective [1]. L’intraspective est une pratique consistant, quand un obstacle vient d’être éliminé, à en chercher la raison profonde, afin d’éviter qu’il se reproduise.
Après plusieurs expérimentations, comme celle à la Chunga ou à Agile Games France, j’ai utilisé le jeu des bacs façon puzzle dans ma formation Scrum de la semaine dernière.
Je suis particulièrement satisfait des enseignements qu’il a apportés. Je l’adopte pour mes prochaines formations et j’ai décidé de le publier : le jeu des bacs façon puzzle.
Cette semaine, c’est un autre beau jeu pour apprendre que je vais proposer aux participants à la formation Kanban de Toulouse : le Kanbanzine.
La première fois que j’ai parlé de Kanban dans ce blog, c’était en 2008, un billet suite à ma lecture de Scrum-Ban de Corey Ladas. Depuis Kanban a fait son chemin dans l’IT.
On en parle de plus en plus dans les conférences. Sur le terrain, je vois de plus en plus d’équipes qui s’y intéressent.
Maintenant j’aborde régulièrement de Kanban dans mon blog. Les formations, comme celle de sensibilisation à Toulouse la semaine dernière suscitent de l’intérêt.
Kanbanzine, c’est pratique pour le formateur : on peut créer son propre scénario et il y a aussi une grande variation possible dans l’application des règles. Cela donne des idées.
Depuis que j’ai fait l’acquisition d’un plateau Kanbanzine, j’ai bien dû faire une dizaine de parties. Je l’ai joué plusieurs fois avec Laurent Morisseau comme ici lors de la dernière formation Kanban à Toulouse.
Laurent a écrit un billet où il compare Kanbazine à GetKanban, l’autre jeu pour apprendre le Kanban : GetKanban vs Kanbanzine, le challenge.
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
Suite de la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition.
Cette deuxième partie évoque les approches processus pour montrer en quoi Kanban est différent.
Représentation de processus Il y a une quinzaine d’années, je m’intéressais de près aux notations, langages, modèles et méta-modèles (UML, SPEM, BPMN) pour représenter les processus.
On retrouve dans Kanban les mêmes notions de rôle, activité et élément de travail, mais avec une approche bien différente :
En fait, j’ai lancé mon blog le mardi 4 avril 2006.
A l’époque, j’étais encore prof à la fac et j’avais attendu que les étudiants partent en stage, début avril, pour m’occuper du lancement du blog[1].
C’était le début d’une belle aventure dont je ne pensais pas qu’elle me mènerait aussi loin.
Au début, mes billets étaient bien plus fréquents, car Twitter n’existait pas encore. J’ai écrit pas mal de billets courts qui feraient maintenant l’objet d’un simple tweet[2].
Voici ce que j’ai proposé :
Thématique Le rôle du PO aujourd’hui et sa vision produit dans l’entreprise
Résumé Pour définir un produit, en allant de la vision jusqu’à un backlog contenant des stories prêtes pour le sprint, le Product Owner dispose maintenant de nouveaux outils, que l’Agilité a récemment adoptés.
L’objectif de cette présentation est de montrer les nouvelles pratiques de définition de produit, avec un focus sur le rôle de Product Owner.
Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition, troisième partie de la préface.
De l’Agilité vers le flux Les méthodes agiles ont permis une évolution décisive vers la notion de flux.
D’abord, en regroupant toutes les entrées d’un processus de développement en un seul artefact, le fameux backlog. La première marche vers le flux est là, avec le backlog en entrée qui se transforme en produit partiel potentiellement livrable, comme dans le schéma Scrum si répandu.
Cette semaine, j’ai à nouveau expérimenté avec succès la formule #noSlides.
Pourquoi sans slides ? Depuis 9 ans que j’anime des formations Scrum, j’ai diminué progressivement la taille du support de présentation pour laisser plus de place aux ateliers. Moins de slides, plus de jeux, cela permet de rendre le cours plus vivant pour les participants.
Mais le passage à #noSlides, c’est d’abord pour moi : j’ai animé tellement de sessions que si je faisais toujours la même chose et qu’en plus cela consistait principalement à passer le slide suivant, cela fait longtemps que je me serais lassé.
Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition, suite de la préface (4/6).
Des pionniers du Kanban, vers la maturité C’est pourtant comme cela, avec des tableaux de post-it, que s’est développé Kanban dans le milieu de l’agilité.
Les premiers retours d’expérience présentent souvent des énormes tableaux remplis de post-it. Cependant, grâce au travail d’évangélisation de Laurent depuis déjà 2-3 ans, la diffusion de Kanban progresse régulièrement, pas seulement comme tableau, mais comme méthode d’amélioration.
Le Club de lecture Agile Toulouse d’hier soir portait sur Agile Transition de Andrea Tomasini & Martin Kearns.
Le livre ne nous pas appris grand chose. Il est plutôt destiné à faire découvrir l’état d’esprit de l’Agilité à ceux qui ne connaissent pas. Il ne parle pas vraiment de transition.
Cependant, il nous a permis de bien discuter sur la transition.
Le personnes qui développent des systèmes s’intéressent à l’Agilité. J’ai fait récemment une intervention pour le Club des utilisateurs du System Engineering à Toulouse et je suis maintenant sollicité par l'AFIS.
J’étais pas mal impliqué dans ce domaine de l'ingénierie système il y a quelques années, avant de me consacrer entièrement à l’Agilité.
A l’occasion de mon intervention au Club des utilisateurs, j’avais proposé une relecture collective du Manifeste Agile, adapté au développement de systèmes. Il a été conçu au départ pour le développement de logiciel, donc quelques adaptations sont nécessaires.
J’ai écrit la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition.
Voici un nouvel extrait.
C’est le pénultième.
Mesures et estimations En réponse à l’exigence de prédictibilité toujours exigée par le management, les méthodes agiles ont réussi, en quelques années, à populariser le planning poker, l’estimation en points et la vélocité.
Cependant les dérives liées aux habitudes du contrôle et du micro-management sont apparues de façon concomitante.
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.
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é.
