Bon Scrum 2017
Pour ma carte de vœux, j’ai repris et détourné la couverture de l’édition 4 de mon livre Scrum (qui a bien marché en 2016, merci à tous mes lecteurs).
2017, agilité à grande échelle
Un sujet de controverse dans la communauté agile.
Bénéfices d'avoir des équipes pluridisciplinaires et autonomes
Pour éviter le faux-agile, il est essentiel que les équipes soient réellement pluridisciplinaires et autonomes
C’est encore plus important quand il y a plusieurs équipes agiles dans une organisation. Voici les bénéfices qu’on peut en retirer.
Meilleure compréhension des besoins des utilisateurs Avec une organisation en silos (par exemple commerce, marketing, technique, test, infra), la boucle de feedback est forcément longue et peu fiable, car chacun cherche son optimisation locale ce qui pousse à déformer les retours.
Quand tout le monde est dans une seule équipe et participe réellement au résultat, cela évite les temps d’attente qui nuisent au déroulement d’un sprint et les intermédiaires qui créent du bruit.
Impressions cubistes
Les commentaires des participants et des participantes
Denis, qui a participé à mon premier cube en décembre, m’a offert cette fresque (lui il dit sketch).
Ça me fait un bien beau souvenir de cette matinée.
Le concept 1CUBE&GO consiste à expérimenter en groupe, pendant une demi-journée, une solution à un problème couramment rencontré par les participants. Pour ce premier cube, le problème était l’expression du besoin, jusqu’à arriver à un backlog priorisé.
Voilà ce qu’en ont pensé des participants :
Tableau Scrum
Un tableau avec des stories et des tâches
La story, élément du backlog, a une vie qui passe par 5 états.
La tâche, travail contribuant à une story, se représente sur 3 états.
Un tableau Scrum avec les 2 niveaux montre à la fois l’avancement des travaux pendant le sprint (la vie des tâches, les stories en cours de réalisation et finies) et le backlog pour les sprints suivants (bac à sable, stories en affinage, stories prêtes). C’est tout simple, pas besoin de plus d’états (et donc, ni de colonnes supplémentaires).
Expérimentations pédagogiques
En entreprise comme avec les étudiants
Quand j’étais prof à la fac, j’avais expérimenté pas mal de façons d’enseigner avec les étudiants de l’IUP ISI.
Critères VRAC pour la priorité dans le backlog
Valeur, Risque, Apprentissage, Coût
Prioriser est un néologisme souvent utilisé, et pas que pour un backlog. Avec Scrum, on dit que le PO priorise les éléments du backlog. Bien qu’en fait, il les ordonne.
Mais sur quels critères se base t-on ?
Dans l'édition 4 de mon livre, chapitre Affiner le backlog, § Revoir l’ordre, page 89, je résume ainsi :
L’ordre (ou priorité ordinale) correspond au rang définissant la séquence de réalisation des stories.
Boite et outil
La boiboite qui vous attend dans la salle de formation ô local
De 2005 à 2013, j’étais impliqué –et même très impliqué, ce blog en témoigne– dans le développement de l’outil iceScrum.
J’ai quitté Kagilum, la startup dédiée à la diffusion d’iceScrum, il y a 4 ans et je me suis converti, un peu plus, au management visuel physique.
Mes anciens étudiants ont continué leur chemin avec iceScrum. Je viens de visiter leurs nouveaux locaux, dans un lieu convivial très sympa : Ô local.
Planifier pour réussir le sprint
C'est la story qui sprinte
En parcourant mon livre à la recherche du 6e D, je m’arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l’article près. Évidemment ce n’est pas ce que j’ai voulu. C’est un bug.
Je mène l’enquête et découvre rapidement que le bon titre du §9.1 est “Planifier pour réussir le sprint”. D’ailleurs ce titre était déjà présent dans l’édition 3 et il apparaît dans les fichiers que j’ai conservés pour la fabrication de l’édition 4.
Les 6 activités de planification du sprint
Sprint planning
La planification du sprint (en anglais Sprint Planning) est un rite Scrum qui se déroule à chaque début de sprint.
L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories.
Prochain Cube Agile à Toulouse : prioriser, estimer, planifier
Comment on priorise ? Pourquoi on estime ? À quoi ça sert ? Qu'est-ce qu'on estime avec Scrum et l'agilité ? Comment faire en sorte que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l'agilité ?
Si, comme de nombreuses équipes vous avez des problèmes avec l’estimation, et par conséquent avec la priorisation et la planification, ce Cube est pour vous.
Estimer la valeur, la satisfaction client, la taille ou l’effort, vous testerez ces pratiques et saurez comment utiliser les résultats pour prioriser et planifier.
Venez seul ou en équipe, des hommes-jours au #noEstimates, vous y trouverez la pratique qui convient pour votre contexte.
C’est le 23 février matin.
Prioriser, estimer et planifier
Agile ou pas, il est souvent utile d’avoir des prévisions sur le moyen terme
Prioriser, cela permet de définir l’ordre de développement. Dans le cadre de Scrum, la priorisation porte sur les éléments du backlog et indique à l’équipe sur quoi elle va travailler dans le ou les sprints qui viennent.
La priorité d’une fonctionnalité est basée sur sa valeur métier, mais pas seulement. Pour affiner l’ordre de cette fonctionnalité et se projeter un peu plus loin que le travail immédiat, il convient aussi de s’intéresser à l’effort pour la développer.
Les activités de l'affinage du backlog
ADAPTER
L’affinage du backlog (en anglais Backlog Refinement) se pratique avant le premier sprint, puis pendant chaque sprint.
L’objectif de l’affinage est d’augmenter les chances de succès des futurs sprints, en entretenant le backlog.
Voici les activités qu’on y mène, en équipe.
Le moyen mnémotechnique pour retrouver ces activités : ADAPTER
L’affinage se déroule entre le Product Owner et le reste de l’équipe, à un moment laissé à l’appréciation du collectif, soit sur un rythme régulier (ce qui est plus facile), soit à la demande.
Prioriser avec CD3
Coût du Délai Divisé par la Durée
Le Cube de jeudi portait sur Prioriser, estimer et planifier.
J’ai présenté plusieurs techniques de priorisation : HIPPO, 10/10, VRAC et CD3.
CD3, c’est le Coût du Délai Divisé par la Durée.
Le coût du délai est une approche économique : on calcule le coût de ne pas faire une feature et on fait en premier celle qui a le coût du délai le plus élevé.
Bien sûr, cela n’est pas facile.
Les activités de la rétrospective
En finissant par un objectif plutôt qu'un plan d'actions
Mon premier article sur les activités de la rétrospective, en 2007, avait eu gros succès. Quand je relis ce billet aujourd’hui, je me dis que j’en garde l’essentiel, 10 ans après, quand j’anime des rétrospectives (ce que je fais assez souvent).
Ma présentation des activités de la rétro a un peu évolué, voyez ce qu’elle donne maintenant avec les cinq activités.
Mais surtout ce que j’ai changé, c’est le résultat de la rétro.
Ma 128e formation Scrum
Dans un contexte toujours différent
Demain et jusqu’à vendredi, je serai à Bordeaux pour y donner ma 128e formation Scrum. Eh oui, j’ai commencé en 2005, à raison d’une dizaine par an en moyenne.
Si j’ai arrêté les formations Scrum inter-entreprises en 2014, je ne me lasse pas d’animer des sessions en entreprise, pour des équipes qui démarrent. Le contexte est toujours différent, ma formation aussi et j’y prends du plaisir.
Le contenu varie selon les participants, mais aussi parce que j’expérimente régulièrement des nouveautés.
L'agilité à grande échelle n'est pas un modèle d'entreprise
SAFe qui peut !
Il faut un vrai besoin pour changer d’échelle !
Dessin de Patrice Courtiade et légende extraits de Scrum, le guide etc. page 278
Sur Twitter, David, après avoir publié son organigramme d’une organisation agile ajoute :
Très influencé par SAFe, qui reste à ce jour la seule proposition de modèle global d’entreprise
David est provocateur… ou sort d’hibernation. Ou il est peut-être tombé sous l’influence de ceux que j’appelle les néocons dans Scrum mon scrotum.
Onze
Onze ans de blog !
Le premier commentaire que j’ai eu sur mon blog, celui d’Albar en avril 2006, me disait :
Ciel, un blog ! Très courageux de ta part de te lancer dans l’aventure, parce qu’il faudra assurer pour les mises à jour…
J’ai assuré pas trop mal, je trouve.
Maintenant, je me demande de plus en plus souvent s’il reste des choses à dire sur Scrum. J’ai l’impression d’avoir tout écrit dans la version 4 de mon livre.
Scrum 3.0
Une initiative qui n'a pas percé
Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l’essence de la méthode.
C’est pourquoi je porte une grande attention à l’article Scrum3.0 qu’ils viennent de publier.
Flux dans le sprint et engagement
Une question d'Eric, un lecteur
Suite à la lecture de mon billet Scrum3.0, Eric se demande, à propos du sprint en flux continu :
Le flux continu remet en cause le principe “pas de changement pendant un sprint”. Comment permettre à l’équipe de s’engager dans ce mode de fonctionnement ? Au jour le jour ? Ou est-ce que ce mode de fonctionnement est réservé à des équipes qui ont dépassé le stade de la nécessité de s’engager ?
Je réponds à Eric :
Mon agilité électorale
Le dessin est un extrait du livre Permaculture humaine qui montre les 3 piliers de la permaculture.
Pour ces élections qui se terminent demain, je me dis que j’ai fait preuve d’agilité électorale. Agilité au sens capacité à s’adapter et réagir aux changements, tout en restant fidèle à ses valeurs et principes.
Comme il me faut respecter la trêve avant le vote, je ne vais pas rentrer dans une réflexion trop personnelle. Disons donc que mes valeurs et principes s’inspirent de la permaculture, l’approche systémique à laquelle je m’intéresse actuellement.
7e Raid Agile la semaine prochaine
Ça vous tente ? Trop tard, car nous sommes complets
La semaine prochaine, il fera beau dans les Cévennes, du côté de Lasalle pas loin de Saint-Jean du Gard. J’y serai avec Pablo, car nous animerons le 7e Raid Agile, toujours au Mas du Canton.
La piscine devrait être ouverte ce qui n’était arrivé qu’une seule fois dans les Raids précédents, en juin 2015 (qui est resté connu comme le raid piscine).
Ça vous tente ? Trop tard, car nous sommes complets depuis plus de 2 mois.
La vie de la story a changé en 10 ans
Une évolution sensible vers du flux
Il y a à peu près 10 ans, j’écrivais un billet “Les états significatifs d’un élément de backlog”.
Amusant de le relire aujourd’hui et de constater comment mon approche de Scrum a —légèrement— évolué au fil des ans.
Pas beaucoup sur les états, car je décris toujours la vie d’une story avec cinq états, dont les noms ont un peu changé, mais pas les 2 essentiels : prêt et fini.
La vie de la story selon Jimmy
Merci Jimmy pour le feedback
Suite à mon article d’hier, j’ai reçu un commentaire de Jimmy L. que je remercie de son feedback.
Jimmy est tout à fait d’accord avec moi pour ne montrer à la revue qu’une story déjà déclarée finie. Cependant il enchaîne :
…Mais cela m’étonne justement qu’on s’arrête généralement à “Finie” sur ce genre de workflow, et qu’on ne mette pas au moins en bout l’état correspondant à l’avis positif reçu en revue de sprint.
Feedback sur la planification
noEstimates
Pour l’édition 4 de mon livre, j’ai revu complètement le chapitre qui porte sur la planification à moyen terme. J’ai fait un gros effort sur le pourquoi. J’ai commencé le comment par un exemple simple, sans estimation. J’ai introduit des variantes à l’estimation et au planning poker. J’ai essayé d’illustrer les notions présentées.
Je l’ai également déplacé, car cette notion ne fait pas partie du cœur de Scrum. C’est maintenant le chapitre 16, il s’appelle Planifier la release.