12 leçons (durement) apprises de transition agile : le live !

Ça a marché pour moi, mais je ne pas garantir que cela marchera pour vous … peut-être la 13ème leçon à garder en mémoire en visionnant mon intervention lors du Printemps Agile 2015.

J’avais posté ici-même le support de présentation il y a peu. Si vous acceptez d’en prendre pour 50 minutes, le propos vous éclairera encore d’avantage. Si j’ai le courage, je convertirais même le tout en article comme je l’ai fait pour la plupart de mes présentations. Mais il faudra être patient.

Si l’éclairage est loin d’être parfait, c’est difficile à nier (et difficile à gérer avec une projection), le CEMU a fait un remarquable travail de montage avec le support. C’est une excellente surprise, qui va bien plus loin qu’une simple synchronisation. Merci et bravo à eux.

Une transition agile en 12 leçons apprises

J’avais évoqué il y a peu le Printemps Agile 2015. J’y ai présenté un retour d’expérience sur le projet Linky en 12 « patterns » pratiques pour accompagner cette transition. Voici le support de ma présentation, en attendant la mise en ligne de la vidéo et une hypothétique version rédigée.

Linky, c’est le grand projet ERDF de mise en place du « compteur intelligent ». Une grande aventure qui a amené le plateau de développement Parisien (12 équipes de développement) à basculer vers un fonctionnement agile. Cette présentation ne raconte pas l’histoire du projet : Jean-Hugues Hamelin et Nadim Elbaba qui la vive de l’intérieur depuis un bout de temps l’ont raconté avec plus de pertinence et d’intérêt que je n’aurais pu le faire lors du ScrumDay 2015. Non, ici c’est de mon point de vue de coach accompagnant ces équipes que je parle.

Management Workouts 3.0, par Jurgen Appelo

Management Workout, c’est le titre du dernier ouvrage de Jurgen Appelo. Le management workout, ce sont des exercices conçus pour pouvoir être mis en oeuvre « dès lundi matin » ! Cette présentation en survole un certain nombre.

  • Improvement dialogues : Ou comment générer des conversations nous guidant vers l’action.
  • Personal Maps : Ou comment gérer la relation à son travail et à ses collègues en terme de distances physiques et cognitives.
  • Kudo Box : Savoir valoriser le remerciement, c’est déjà changer la dynamique des relations dans une organisation.
  • Work Expo : Une organisation doit savoir être fière du travail de ses collaborateurs… et le montrer !
  • Project Credits : Comment penser le titre de votre job ou gérer votre réputation ?
  • Salary Formula : Comment concevoir les abaques salariaux ?
  • Delegation Board : Où comment partager le niveau de décision entre managers et équipes.
  • Metrics Ecosystem : Comment mesurer la performance d’une organisation et quels sont les impacts de ces pratiques ?
  • Merit Money : Le système des bonus ne porte pas la collaboration que l’on souhaiterai dans l’organisation. Repensons la façon de rétribuer !
  • Yay Questions : Des questions qui nous invitent à célébrer ce que nous avons bien fait !

Lire la suite

Scrum Shu Ha Ri, le live

Voici la vidéo de ma présentation « Scrum Shu Ha Ri » faite lors du Printemps Agile organisé à Caen. Un grand merci à l’équipe du CEMU qui a effectué la prise vidéo et le montage.

Vous pouvez retrouver cette vidéo (et d’autres du Printemps Agile) sur cette page. J’avais par ailleurs fait deux posts sur cette conférence, accessibles ici et ici, et une galerie photo visible ici.

Le support de cette présentation se trouve ici. J’ai par ailleurs rédigé un article un article s’appuyant sur le matériel de cette présentation que vous trouverez ici.

Quand Tom Baeyens inaugure le BPM Professional Group

