2011, Scrumban - Scrum, Agilité & rock'n roll

Santé, bonheur et agilité pour tous ! On commence l’année par parler de l’affinage du backlog.

Un utilisateur d’IceScrum a déposé une demande d’évolution dans le bac à sable en ligne. Il nous dit : Dans un environnement de production, vous avez souvent différents groupes de personnes qui sont responsables d’accomplir des tâches spécifiques. Par exemple, vous pourriez avoir des artistes, des designers, des programmeurs sur différents domaines, des testeurs…, tous ayant des compétences différentes. Il nous serait utile de les suivre séparément en termes de tâches et de ressources.

La lecture du dernier article de Scott Ambler dans DrDobbs “Certified ScrumMaster Examined” m’a interpellé, non pas sur la certification, mais sur la façon d’écrire ScrumMaster. ScrumMaster ou Scrummaster ou Scrum Master ?

On trouve maintenant 4 livres en français sur Scrum. Il y a bien d’autres sur l’agilité qui parlent aussi de Scrum ou simplement l’évoquent, mais seuls ceux-ci ont un titre qui contient le mot Scrum.

L’estimation des éléments du backlog se base sur des suites de nombres. La suite la plus couramment utilisée pour estimer lors d’une séance de planning poker —en tout cas la plus connue— est la suite de Fibonacci. La suite de Fibonacci se présente comme ceci : 0 1 1 2 3 5 8 13 21 34 55 89 Dans les cartes de Planning Poker que l’on trouve en ligne, c’est : 0 1/2 1 2 3 5 8 13 20 40 100

En décembre 2001, dix-sept spécialistes du génie logiciel se sont réunis dans les Montagnes Rocheuses pour cette déclaration fondatrice, qui prend clairement position contre les processus lourds et le taylorisme en vigueur dans l’industrie. Un peu plus tard…

Henrik Kniberg est un des gourous de l’agilité les plus intéressants. Il a plein d’idées et les exprime toujours très clairement, ce qui fait qu’on a tendance à faire ce qu’il dit. Le risque est de tomber dans le culte du cargo. Exemple avec le focus factor.

Lundi soir, j’ai fait une présentation de Scrum, avec une démo d’IceScrum, invité par ApéroWeb dans les locaux de la Cantine de Toulouse.

Pendant un sprint, une équipe Scrum ne devrait pas, en principe, être perturbée. Cependant il arrive que des perturbations correspondent à des travaux urgents qui ne peuvent pas attendre, alors que faire ?

Après l’ApéroWeb du 21 février, la Cantine accueille un nouvel événement où l’on va parler de méthodes agiles. Le prochain SigmaT, qui a lieu tous les trimestres et se passe d’habitude à l’Université Paul Sabatier, se tiendra cette fois à la Cantine de Toulouse. Cette dix-septième (!) édition des SigmaT sera placée sous le signe des relations entre les clients (et utilisateurs) et les développeurs. En effet le sujet sera le Product Owner. Popularisé par Scrum, le rôle de PO est probablement le plus délicat à tenir dans les organisations. Ce représentant des utilisateurs et clients dans l’équipe vient normalement du côté métier. Cependant compte tenu des difficultés rencontrées sur le terrain, notamment en ce qui concerne sa disponibilité, certains proposent d’avoir un PO proxy côté développement. Cette idée est très discutée, ce sera l’objet du débat. Pour s’y préparer, on peut relire une présentation du rôle de Product Owner.

L’Institut Agile a publié une première version du référentiel de pratiques agiles. L’objectif est de le faire connaître largement dans la communauté francophone. Je contribue bien volontiers à cette initiative française, qui n’a pas d’équivalent ailleurs. On parle beaucoup d’instituts en ce moment, avec ceux qui se consacrent aux sondages, mais c’est plutôt pour dire : Destituons les instituts. On peut être rassuré, l’Institut Agile est beaucoup plus transparent. A propos d’institut, j’ai travaillé il y a une vingtaine d’années dans l’Institut du Génie Logiciel. En fait c’était une société (IGL) qui avait été fondée par un ancien prof de fac. C’est vrai qu’institut, cela donne un côté universitaire.

Dans notre présentation au Scrum Day, comment tirer le meilleur de Kanban & Scrum, avant de montrer les différences, nous reviendrons sur les similitudes entre les 2. Parmi celles-ci, le fait que les deux sont empiriques. On peut grossièrement identifier 3 activités concernées par l’empirisme.

