Après une présentation des conférences du jeudi par Jonathan, c’est à mon tour de vous parler du Scrumday, cette fois-ci pour vous parler de la journée du vendredi.

Keynote

Cette journée a commencé par une keynote avec Mary Poppendieck comme oratrice. La keynote met en exergue des éléments, parfois évident ou triviaux quand on y pense mais qu’il n’est pas forcément inutile de rappeler, parfois précis et subtils, apportant beaucoup de matières à réflexion pour tous développeurs ou responsables de projets.

Sa présentation se divisait en 4 points et si je suis incapable de résumer correctement la conférence (mais la vidéo de celle-ci est disponible), j’ai noté quelques éléments qui me semblent pertinent :

Les équipes

La sociologie et l’étude des tribus humaines permet de diviser nos groupes sociaux en plusieurs cercles de tailles croissantes

1. le cercle interne, de 3 à 5 personnes, la famille ou les amis très proches
2. le « sympathy group », de 7 à 10 amis proches. Ce sont les personnes sur qui on peut compter dans toutes les situations, ceux pour qui on est prêt à « mourir ». Elle donne comme exemple la patrouille dans l’armée romaine, un groupe de 8 personnes ayant des liens très forts, ils vivent ensemble, se battent ensemble, sont responsables les uns des autres… Cette unité de base de l’armée romaine lui donnait une grande force et une grande adaptabilité sur le terrain qui lui a permis de conquérir et dominer son monde pendant plusieurs siècles.
3. le groupe de chasseurs, de 30 à 50 personnes collaborant pour mener à bien une mission complexe, typiquement, chasser le mammouth. Cette taille d’équipe est typiquement la taille d’une « équipe produit » ou d’une startup ou encore d’un projet Open Source. L’une des conditions nécessaires pour la réussite d’un groupe de chasse est l’existence d’un véritable leader en qui les autres ont confiance.
4. le clan, de 100 à 150 personnes qui ont des relations interpersonnelles ; pour Mary Poppendieck, c’est la taille maximale d’une Business Unit pour que celle-ci soit utile ou fonctionnelle.

Dans le cadre d’un projet, pour qu’un équipe, même divisée en sous-équipes plus spécialisées (par exemple, les développeurs Back-offices, les équipes d’exploitations, les responsables fonctionnels…) soit efficace, il faut 2 conditions :

1. ces différentes sous équipes doivent avoir un même but global
2. une sous-équipe ne peut pas réussir si l’ensemble de l’équipe ne réussit pas.

La complexité

Le second point de la conférence portait sur la notion de complexité.

On sait que les systèmes complexes ne fonctionnent pas ou mal. Mary Poppendieck insiste alors sur la notion de livraison continue :

• avec en permanence des tests d’acceptance
• avec un travail conjoint des équipes de QA et de développement.
• le logiciel est toujours prêt à être livré en production
• il y a une forte collaboration entre les équipes business et de développement
• il faut des outils automatiques pour le test, la migration de base de données ou le déploiement.

La release d’une version doit être un choix business pas opérationnel.

Concernant cette notion de complexité et de façon de travailler avec, Mary Poppendieck donne l’exemple des micro-services :

• des services qui font une seule chose mais le font bien, déployables de façon indépendante les uns des autres (en particulier, indépendamment d’une base de données centrales).
• des services gérés par une petite équipe, responsable du service du début à la fin : « you build it, you monitor it, you fix it »

L’état d’esprit

La troisième partie de la keynote portait sur le « Mindset« , l’état d’esprit

« Think product, not project ». Pour Mary Poppendieck , il faut changer l’état des esprits des équipes pour qu’elles ne pensent plus en mode « nous devons livrer le projet » mais en mode « nous devons résoudre des problèmes, apporter des solutions »

L’objectif

Enfin, la dernière partie de la conférence portait sur la notion de « focus » ou l’objectif à atteindre

Pour Mary Poppendieck, on doit se poser la question de l’impact en terme de business de son développement, c’est « l’impact Driven Development ». On doit toujours commencer en se posant la question du pourquoi ? Quel est le problème, quel est l’objectif du projet / produit ? On doit comprendre l’impact désiré pour le produit, faire des hypothèses sur l’impact qu’aura le design. Et en fin de projet, on doit être capable de prouver que l’impact désiré est atteint.

 

