2017, agilité à grande échelle

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).

Bénéfices d'avoir des équipes auto-organisées et pluridisciplinaires

Pour éviter le faux-agile, il est essentiel que les équipes soient réellement auto-organisées et pluridisciplinaires. 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 :

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 :

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).

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

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 priorité ordinale) correspond au rang définissant la séquence de réalisation des stories.

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.

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.

La planification du sprint (en anglais Sprint Planning) est un rite Scrum qui se déroule à chaque début de sprint.

Ce rite au tout début du sprint sert à déterminer l’objectif et à produire le plan de sprint.

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, 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.

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 succè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.

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.

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

Il faut un vrai besoin pour changer d’é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.

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.

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.

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 :

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.

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.

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.

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.

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.

2017, agilité à grande échelle

Bon Scrum 2017

Bénéfices d'avoir des équipes auto-organisées et pluridisciplinaires

Impressions cubistes

Tableau Scrum

Expérimentations pédagogiques

Critères VRAC pour la priorité dans le backlog

Boite et outil

Planifier pour réussir le sprint

La planification du sprint

Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Prioriser, estimer et planifier

Les activités de l'affinage du backlog

Prioriser avec CD3

Ma 128e formation Scrum

L'agilité à grande échelle n'est pas un modèle d'entreprise

Onze

Scrum 3.0

Flux dans le sprint et engagement

Mon agilité électorale

7e Raid Agile la semaine prochaine

Errata des éditions 3 et 4

La vie de la story a changé en 10 ans

La vie de la story selon Jimmy

Feedback sur la planification