Quand on pense BPM et Open-Source, on pense toute de suite à jBPM ou Activiti ! Derrière ces 2 projets, un même homme : Tom Baeyens ! On ne pouvait rêver mieux pour inaugurer le BPM Professional Group au zLocalHost de Zenika ! Ce ne sera pas le seul intervenant de cette soirée, car Fayçal Mehrez viendra nous parler d’indicateurs de performance en entreprise et de l’usage de BPM dans ce cadre !

A la découverte d’Effektif, avec Tom Baeyens !

Effektif, c’est la nouvelle structure de Tom Baeyens, qui s’éloigne maintenant d’Activiti et Alfresco pour une nouvelle aventure. Mais ce n’est pas pour faire la promotion de son outil qu’il sera là ce soir, mais bien pour nous parler de BPM.

image

Lire la suite

Agile at Home, par Henrik Kniberg

Changement de décors pour cette nouvelle présentation de Henrik Kniber : comment mettre en oeuvre les pratiques agile et Lean à la maison avec 4 enfants !

Kanban

D’abord le Kanban. Il y en a un peu partut chez les Kniberg ! Un Kanban commun pour les tâches partagées, sur le réfrigérateur pour les enfants ou encore pour préparer un barbequeue entre amis.
La famille Kniberg est partie durant 8 mois pour un « familly trip » autour du monde. Il y a eu un Kanban pour préparer cela aussi. Cela comprenait d’ailleurs une expérimentation du concept, avec un séjour de 4 jours à Londres.

WIP limite

Un problème récurrent avec les enfants : le bordel dans la chambre ! Un problème qui ne s’est pas posé durant leur voyage, car la quantité d’affaires à transporter était limitée. Alors on utilise le même système : on limite le nombre de vêtements à ce que peuvent contenir les tiroirs !
Un système qui s’étend ensuite à la cuisine, pour le lavage de la vaisselle, avec une pincée de « definition of done ».

Burnup chart

Junior a du mal a être dans les clous avec ses devoirs ? Son coach de père lui met au point un burnup chart a suivre lui-même au fur et à mesure qu’il fait ses devoirs.

Autres management visuel

Cartes, « dream gallery », Kaizen boards, Henrik Kniberg n’hésites pas non plus à utiliser tout l’arsenal de management visuel à sa disposition.

Ce que j’en pense

Une vraie mise en oeuvre des principes agiles dans la vie réelle. C’est même assez impressionnant, je dois dire, même si je sais que certains de mes confrères s’essaie au même genre de chose..

Et moi alors ?

Eh bien non. En ce qui me concerne, je préfère laisser mon arsenal d’agiliste hors de la famille…

Le guide Scrum, millésime 2013

On a pu voir différents retours sur le Scrum Guide 2013

Avant d’aborder le fond, ma première remarque: le document a de toute évidence été écrit avec Word sur Mac. Les auteurs ont utilisé le style par défaut sans rien changer aux styles proposés (Titre, titre 1, titre 2 et normal entre autres). J’aime bien aussi le copyright “1991-2013”, même si le premier article publié date de 1993…

Rentrons dans le fond.

La transparence

C’est un ajout par rapport aux versions précédentes. Bravo. Cela dit, c’est très centré “inspection”. J’aime bien la notion de “done partagée” (pour les items de backlog, car il y a aussi un “done” des tâches qui ne concerne que l’équipe), et pour moi la transparence passe plus par le partage d’information : tableau des tâches, backlog, etc… pas simplement à l’intérieur de l’équipe mais aussi à l’extérieur.

Le Product Owner

Cela n’a pas bougé depuis 2011. Mais je reste assez dubitatif de cette position qui créé un schisme entre l’équipe et le “responsable fonctionnel”. Je m’en étais ouvert dans ma rubrique “en finir avec” dans un post dédié aux Product Owners. Ma position n’a pas changé, et ce partage des eaux ne m’a jamais semblé agile.

La Scrum Team

Comme d’autres, je pense qu’une taille de 9 est le début de la rupture. En fonction de la dynamique de groupe, ça peut tenir ou pas, ou la rupture peut être avant. Quand je dis “rupture”, je veux dire qu’en fait l’équipe se restructurera d’elle-même en sous-groupes de manière informelle. Pas la peine de luter, ça se passera de toute façon.

