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. J’ai distillé ici une partie des ces exercices que l’auteur a mis à disposition. 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 !

Ce survol ne fait que picorer dans le différents sujets. Il y a mieux à faire : lire effectivement les workouts. Ou encore mieux : acquérir le livre de Jurgen … il y a de nombreux autres workouts à découvrir !

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.

La résistance contre l’ISO 29119 s’organise !

Au départ…

Les agilistes ne sont guère friands de normes et autres standards. Généralement, nous nous contentons de les ignorer. Néanmoins ils sont souvent utiles.

C’est en proclamant l’utilité des standards, de la plupart des standards que James Christie commence sa présentation lors de la conférence CAST 2014, celle par laquelle tout a commencé. Car c’est contre les standard de test que s’élève le présentateur. Son propos rappelle celui de Dominique Dupagne dans La revanche du rameur qui clame que standardiser les processus n’assure en aucun cas la qualité du produit, qu’en fait il s’agit même d’une bonne occasion pour s’en désintéresser !

La question de considérer l’activité de test comme un « commodité » tend à donner une dimension directement économique à ce travail, ce que l’orateur juge trop simpliste (il a lui-même un diplôme en économie). De manière générale, il est d’ailleurs toujours possible de trouver une théorie économique correspondant à ce que l’on cherche à prouver ! James Christie nous ramène lui à Adam Smith, le père du capitalisme et ses 3 facteurs économiques : le travail, le capital, la propriété.

En alignant les processus de tests, les organismes de normalisation servent les cabinets de conseils qui pourront ainsi vendre du conseil sur ces processus normalisés. Les éditeurs devront eux dépenser de l’argent pour se conformer aux normes. Finalement, le consommateur y perdra aussi, car le focus des éditeurs se déplacera de la qualité du produit vers le respect des normes de processus !

La standardisation de l’activité de test nous amènerai vers une « licence » de testeur qui ne serait en aucun cas gage d’efficacité, ce que l’orateur trouve effrayant ! Imaginez un chirurgien : elles-vous jugez de sa qualité du fait du suivi d’un standard ou du nombre de personnes qu’il tue ? Le focus de ces standard est la documentation plutôt que le test réel !

Un autre point soulevé par James Christie est celui de l’asymétrie de la connaissance : plutôt que de communiquer la connaissance à celui qui en a besoin, le standard masque celle-ci par un écran de fumée. Il se réfère aussi aux pratiques d’audit : celles-ci disent qu’il n’y a pas 2 contextes IT semblables, ce qui rend caduque toute idée de checklist générique (institute of internal auditors). Les standards promeuvent plutôt une idée de « sauver ses fesses » en suivant celui-ci à la lettre afin d’être irréprochables !

Finalement l’orateur exhorte le publique à garder ouvert ce début contre l’ISO 29119, car l’absence de consensus seulement permettra de le remettre en cause.

Au fait, c’est quoi l’ISO29119 ?

Tout d’abord, la parole à l’avocat de la défense, Stuart Reid, avec cette introduction à l’ISO 29119

L’ISO 29119 se veut un consensus sur la manière de procéder des tests, c’est une démarche normalisée comprenant définition des processus et de la documentation. Elle est déjà mise en oeuvre par certains cabinets de conseil.

La résistance s’organise

Tout d’abord avec un manifeste, initié lors de cette même conférence CAST 2014 !

image

Une pétition fait suite à cet acte de foi. Difficile toutefois de s’opposer au corporatisme, mais cette communauté a choisi aujourd’hui de ne pas se laisser faire !

Je voulais saluer ce mouvement, bien que n’étant pas testeur, non seulement pour leur courage de défendre leurs idées, mais surtout parce qu’ils ont raison !

Autres ressources

Improvement Dialogue, un Management Workout par Jurgen Appelo

C’est de « l’appreciative inquery », des questions puissantes et du théatre d’improvisation que veux s’inspirer Jurgen Appelo aujourd’hui.

Ensembles auto-catalytiques et coaching personnel

Les ensembles autocalytiques n’ont besoins d’aucun éléments autre que leurs constituants de base pour interagir et former de nouveaux constituants. Transposé aux organisations, il s’agit de groupes où « chaque participant renforce et accélère la productivité des autres ».