Avant d’aborder l’au-delà, il faut d’abord définir ce qui pourrait désigner un projet avec Scrum. La définition classique (celle du PMI) est la suivante : un projet est un effort temporaire dans le but de créer un produit, un service ou un résultat unique. Avec Scrum, l’effort du sprint permet d’obtenir un incrément de produit et, après les efforts de plusieurs sprints, le résultat correspond au produit. L’équivalent le plus proche de la notion de projet serait, avec Scrum, la release, vue comme une suite de sprints.

L’anniversaire, c’était hier. J’avais commencé (tout doucement) le 4 avril 2006. À l’époque, je n’imaginais pas continuer aussi longtemps, ni qu’il m’apporterait autant de satisfaction. Ce n’est pas tant par l’écriture en elle-même qui a toujours été et reste difficile, même si cela permet de structurer la pensée. C’est plutôt par ce qu’il m’a permis de faire : rencontrer plein de gens intéressants (comme au Scrum Day jeudi dernier), aider des équipes à passer à l’agilité et écrire un livre. C’est en effet par la lecture de mon blog que mon éditeur m’a contacté il y a 2 ans.

Gokjo Adzic a publié il y a quelques mois un article sur une technique de mindmapping permettant de définir un produit.

Si on se réfère à l’assistance que nous avons eue lors du Scrum Day et aux échos que la présentation a suscités, le ScrumBan est un sujet qui intéresse.

La formation que j’ai animée la semaine dernière a mis en évidence, une fois de plus, l’intérêt de la diversité. Du 11 au 13 avril, je donnais une formation Scrum inter-entreprises à Toulouse[1]. C’était bien. Les formations inter-entreprises accueillent des participants venant d’horizons différents. La grande diversité des expériences est extrêmement enrichissante. De plus, comme ces participants ont demandé à venir à cette formation et ont parfois dû insister pour y arriver, ils sont très motivés et ils ont vraiment envie d’apprendre et de partager, ce qui est agréable pour le groupe, et aussi pour le formateur.

Quand je suis au jardin, il m’arrive, pendant que j’y vaque, d’avoir besoin d’un outil et de l’aller chercher. Souvent, je m’arrête en chemin, attiré par une fleur de ciste qui éclot ou par une mauvaise herbe qui dépasse, et je me mets à vaquer à autre chose. J’ai tendance à ne pas finir ce que j’ai commencé.

Voilà une façon simple de faire du “scrum de scrums”.

Ce billet reprend une partie du livre Scrum le guide pratique de la méthode agile la plus populaire, chapitre Des sprints pour une release, pages 22 et 23. En plus de sa démonstration à la revue de sprint, on peut identifier trois usages de la version produite en fin de sprint, pour un développement de logiciel. Utilisation interne La version n’est pas utilisée en dehors de l’équipe de développement. Elle a été produite pour chercher à minimiser les risques liés à la technologie et à la capacité de l’équipe à intégrer différents composants. Elle n’est pas livrée à l’extérieur de l’équipe. Cela est fréquent au début d’un nouveau développement.

Ce billet s’appuie sur un extrait du livre Scrum le guide pratique de la méthode agile la plus populaire, édition 1, chapitre 5 Le backlog de produit, page 58. Le backlog de produit est au carrefour de plusieurs activités du développement : l’ingénierie des exigences, puisqu’on y collecte ce que doit faire le produit ; la gestion de projet, car le backlog est la base pour la planification ; la conception et le codage des stories sélectionnées pour un sprint ; le test, qui permettra de s’assurer que les stories sont bien finies dans un sprint. Le backlog est donc utilisé par toute l’équipe -et pas seulement par le Product Owner- pour communiquer sur les activités menées sur les stories, Même si c’est lui qui en est responsable et qui définit les priorités, le backlog est partagé entre toutes les personnes de l’équipe.

Lorsqu’on se lance dans le développement agile, une des premières questions à laquelle il faut répondre concerne la durée des itérations. Il n’y a pas de réponse universelle, chaque projet est différent et doit définir sa façon de travailler. S’il existe un consensus de la communauté agile pour préconiser que toutes les itérations doivent être de même durée et qu’une itération est un bloc de temps fixé, il y a des variations sur la durée d’une itération.