Open space

La seconde partie de la journée a été consacrée à une session « Open Space » de 4 h.

Le principe des « Open space » est le suivant :

– En début de session, des personnes proposent des thèmes de discussion, un lieu et un horaire. Un tableau blanc avec les lieux et heures est disponible et chaque proposant colle un post-it avec son sujet à l’heure qui lui convient

– Chacun note les sujets qui l’intéressent et se rend sur place pour discuter du sujet avec les personnes présentes.

Ce système permet des échanges très souples sur des sujets divers. La seule vraie contrainte étant d’avoir suffisamment de lanceurs de sujets pour occuper la session Open Space. Dans le cadre des Scrumday, les propositions furent très nombreuses et variées (entre 30 et 50 propositions) pour une durée d’environ une heure par discussion.

No Estimation

La première session à laquelle j’ai participé portait sur « No-estimation »

De ce que j’ai compris, le « no-estimation » est une tendance de certaines équipes scrum expérimentées à ne plus avoir besoin d’estimer la durée des tâches (que ce soit en jours/homme ou en points) car elles savent intuitivement ce qu’elles pourront faire durant un sprint.

Un élément extrêmement intéressant de la discussion portait sur la notion d’estimation. Tout développeur / chef de projet… s’est vu demandé « combien de temps pour effectuer cette tâche ?» avec des difficultés à répondre. Souvent, il sait que le chiffre qu’il va donner (par exemple 10 jours) va être compris comme un engagement de sa part et qu’il devra expliquer pourquoi il a mis en fait 13 jours (et curieusement, on ne lui demandera pas d’expliquer pourquoi il a mis 8 jours). Il faut donc essayer d’arriver à un autre mode de fonctionnement avec le demandeur. A la place de 10 jours, on va dire : « il y a 95 % de chance que je finisse cette tâche entre 8 et 13 jours sans doute, de façon plus proche de 10 jours ».

L’estimation de la durée d’une tâche se rapproche ainsi de la théorie de la mesure, utilisant la théorie des jeux pour fournir une estimation correcte. On peut fournir pour chaque tâche une véritable estimation avec un intervalle de confiance (à 95 % souvent), suivant une loi de distribution de type loi normale asymétrique. Si on arrive à faire accepter cette estimation avec un intervalle, on peut de plus utiliser un autre outil pour estimer la durée totale d’un projet.

En considérant qu’un projet se divise en quelques dizaines de tâches (les différents item du backlog produit par exemple), même en sachant que l’on possède une incertitude sur les estimations de chacune des tâches, il est possible de fournir une estimation globale du projet en effectuant un tirage de type « monte-carlo ». Pour chaque tâche, on effectue un tirage aléatoire suivant son estimation (de 8 à 13 jours, sans doute 10 jours, à 95 % de confiance), puis on calcule l’estimation totale pour ce tirage (exemple 137 jours), on refait un second tirage (135 jours), un troisième (142)… puis on calcule la moyenne des tirages, ce qui donnent une bonne estimation globale.

En finir avec Scrum ?

Je suis allé à cette discussion au titre volontairement polémique en me disant qu’on aurait l’occasion de discuter de Kanban, où de façon générale comme dépasser la notion de sprint de durée fixe. La discussion a été très générale et intéressante, mais l’un des points qui m’a semblé intéressant est le reproche qui a pu être fait à certains de voir dans le « scrum guide » une sorte d’évangile avec ces rituels (le daily meeting, les post-it sur le mur) mais sans forcément comprendre l’intérêt de ces pratiques et la nécessité ou la capacité parfois de ne pas les utiliser si ça n’est pas adapté. Nous avons aussi discuter du carcan parfois contre productif des rôles, de la difficulté de maintenir la motivation sur le long terme (avec un exemple de projet qui en était à son 76eme sprint), de la gestion du Backlog produit comme un stock de feature à intégrer et pas comme un flux d’idées qui peuvent y entrer en cours de projet mais aussi en sortir si l’équipe considère qu’elle est finalement inutile ou inadaptée

Conclusion

En conclusion, les journées Scrumdays apportent une vision intéressante sur l’utilisation de Scrum au jour le jour, que ce soit pour mieux comprendre sa pratique, pour s’améliorer ou encore pour réfléchir aux limites que l’on peut atteindre.