Si le coaching personnel est souvent considéré comme une composante majeure du développement personnel, alors une organisation où chaque membre est coachée par une autre peut être considérée comme une forme d’ensemble autocatalytique ! Cette dynamique de coaching interne doit prendre en compte 2 aspects :

  • Un coach ne doit pas être la seule autorité à laquelle se référer pour tous les problèmes auxquels faire face : votre coach agile ne sera pas votre coach santé !
  • Les personnes ne se coachent généralement pas deux à deux.
  • La relation de confiance entre coach et coaché doit être réelle.

Les échanges entre coach et coaché ne sont pas des choses à planifier de manière militaire. Ces moments arrivent quand cela parait propice et nécessaire.

Le « one on one »

Le « one on one », c’est d’abord l’un des outils favoris d’Esther Derby, qu’elle développe dans son livre Behind the Closed Doors. L’auteur rappelle quelques points essentiels de cette pratique :

  • En faire régulièrement : tous les 1 à 4 semaines, donc souvent !
  • Un agenda adapté à la personne que l’on rencontre.
  • Une attention pleine et entière des deux participants. Donc pas d’interruption, qu’elle soit humaine ou matérielle.
  • Ils ne doivent pas donner l’impression à aucun des participants d’être trop coûteux !

Les finalités du « one on one » et du coaching personnel sont très proches, sinon identiques (aider la personne à se développer et améliorer son travail), mais la posture d’un coach et celle d’un manager sont différentes.

On ne saurait donc substituer l’un par l’autre ! Jurgen Appelo s’inscrit contre l’idée du « manager en tant que coach », qui renforce les liens de hiérarchie au lieu de faire grandir les liens de relation « en réseau » au sein de l’organisation !

Binômage à tous les étages

Le binômage est une pratique connue et reconnue en développement. Elle apporte nombre de bénéfices tels que la montée en compétences, le focus sur un sujet ou la revue en continu. Réfléchir à haute voix ou compenser les moments de faiblesse du gars d’à côté sont aussi des opportunités d’arriver à résoudre des problèmes complexes.

Parfois le binômage peut se transformer en coaching lorsque, par exemple, on est d’avantage dans une relation de maître à élève.

De l’appreciative Inquiry au théâtre d’impro

Cette approche promeut l’idée qu’enquêter est le moteur du changement. Mais qu’une enquête objective est impossible. On surmonte cela en ce focalisant sur « ce qui est possible » plutôt que sur ce qui va mal, plutôt que de rentrer dans une logique qui ne fait souvent qu’empirer le problème.
Engager un changement persistant dans une organisation se fait par le biais d’une attitude positive, en misant sur les forces. L’appreciative inquiry nous invite à interagir de manière positive, dans nos questions et nos dialogues.

Les questions puissantes (powerful questions) stimulent la reflexion par la profondeur qu’elles induisent, elles focalisent sur un périmètre qui est dans notre sphère d’influence et nous guident vers des actions à venir plutôt que vers des blâmes ou des justifications.

Nos dialogues peuvent eux, s’inspirer du théâtre d’improvisation. L’une des règles de cette activité est de respecter le contributeur précédente et d’y contribuer à notre tour d’une manière positive, qui le valorise. Une des autre règles est de privilégier les déclarations aux questions, car elles font avancer la conversation. Pour Jurgen Appelo, il s’agit là d’un autre exemple d’autocatalyse.

Les quatres zones

Ce sont 4 cercles de dialogues qu’identifie Jurgen Appelo, que l’on parle de coaching, de one on one, etc… Au sein de ces cercles, l’auteur nous propose de développer des « inquisitive statements » qui sont, comme on peut l’imaginer, une convergence entre l’appreciative inquiry et le théâtre d’improvisation !

Les choses personnelles

Les désirs intrinsèques, les ambitions, les émotions, etc.. ont leur place ici. Jurgen nous propose de développer 40 « inquisitive statements » pour contextualiser nos points forts : je suis bon quand je…, mes besoins les plus importants sont…, j’apprends mieux quand…, etc..

Les choses relationnelles