De toute manière, l’art de fixer une taille est un peu osé. Une équipe de deux, ça peut marcher et avoir un sens pour certains projets, même en Scrum !

Le Sprint

Plus ça va, moins j’aime le mot “sprint” qui a trop une connotation de “rush” à mon goût. Itération me va bien. Bien sûr l’insistance sur les 30 jours (même si l’on précise que cela peut être moins) devient drôle. Plus personne au monde, à part Ken Schwaber et Jef Sutherland, ne parle d’une limite maximum à 30 jours, mais bon…

Planning meeting

Comme mes petits camarades, j’ai noté la présence du “sprint goal”. Voici une évolution que j’accueille à bras ouverts ! Depuis pas mal de temps déjà je commence mes planning meeting ainsi, et note cet objectif sur un A3 qui figure ensuite au-dessus du tableau des tâches. Il est vrai que j’arrive rarement à faire une itération avec un seul objectif, mais je ne dépasse jamais 3.

Quoi qu’il en soit j’ai pu noter une différence extrêmement importante de motivation et de productivité entre des sprints ayant un objectif clair par rapport à la vieille méthode “liste à la Prévert” qui nous transforme plutôt en ouvriers spécialisés ! C’est ce qui aide à créer du plaisir et de la motivation : donner du sens à notre travail. C’est bien plus efficace que de coller des niko-niko au mur…

Bravo pour cette évolution qui va dans le bon sens !

Daily Scrum

De manière concomitante, le Daily Scrum prend une orientation qui est en concordance avec le “sprint goal”. C’est pure logique.

Un effet de bord est que l’on parle moins d’engagement sur la liste des stories (voir plus du tout) mais d’engagement sur le but du sprint, qui donne la souplesse d’adapter le contenu en cours de route pour rester dans la ligne de l’objectif mais éventuellement en déscopant des choses !

C’est encore une évolution que j’apprécie. Je n’ai jamais été à l’aise avec la notion d’engagement telle qu’elle été exprimée. Pour moi, l’engagement est moral. La qualité et la conformité au “done” doivent être maintenus coûte que coûte. L’engagement sur une liste de stories est pour moi une manière de demander à l’équipe de s’enchainer volontairement. Elle est le stigmate d’un manque de confiance et au bout du chemin demande implicitement de renoncer au “rythme soutenable”, ce que je n’accepte pas non plus.

On a ce pour quoi on paie. L’engagement sur un ensemble de stories se paie. Souvent en rush avec à la clé une qualité abdiquée, des heures sup’ avec une conséquence désastreuse sur le moral et la confiance et le plus souvent un cocktail de tout cela. Le tout en parfaite conformité avec les valeurs du management contrôle/commande que l’on prétend avoir abandonné !

Ce qui peut paraitre un petit ajustement est pour moi un gros virage dans le bon sens !

Sprint review

Apparemment il fait toujours 4 heures ! Bon je sais que l’on parle d’itérations d’un mois que personne ne pratique. Mais cette durée est ridiculement longue. Je vise une heure maximum pour une iteration de 2 semaines. Et c’est plus souvent de l’ordre de 30 minutes. Bref, je suis aligné sur Pablo visiblement sur cet aspect.

D’ailleurs la pratique des micro-démo tend à conforter la durée de 30 minutes, voir moins.

Sprint rétrospective

Je me suis fait la même remarque que Pablo: il est curieux qu’elle soit plus courte que la démo. Mes rétrospectives sont à peu près toujours de l’ordre de 2 heures pour 2 semaines. En fonction du contexte, ça peut aller jusqu’à 2h30 ; il est plutôt rare qu’elles soient plus courtes.

Product backlog