J’ai participé, avec quelques membres de la SigmaT, à la première partie du Startup Week-end de Toulouse, qui se poursuit à l’heure où j’écris ce billet : il se termine par les présentations des 9 groupes à partir de 16h ce dimanche. Les organisateurs toulousains ont pensé que les méthodes agiles pouvaient aider les participants à concrétiser leur projet. Ils m’en ont parlé et j’ai trouvé que c’était une bonne idée.

Les jeux sérieux sont très en vogue dans le domaine de l’agilité. Ils se pratiquent sur les projets, et on peut s’y entrainer dans les conférences et les formations. L’association SigmaT en propose pour la communauté toulousaine. Elle organise le 30 mai un atelier sur la Théorie des contraintes, il reste encore quelques places. Je les utilise aussi dans me formations. Hier, nous avons consacré l’après-midi de la première journée de ma formation Scrum à :

Je viens d’animer, pendant 3 jours, une formation Scrum pour une SSII toulousaine. J’avais 9 participants curieux et motivés et nous avons passé un bon moment ensemble. Je pense qu’après la formation ils sont prêts à appliquer les pratiques agiles chez leurs clients, et à leur apporter plus de valeur. C’était une formation Fédération Agile. Je lis par ailleurs, sur des réseaux sociaux, qu’une autre SSII toulousaine se renseigne pour trouver une formation Scrum certifiante[1] pour ses collaborateurs.

Franck (@DirtyF) m’a demandé ce que je pensais de Perplexité, complexité, vélocité …une autre vue.

Même si on pense avoir tout prévu, des événements inattendus viennent toujours freiner l’avancement du sprint, en bloquant ou ralentissant une ou plusieurs tâches en cours. Pour empêcher ces événements de remettre en cause l’engagement de l’équipe sur un objectif de sprint, il faut garder du mou lorsqu’on planifie le sprint.

Avec l’épisode ScrumBan au jardin, j’avais présenté une façon de mixer Scrum et Kanban. En voici une autre, toujours dans l’idée de tirer le meilleur des 2.

On entend souvent parler de bonnes pratiques. Certains pensent que comme elles sont bonnes, elles peuvent s’appliquer partout. Mais les solutions qui ont marché ailleurs ne sont pas forcément bonnes partout et pour tout le monde.

Jim Highsmith vient de publier un billet avec une idée qui m’a beaucoup plu The ‘’to do less’’ List, qu’il reprend des fondateurs de 37 signals. Penser plus, faire moins : par tempérament, j’ai déjà tendance à suivre naturellement cette idée. De plus en plus au fil des années.

Ce soir c’était le SigmaT18 à la Maison des Associations de Toulouse.

J’ai assisté aujourd’hui à 7 soutenances de stage d’étudiants de Master 2 de l’IUP ISI. Dans aucune d’entre elles n’a été mentionné Scrum ou agile. Des étudiants ont parfois fait du développement itératif, certains ont eu des réunions quotidiennes, guère plus.

J’ai le plaisir d’annoncer qu’avec mon ami Alexandre Boutin, nous organisons une formation consacrée aux serious games. Les jeux sérieux constituent une nouvelle façon d’apprendre extrêmement prometteuse. Ces ateliers ludiques sont le complément idéal d’une approche agile en permettant, par exemple, de construire collectivement un backlog initial à partir d’une idée de produit. Dans ce domaine de la définition de produit, les Innovations Games de Luke Hohmann font référence. J’en parle dans ce blog depuis longtemps et j’en utilise régulièrement en formation ou lors de coaching.

Je suis joueur : après avoir lu le billet de Gokjo Adzic hier, j’ai utilisé le jeu de la randonnée en montagne au début de ma formation Scrum dès aujourd’hui. D’habitude je demande aux participants à mes formations quelles sont leurs attentes en leur demandant d’écrire ça sur des post-it de façon individuelle. Le jeu de la randonnée en montagne permet d’aller plus loin. Premier atelier collectif, il facilite la constitution du groupe et c’est important dans une formation inter-entreprises. J’ai trouvé les résultats intéressants pour mes deux groupes :

… avant les vacances. La formation que j’ai donnée la semaine dernière à Paris était très agréable. Merci à Anna, Doriane, Arnaud, Florent, Gérald, Sébastien, Paolo, Thomas et Xavier pour leur participation active. Ça fait plaisir de voir un groupe se former aussi vite et rester aussi motivé jusqu’à la fin des 3 jours. Plein de questions intéressantes et pas que d’Arnaud[1]. Ils peuvent s’honorer d’avoir suivi une formation agréée Fédération Agile. En plus, et ce n’est pas surprenant, ils ont obtenu de très bons résultats au QCM, un questionnaire de 70 questions que je propose à la fin de mes formations.