On y développe tout ce qui a trait aux relations et collaborations entre personnes, que ce soient des relations de pairs ou des relations hiérarchiques. Parmi les 40 « inquisitive statements » proposé par Jurgen, on trouvera des éléments tels que : J’attend de nos conversations que…, Nous sommes tous deux motivés par…, Tu peux m’aider en faisant…

Les choses organisationnelles

Les éléments de ce cercle concernent les aspects organisationnels, le changement et autres aspects systémique de l’organisation. Parmi les 40 « inquisitive statements » on trouvera : J’attend de l’organisation que…, Je peux me rendre compte que l’organisation progresse parce que…, Je suis fier de notre organisation quand…

Les choses environnementales

Que se passe-t-il en dehors de notre cercle restreint ? Qu’en est-il du marché, de nos clients ou de nos concurrents ? Ce cercle adresse les aspects contextuels. Au hasard des 40 « inquisitive statements » on croisera : Nos clients devraient être félicités parce que…, les raisons qui font que nos clients s’impliquent sont…, Ce que nos clients devraient arrêter de faire est…

What’s next ?

L’improvement dialogue, c’est piocher un « inquisitive statement » et devoir le compléter d’une manière positive et affirmative. Puis laisser la conversation se dérouler à partir de là. Le but de ces conversation est de parvenir à catalyser des actions. Durant ce dialogue, les déclarations de chaque personne doivent être accueillies comme des faits !

Comment y arriver ? Jurgen Appelo nous propose une démarche en 6 étapes, applicable dès demain !

Mais l’étape 0 reste de lire dès à présent son workout !

Agile Playground #17 : En interlude…

Nous avons conservé ce mois-ci la formule du mois précédant : un démarrage en mode « place de marché » d’un forum ouvert ! Dans la pratique, nous n’avions pas de jeu « à expérimenter » ce mois-ci. Mais Alexis Nicolas avait amené un Kanbanzine. C’était fort à propos !

image

Finalement, deux « ice breakers » et 2 jeux furent retenus pour cette soirée. Outre le Kanbanzine et l’ice breaker dont j’ai oublié le nom, je me suis donc retrouvé mis à contribution sur un ice breaker que j’avais proposé … et un « remember the speed boat » pour satisfaire une demande de mettre en oeuvre des innovation games !

Cassons la glace des estimations agiles !

Pas tout à fait en estimations agiles, en fait. Il s’agissait plus d’expérimenter une approche d’estimation inspirée du Wide Band Delphi. Une version un peu simplifiée, en fait.

1 – On forme plusieurs groupes

2 – Je propose un sujet à estimer.

3 – Chaque groupe discute entre eux pour déterminer une estimation durant 2 minutes

4 – Les groupes partagent les éléments les ayant conduit à choisir cette valeur.

5 – On fait un nouveau tour de ré-estimation d’une minute.

Est-ce parce que nous avions un parterre d’agilistes « chevronnés » ? Aucun groupe n’a jugé nécessaire de réviser l’estimation au second tour (bien qu’avec quelques hésitations). A tord. La réévaluation les auraient fait converger vers la bonne direction !

Remember the Speed Boat

Mariage forcé entre le « Speed Boat » et le « Remember the future », il s’agit d’une combinaison qui me parait aujourd’hui naturelle. Par contre, cette animation était un peu improvisée et j’avoue ne pas avoir été excellent. Hélas. Le sujet, s’il était fun, n’était pas non plus évident à mener à bien : Organiser une visite privatisée au Taj Mahal, avec nuit sur place … mais à un prix raisonnable !

image

Nous avons pu mener notre projet fictif (plus ou moins) à bien. Nous avons terminé en discutant librement des apports de cette approche. Finalement, notre jeu aura atteint son but, car plusieurs des participants vont s’y essayer.

image

Pendant ce temps, le Kanbanzine

Nous avons terminé un peu plus tôt que le second groupe. C’était donc l’occasion pour moi d’entretenir une petite frustration réccurente : cela fait déjà un certain temsp que j’aimerai tester le Kanabanzine ! Chaque fois je rate l’occasion à pas grand chose ! Mais un jour, j’y arriverais…

image

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

Pourquoi BPM ?

C’est une question essentielle, car il serait irréaliste de penser que BPM est une évidence pour les entreprises. Il s’en faut de beaucoup. Nous ne sommes que 40 ce soir, et non des centaines !

