feedback

Mes relecteurs et mes relectrices

Mes relecteurs et mes relectrices

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. Ce livre est particulier. En tout cas, différent de mon livre Scrum.
Une bonne note de lecture

Une bonne note de lecture

L'art de devenir une équipe agile, lu et commenté par le critique emblématique de l'agilité

Comme un enfant qui a eu une bonne note à l’école, je suis heureux d’avoir eu une bonne note de lecture. Ce n’est pas tellement la note en soi qui me fait plaisir — 8/10 c’est bien mais j’ai déjà eu plein de 5* sur Amazon — c’est la critique qui va avec.

Car elle vient du seul véritable critique de livres dans notre domaine, Christophe Addinquy.

Le Software Freethinker

La revue revisitée

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 :

  1. collecter le feedback,
  2. 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.

Le feedback des lecteurs

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.

Scrum pour une phase d'étude

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 traduction de Fabrice “de l’idée au lancement en passant par la vision” illustre bien ce qu’on peut faire pendant cette phase. Elle peut prendre quelques jours mais parfois bien plus.

Historique d'iceScrum

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. Les étudiants de cet IUP en génie logiciel ont un module d’enseignement qui consiste en des projets tutorés : des équipes sont constituées pour développer un produit en suivant les méthodes enseignées.

Mes relecteurs

Si mon livre 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. Je les envoyais à mes 3 relecteurs principaux[1], à qui je donnais quelques jours pour me faire des remarques. Et ils l’on fait !
Le feedback, la clé de l'amélioration

Le feedback, la clé de l'amélioration

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

Définition de l'agilité

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.