Demain, je pars en virée au Pays Basque avec Thierry Cros. Dans leurs discours, les agilistes mettent en avant l’importance du collectif, avec l’équipe. Mais quand nous faisons des formations ou du coaching, nous sommes seuls, la plupart du temps. Sauf à faire de l’accompagnement intensif qui laisse le temps de s’immerger dans une équipe, nous devons souvent prendre des initiatives et faire des proposition tout seuls. Bien sûr, nous nous retrouvons régulièrement dans les conférences, les associations ou même pour un panier repas.

Voire la 5ème colonne, si on compte la colonne Story. Dans ce tableau des tâches qui représente le plan du sprint en cours, on trouve, avec la disposition la plus classique : la colonne de gauche dans laquelle sont placées les stories du sprint, 3 colonnes pour visualiser l’état des tâches : à faire, en cours ou fini.

Il y avait les scrum cafés, les apéros agiles et maintenant il y a le panier repas agile. Le premier a eu lieu le 15 juillet à Bages dans l’Aude(11). Bages-ile ? Non presqu’ile seulement !

En tant que consultant, j’ai la chance de travailler dans des domaines variés. Après avoir accompagné Sarenza.com dans sa transition radicale et à grande échelle à Scrum[1], j’interviens sur le projet Sirius du CNES avec Thalès. Il s’agit de développer le patrimoine de base de la dynamique du vol, sur lequel viendront se construire les futurs outils opérationnels pour les mises à poste et maintien à poste de satellites. Sirius consiste en des bibliothèques Java sur la base de OREKIT et Commons Math.

J’avais écrit au printemps deux articles montrant comment on pouvait mâtiner Scrum avec des notions venant de Kanban. La mise en œuvre de ce ScrumBan était présentée avec un usage d’iceScrum. Quelques mois plus tard, après du feedback d’utilisateurs et une utilisation poussée, j’ai remis à jour les articles :

Nouveau, un quiz !

La première question était la suivante : Le sprint de 3 semaines a commencé vendredi, avec une équipe de 10 personnes. Le lundi lors du scrum du matin, on apprend qu’un développeur s’est cassé le bras droit au ski, il est plâtré pour une semaine.

J’ai appris la mise à jour du guide Scrum de Ken Schwaber et Jeff Sutherland quelques jours après avoir envoyé le bon à tirer pour la deuxième édition de Scrum, le guide pratique etc…

La question portait le Product Owner : Un sponsor important du projet tient beaucoup à une fonction mais ne sait pas bien de quelle façon elle pourrait être proposée aux futurs utilisateurs du produit. Vous êtes Product Owner, que faire ?

La nouvelle édition du guide Scrum présente la planification de release comme une pratique en dehors de Scrum : La planification de release est intéressante lorsqu’on pratique Scrum, mais n’est pas exigée par Scrum lui-même. C’est une évolution car dans la version précédente, même si ce n’était pas toujours bien cohérent, la planification de release était présentée comme une pratique Scrum. Faire un plan de release, c’est effectivement souvent utile, notamment quand on a besoin de se synchroniser avec d’autres équipes ou d’autres services de l’organisation.

La couverture de la deuxième édition fait un peu plus rugby. Je l’avais réclamé dès la première édition, mais à l’époque ça ne se faisait pas.

La question était la suivante : Une personne dans l’équipe perturbe les autres. Vous êtes Scrum Master, comment réagissez-vous ?

Une présentation de Tom Grant, analyste chez Forrester, met en évidence l’intérêt des jeux sérieux pour favoriser l’innovation dans les sociétés qui développent des produits : Corporate Serious Games Are Changing The Rules Of Product Development Il montre que pour faire face aux 3 grands problèmes dans le développement : la complexité, le manque d’implication des clients et la difficulté à maintenir la dynamique de groupe, il est temps de changer les règles. Il présente les jeux sérieux comme un excellent moyen de susciter des idées et de faciliter la prise de décisions.

Un produit sort avec sa release note et nous sommes le 7 septembre, date prévue pour la publication de l’édition 2 de mon livre Scrum.

L’énoncé était le suivant : Pour réaliser la story « tableau de bord », il faut que le composant qui envoie les données fonctionne. Il est développé par une autre équipe. Vous êtes en train de mettre à jour le plan de release, à quelques jours du démarrage du prochain sprint.