Se focaliser sur l’essentiel. Éliminer les fioritures qui se sont accumulées au fil des ans. Ignorer les sur-couches qui ont fini par dénaturer l’idée de légèreté des débuts.
Il s’agit de revenir aux fondamentaux, dans l’agilité comme dans de nombreux autres domaines. Mais de quoi s’agit-il, les fondamentaux ?
Le résultat du sprint est ce que l’équipe donne aux parties prenantes à la fin de chaque sprint, pour solliciter leur feedback.
Le résultat est produit par le travail de l’équipe, à partir du backlog, dans la boucle du sprint. À un backlog unique vont correspondre plusieurs résultats, un par sprint.
Sur la photo, mon vieux sac à dos Agile Grenoble 2011 rempli de précieux retours pour Scrum 6 donnés par une relectrice exceptionnelle ; j'étais allé les chercher à vélo au fin fond du Lauragais, en grimpant les côtes sous le terrible cagnard de début août, mais ça valait largement le coup.
L’écriture d’un livre, c’est avant tout l’affaire de l’auteur. J’ai commencé en avril 2021, j’y ai passé beaucoup de temps, mais cela n’a pas été 9 mois de travail solitaire. Le contenu du livre montrant tout l’intérêt des boucles de feedback pour accroitre la valeur d’un résultat, je n’allais pas m’en passer dans l’écriture.
Je viens de recevoir des nouveaux dessins de Patrice pour l’édition 6. Comme depuis l’édition 1, je lui envoie du texte provisoire qu’il utilise pour laisser son inspiration vers des idées d’illustrations. Par exemple, il me propose un dessin sur le mot feedback.
Ces personnes sans lesquelles le livre n'aurait pas été le même, je leur offre toute ma gratitude
En parcourant mon blog, je m’aperçois que je n’ai pas remercié celles et ceux qui ont contribué au résultat du livre L’art de devenir une équipe agile, à savoir les relectrices et les relecteurs. Je l’ai fait pendant la conception du livre — autant que je me souvienne — mais pas depuis qu’il est publié.
Je répare cet oubli.
Commencez par une revue en interne, avec seulement l'équipe Scrum
La revue de sprint, telle que décrite de façon habituelle a deux objectifs :
collecter le feedback, communiquer un avancement objectif sur la release (et prendre éventuellement une décision sur la vie du produit). Ces deux objectifs ne visent pas forcément les mêmes personnes. Le feedback sur les user stories montrées est demandé aux futurs utilisateurs tandis que l’avancement du produit intéresse des parties prenantes impliquées dans le pilotage.
Pour mener à bien la première édition de mon livre, j'avais plutôt fait du Scrum. Pour la deuxième, j'avais évolué vers du Kanban.
Pour la troisième j’avais l’expérience. Je savais qu’écrire un livre n’est pas un processus linéaire et j’avais appris à quel moment le feedback des lecteurs était le plus profitable pour moi.
Ce n’est pas à la fin pour la validation d’un chapitre. Non, j’ai besoin d’un feedback beaucoup plus tôt que ça. En fait dès que j’estime avoir avancé quelques idées, je sollicite mes relecteurs pour voir ce qu’ils en pensent. Selon leur disponibilité, ce sera un seul ou plusieurs pour un chapitre. Le plus souvent cela a été un seul à la fois et c’est ce que je préfère : j’intègre le feedback d’un lecteur avant de passer au suivant. Cela a marché car ils ont accepté ma requête insistante d’avoir un feedback rapide (moins d’une semaine en général ce qui n’est pas évident pour les grands professionnels occupés qu’ils sont).
Plutôt que de faire une phase d'étude (ou sprint zéro) longue, transformez-la en plusieurs sprints courts
Pour commencer le premier sprint, il faut un certain nombre de choses, au moins un backlog et une équipe. En 2006, il y a une éternité donc, j’avais écrit un billet “avant la première itération”. J’en ai écrit d’autres par la suite, autour du sprint zéro.
Une nouvelle version d’iceScrum va bientôt être diffusée, avec une pré-release en août. L’équipe actuelle, portée par iceScrum Technologies, a réécrit toute l’application à l’occasion du changement sur la plateforme de développement agile Grails.
Je profite de ce changement majeur pour revenir sur l’histoire d’iceScrum.
L’histoire d’iceScrum a commencé en octobre 2005 à l’IUP ISI de l’Université Paul Sabatier de Toulouse.
Si mon livre Scrum a de bonnes critiques de la part de ses lecteurs, c'est en grande partie à mes relecteurs que je le dois.
C’était l’année dernière, en été, j’écrivais laborieusement et j’envoyais mes chapitres au fur et à mesure de leur rédaction, dès que j’avais quelque chose de lisible.
La nouvelle version d’IceScrum, publiée hier, comporte de nombreuses nouveautés. C’est le feedback des utilisateurs qui nous guidés pour définir les priorités.
La clé plate que brandissent les membres de l’équipe sur le dessin (merci Manuarii) rappelle une amélioration concrète d’ergonomie : l’accès a de nombreuses fonctions qui se faisait uniquement par clic droit (ce qui n’était pas intuitif pour une application web) est désormais plus évident, grâce à la clé de 12[1].
Dans l’introduction de mon livre, avant de détailler Scrum, je parle d’agilité et je reprends une définition de Jim Highsmith :
L’agilité est la capacité à favoriser le changement et à y répondre en vue de s’adapter au mieux à un environnement turbulent.
Je trouve intéressante la mise en avant de cette idée que le changement est non seulement subi mais sollicité (par le feedback). D’ailleurs j’utilise aussi cette définition dans mes formations.