On parle d’items qui peuvent être complétés dans un sprint. Certes, mais pour moi cela reste une granularité bien trop élevée ! Difficile d’être adaptable au sein d’un sprint si seule un item ou deux figurent au programme ! Mais bon, ce point n’est pas nouveau… Je dirais que là-dessus je suis clairement d’accord avec ce que Gilles Mantel met au programme de son Scrum Master Academy.

Surveiller les progrès vers un but

Ce point devrait être en principe en concordance avec ce qui est dit sur le sprint planning et le Daily meeting. Il ne semble pas, car on parle de monitorer à la fin de chaque sprint ! De plus je trouve que ce point n’est pas très clair…

La transparence, encore et toujours…

J’aime bien ce nouveau focus. Toutefois je le trouve incomplet. Tout d’abord il ne concerne que le “done” et la liste des items pris dans le sprint, alors que je pense qu’il doit s’étendre à l’ensemble des artefacts de l’équipe, notamment le suivi des tâches.

Ensuite pour moi la définition de terminé ne doit pas seulement venir de l’équipe, mais de l’ensemble des parties concernées par le produit : product owner, opérations, hot line s’il y a lieu, etc…

En conclusion

Globalement, ce Scrum guide n’est pas une révolution. Ce n’est pas non plus ce que l’on attendait. J’aimerai bien que les auteurs abandonnent une fois pour toute leur notion de sprint d’un mois qui était déjà ridicule il y a 10 ans et est maintenant franchement embarrassante.

Mais de manière générale, je trouve que ce Scrum guide va dans le bon sens. Les auteurs ont résisté à la tentation d’alourdir Scrum. En fait ils l’ont même allégé de notions pas indispensables, comme celle de release. D’un autre côté, je suis un grand fan de cette notion de “sprint goal” qui nous éloigne d’idées précédentes pas franchement agiles.

Bon boulot, donc !

L’invention du mot « ordinateur »

C’est Jacques Perret qui, le 16 Avril 1955 inventa le mot « ordinateur », suite à une sollicitation d’IBM pour trouver une traduction Française au mot anglo-saxon (« computer » pour les machines scientifiques et EDS soit « electronic data system » pour les systèmes de gestion) ! Il faut en effet savoir qu’IBM a l’habitude de traduire l’intégralité de ses notices techniques sans y laisser traîner d’anglicisme.

Alors professeur à la faculté des lettres de Paris, il fut sollicité par un de ses anciens élèves pour cette traduction. Comme on le voit il proposa plusieurs termes, « ordinateur », ou plus exactement son pendant féminin « ordonnatrice » ayant sa préférence.

IBM a tout d’abord protégé le nom. Puis, rapidement adopté par les utilisateurs, la société a finalement décidé de le laisser dans le domaine public, quelques mois plus tard seulement.

Cette anecdote nous montre aussi que notre langue, que nous jugeons souvent inapte à capturer des termes liés à la technologie peut aussi faire naître des mots qui s’avèrent supérieurs à leur pendant anglo-saxon ! Il en va de même pour moi du mot « tableur », bien plus parlant que « spreadsheet »…

Cher Monsieur,

Que diriez vous d’ « ordinateur » ? C’est un mot correctement formé, qui se trouve meme dans le Littré comme adjectif désignant Dieu qui met de l’ordre dans le monde. Un mot de ce genre a l’avantage de donner aisément un verbe « ordiner », un nom d’action « ordination ».

L’inconvénient est que « ordination » désigne une cérémonie religieuse ; mais les deux champs de signification (religion et comptabilité) sont si éloignes et la cérémonie d’ordination connue, je crois, de si peu de personnes que l’inconvénient est peut-être mineur. D’ailleurs votre machine serait « ordinateur » (et non ordination) et ce mot est tout a fait sorti de l’usage théologique. « Systemateur » serait un néologisme, mais qui ne me parait pas offensant ; il permet « systémation » ; mais systemer ne me semble guère utilisable ; « Combinateur » a l’inconvénient du sens péjoratif de « combine » ; « combiner » est usuel donc peu capable de devenir technique ; « combination » ne me parait guère viable a cause de la proximité de « combinaison ». Mais les Allemands ont bien leurs « combinats » (sorte de trusts, je crois), si bien que le mot aurait peut-être des possibilités autres que celles qu’évoque « combine ». « Congesteur », « digesteur » évoquent trop « congestion » et « digestion » ; « Synthétiseur » ne me parait pas un mot assez neuf pour designer un objet spécifique, déterminé comme votre machine.