Le BPM, c’est avant tout voir les processus de l’entreprise comme des activités répétables. Un outil BPM modélise non pas des processus, mais des templates de processus ! les processus eux-mêmes en sont les instances.

Par rapport à ces processus, et oserais-je dire par rapport à la « normalisation de ces processus », BPM permet une agilification avec une réelle facilité d’amélioration et de déploiement de ces nouvelles versions de processus. Nous aurons l’occasion de revenir sur cette conjonction entre agilité et BPM qui est en fait bien plus complexe, lors d’une prochaine rencontre. Pour Tom Baeyens, cela s’articule en 4 éléments principaux.

1 – L’organisation des tâches

Un modèle BPM permet non seulement de définir, mais surtout d’implémenter « qui fait quoi », et d’éviter ainsi les incompréhensions entre acteurs.

2 – Le bon niveau de contrôle

Un moteur BPM permet de garantir le respect des règles telles qu’elles sont définies et appliquées. Hum ! Voici une déclaration qui a bien plus des relents de Taylorisme que d’agilité ! Toutefois, le BPM permet aussi de laisser libre le fonctionnement au niveau ui est décidé ! D’ailleurs l’un des apports les plus intéressants d’Effektif est l’intégration d’une notion de « case management » au sein de l’outil !

3 – Transparence sur ce qui se passe

Un moteur BPM permet de centraliser les informations sur l’activité, permettant de savoir qui fait quoi, mais aussi de remonter aux causes racine d’un problème en s’appuyant sur un audit trail.

4 – Coordination de grand volumes de processus

Un moteur BPM permet de monitorer ce qui se passe sur plusieurs milliers (millions ?) d’instance de processus simultanément, et d’assurer la consistence de leur traitement. Comme le dit Tom, cela permet aussi de surveiller les « employés distraits ». Quand je vous parlais de Taylorisme…

image

Qu’est-ce qui a changé ?

Le BPM n’est pas un nouveau-né ! C’était déjà un sujet d’actualité au début ou au milieu des années 90 quand la modélisation était l’une de mes activités principales ! Mais le paysage a incontestablement changé ces dernières années. Tom Baeyens concentre son propos sur 3 points

1 – Le cloud dans l’entreprise

L’utilisation des services est aujourd’hui une évidence, que les DSI le veulent ou non. Et dans ce cas, elles se font tout simplement contourner ! Toutefois les reservoirs d’information n’ont pas disparu des entreprises, et il faut savoir fonctionner en environnements hybride !

2 – Focus sur l’expérience utilisateur

Les applications d’entreprise sont traditionnellement mauvaises sur cet aspect. Et au sein des applications d’entreprises, les applications BPM seraient plutôt les pires ! Pourtant, être incapable de proposer une expérience utilisateur de qualité dans ce domaine n’est pas une fatalité : IFTT fait un excellent travail à cet égard, avec ses « recettes » !

Autre problème dans ce domaine : la surcharge d’emails ! Hélas, s’en passer semble illusoire, car l’email reste le plus petit dénominateur commun ! Mais les outils de case management tels que Yammer, Jive, Huddle ou Asana permettent d’entretenir des « discussions riches » auxquelles on peut ajouter du contexte et garder tout le monde dans le même échange !

3 – Le point de souffrance du BPM

Le BPM est une problématique métier. Hélas, il ne faut pas longtemps pour que cela devienne un projet IT ! Et avec cette transition arrive les questions de management « lourd », les temps de cycle long… Il est nécessaire de séparer la partie « expérience utilisateur » de la partie « projet IT ». Car ne rêvons pas : la customisation nécessitant de faire des développements restera vrai !

Voici Effektif

Effektif permet de laisser entre les mains des utilisateur métier la modélisation des processus, tant que celle-ci reste simple. Et l’on s’inspire ici de ce que fait IFTTT ! Puis l’outil dispose d’API pour permettre d’y adjoindre des traitements « custom »!

Il est temps de passer à la démo. Plutôt que de la décrire, je vous propose cette vidéo, hélas d’assez mauvaise qualité : je n’étais pas très bien placé et tenir un appareil photo à bout de bras pour filmer pendant 20 minutes … eh bien il y a mieux ! Désolé donc pour l’effet « mal de mer » si vous avez le courage de la regarder !