En relisant les brochures que vous m’avez données, je vois que plusieurs
de vos appareils sont désignés par des noms d’agent féminins (trieuse,
tabulatrice). « Ordinatrice » serait parfaitement possible et aurait même
l’avantage de séparer plus encore votre machine du vocabulaire de la
théologie.

Il y a possibilité aussi d’ajouter a un nom d’agent un complément :
« ordinatrice d’éléments complexes » ou un élément de composition, par ex. : « selecto-systemateur ». « Selecto-ordinateur » a l’inconvénient de 2 “o" en hiatus, comme « électro-ordinatrice ».

Il me semble que je pencherais pour « ordinatrice électronique ». Je souhaite que ces suggestions stimulent, orientent vos propres facultés d’invention. N’hésitez pas a me donner un coup de telephone si vous avez une idée qui vous paraisse requérir l’avis d’un philologue.

Votre

J. Perret

What to do when Scrum doesn’t works

Et d’abord, c’est quoi Scrum ?

Oui, je sais, on peut faire référence au Scrum Guide et à toute ces sortes de choses, mais pour Henrik Kniberg, ce sont :

  • De petits morceaux de fonctionnalités
  • Des équipes subdivisées en petites équipes
  • De petites tranches de temps.
  • Une valeur métier optimisée
  • Avec un processus optimisé !

Et c’est tout !

Pourtant, visiblement, tout ça peut mal se passer. Voyons comment et comment y remédier. Avec 5 cas de figure.

Mal utiliser le processus

S’en prendre à Scrum alors qu’il faudrait plutôt penser à notre façon de l’utiliser est le premier symptôme. Le grand classique est le temps consacré aux cérémonies : s’il est exagérément long, il s’agit simplement d’un avertissement, nous essayons de pratiquer Scrum comme une méthode classique !

Le fondamentalisme ne rend pas non plus beaucoup de services. Ils qualifient d’erroné tout ce qui ne marche pas en agile, tout comme ils qualifient de « cycle en V » tout ce qui n’est pas agile. Pourtant le cycle en V marche aussi dans le bon contexte…

Blâmer le messager

L’une des vertus de Scrum est de faire remonter les problèmes à la surface rapidement : le projet est trop gros ? La qualité n’est pas au rendez-vous ? Il est préférable de le savoir avant qu’après ! Or nous sommes habitués à vivre longtemps dans l’ignorance, il semble naturel de blâmer un processus qui va nous révéler des défaillances dès le premier mois… Il faut alors travailler de manière systématique sur ses faiblesses, via de l’analyse causale.

Henrik Kniberg pointe aussi les « Sadoscrumistes » : si ça fait mal, c’est que c’est bon…

L’impatience

Passer d’une procesus classique à un processus agile, c’est une courbe de changement. Et la première étape du changement, c’est le chaos ! La ou les premières itérations d’un projet agile peuvent donner des résultats moins bons qu’avant. Laissez un peu de sursis à Scrum !

Ne pas adapter le processus

Scrum est un cadre, pas un carcan. Si une pratique ne convient pas, il faut chercher à l’adapter plutôt que jeter brutalement Scrum !

Utiliser le mauvais processus

Certains contextes se prêtent mal à Scrum et plus précisément au rythme des itérations. Scrum n’est pas le seul processus agile ! Il ne faut pas être dogmatique, ce qui nous enferme dans le « Scrum Shu ». Evoluer, ce peut être se détacher de Scrum ou emprunter une autre voie telle que Kanban.

Autres Ressources