Techniquement, Effektif s’appuie sur des choses assez simples : Tomcat et MongoDB ! Et encore, seul le moteur de servlet de Tomcat est réellement utilisé. Pour Tom Baeyens, le début de l’aventure commence bien, avec le reconnaissance de la validité de son modèle par le Gartner ou Tech Crunch. Et bien d’autres choses dans la roadmap…

Vous avez raté la performance de Tom et ma prose vous laisse de marbre ? Voici la vidéo !

BPM dans un contexte industriel, par Fayçal Mehrez

C’est d’analyse de la performance d’entreprise avec le PLM dont Fayçal va parler. Pas évident d’évoquer ce sujet qui n’est pas réellement attendu par le public !

Quand on parle PLM, on pense souvent « outil de PLM ». Mais le PLM c’est avant tout un processus, un concept structurant de gestion de produit pour dire à une société comment elle doit fonctionner. Décidément, je suis verni ce soir : après le Taylorisme, voici venir l’ERP dans son habit de lumière !

Trêve de plaisanterie : ce dernier point fait la jonction avec l’univers du BPM, car la démarche PLM passe par la mesure de la performance, une chose que permet justement les moteurs de BPM !

Il y a 3 axes à cette démarche :

  • Une méthodologie de performances
  • Une démarche de transformation
  • Une approche BPM
image

Parlons de performances

Attention, quand on parle « performances », on pense souvent à la performance financière uniquement. C’est une erreur. Par exemple, dans un processus RH, la performance ne concerne pas le coût du processus d’embauche, un aspect qui est en fait souvent marginal, mais bien l’adéquation par rapport aux besoins futurs de l’entreprise, la réduction du turn-over, etc.

Par ailleurs, la performance ne se décrète pas, mais se construit.

Mais aussi, dans un cadre PLM, on peut avoir un objectif stratégique de réduction du « time to market ». Cet objectif se décline en objectifs opérationnels, comme par exemple réduire le délai de développement.

Pour ce faire, on développera plusieurs axes :

  • Améliorer la conception
  • Réduire les volumes de développement
  • Multiplier les ressources

Quels outils pour mettre en oeuvre cela ?

C’est également une démarche de transformation

Il n’y a pas d’outil unique dans cette démarche. L’un des classiques est le Balanced Scorecard. Fayçal préfère la « feuille de route stratégique ». On parle bien de feuille de route, et non de carte ! Si j’ai bien compris, elle aide à partir des objectifs stratégiques à décliner les objectifs opérationnels à l’aide d’une approche type « 5 pourquoi ». Mais en vérité, je ne pense pas avoir tout suivi correctement.

L’autre volet de cette transformation, ce sont les hommes ! 80% de la performance vient de l’humain. Aussi est-il important de donner du sens à ces changements. Enfin un point commun avec l’agile ! Et n’oublions pas que la première étape d’une transformation est une baisse de performance !

L’apport du BPM

Le BPM permet de donner de la cohérence aux processus. La finalité du PLM est intrusive : obtenir des processus répétitifs et contrôlables. De nombreux aspects de l’intérêt du BPM dans une démarche PLM me rappellent les finalités de l’urbanisation des systèmes d’information (décidément, je boirais la coupe jusqu’à la lie) : partir de standard de processus, permettre l’alignement sur les processus (alignement d’un peu tout).

Petites reflexions personnelles

Ne nous voilons pas la face : nous étions venus pour Tom Baeyens ! Il ne nous a pas déçu, autant par la clarté de sa perception du BPM que par sa démonstration d’Effektif !

Le thème abordé en seconde partie est assez éloigné de mes préoccupations. Mais il met en relief certains éléments que je percevais quelque peu : le monde du BPM reste fondamentalement assez éloigné de celui de l’agilité. Un avis à tempérer toutefois avec la flexibilité qu’il permet d’une part, et l’ajout de dimensions « non prédictives » d’autre part !

Bref, cette session m’aura aussi alimenté en reflexions sur le BPM et l’agilité, bien plus que je ne l’espérais. Et cela nous donnera du grain à moudre pour une future rencontre « BPM Pro » !

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 !