Mixit-14 : un grand cru

Mix-IT est une conférence dans le domaine du développement, de l’agilité et l’innovation. Elle se tient sur deux jours à Lyon. L’édition 2014 avait lieu les mardi 29 et mercredi 30 avril. Je m’y rendais pour la première fois.

Voici ce qu’a été mon programme.

Visualization – what’s my brain got to do with it?

Cette session de Mattias Skarin nous propose de parler du cerveau. Peut-on croire ce que l’on voit? Mattias nous présente le jeu des 7 erreurs en version hard-core. Une image n’est visible à l’écran qu’une demie seconde, puis disparait au profit d’un écran blanc, pendant encore une demie seconde et ainsi de suite pendant presque une minute. Gare aux épileptiques. Les flashs se succèdent. Personne ne trouve vraiment de différence entre chaque. Alors qu’en fait, plus d’une dizaine d’éléments ont changé, notamment un immeuble entier qui prenait un quart de l’écran.

Où veut-il en venir? Le cerveau est limité dans sa capacité à analyser une image complexe et retenir des éléments clés. Le rapport avec cette conférence? Les méthodes agiles mettent souvent en avant le management visuel. Notre attention doit être attirée vers les points importants. Attention donc à la densité d’information que l’on met sur nos boards !

Developing great Scrum Masters

Après une première session stimulante, je continue avec le très vivant Angel Medinilla. L’intitulé de la session me plait beaucoup. C’est une session haute en couleur qui s’annonce.

Angel commence à faire le tour des méthodes agiles pour tenter de trouver le rôle de Scrum Master. A quoi sert-il? Ce n’est ni expliqué dans le manifeste agile, ni dans Kanban, à peine dans les méthodes XP, et la définition de son rôle dans la description de Scrum est très vague. Que doit donc faire le Scrum Master dans la réalité ?

Il entame une petite session de troll. Pas sur Kanban, mais sur le Nonban. C’est une voie que les équipes peuvent prendre en démarrant l’agilité. Scrum a l’air trop contraignant, Kanban, de prime abord, moins. Alors on fait du Nonban. Cela devient une excuse pour s’organiser n’importe comment, du moment qu’il y a des post-it au mur. Kanban ne doit pas être choisi comme méthode parce qu’il semble moins contraignant que Scrum. Essayer de bien étalonner ses limites de Work-In-Progress, c’est une autre histoire. Il continue en précisant que beaucoup d’équipes confondent auto-organisation et auto-management. Il a vu des mouvements de rebellions. Les équipes se sentent toutes puissantes et ne jurent que par une seule chose, l’anarchie. Ce peut être un mode d’organisation mais AGILE est différent d’ANARCHIE !

Pour Angel, le rôle du Scrum Master doit être semblable à celui d’un entraîneur pour un sport collectif. Il ne dit pas ce que doit faire chaque personne. Mais il s’assure que l’ensemble travaille ‘harmonieusement’ et avance dans un but commun. En anglais, EMPOWER TEAMS.

De par son expérience, il entrevoit trois types de Scrum Master :

• Scrum Dude: comme le Dude du Big Lebowski, il est plutôt cool. Il ne sait pas trop pourquoi il a ce rôle et n’y croit pas vraiment. Il décide alors avec l’équipe de faire du Scrum Dude tournant, car c’est un rôle pénible et chacun doit y participer. Les retrospectives sont inutiles. Scrum ne sert pas vraiment.
• Scrum Mum: c’est une version beaucoup plus autoritaire (on peut difficilement faire moins que Scrum Dude). Scrum Mum va s’assurer que les devoirs sont faits, que chacun contribue aux tâches communes et sépare les personnes quand il y a des problèmes. C’est une phase pendant laquelle le Scrum Master fait appliquer Scrum au pied de la lettre. C’est très confortable pour l’équipe. La dérive étant ensuite que l’équipe s’y habitue et que seul le Scrum Master porte Scrum dans l’équipe.
• Scrum Master: c’est selon lui le rôle attendu. Il est plus effacé que "Scrum Mum". Il laisse beaucoup plus de responsabilités aux personnes de l’équipe, s’effaçant petit à petit. Il assène de nouveaux les principes s’il considère que l’équipe dévie sans raison. Il règle les conflits entre les personnes plutôt que les éviter.

Amené avec beaucoup d’humour, c’était une session instructive. Ses slides, mêmes si elles ne sont pas totalement à jour, sont disponibles sur Slideshare.

Product Owner Super Powers

Dernière session de la journée. Cette présentation est donnée par Stefan Haas. C’est intéressant car la salle est majoritairement composée de PO. Car oui, c’est une conférence avec du PO dedans. Le but de la présentation: quel est le rôle du PO et quels sont ses outils? C’est une session très interactive. Stefan nous donne sa vision du PO: il est seul à explorer le terrifiant monde extérieur pour ramener des idées à l’intérieur de l’entreprise. C’est un explorateur. Et son chemin n’est pas sans embûches.

Pour Stefan, les PO peuvent manquer de structure pour partager et échanger entre eux. Avec #podojo, il organise des ateliers pour aider les PO et stimuler l’innovation dans une équipe. On parle alors de "Design Thinking", de serious games, de Lean Canvas.

Il nous questionne ensuite. A quel point sommes-nous capables de faire des itérations courtes? Comment savoir si une idée est bonne? Comment le mesurer? Il nous sensibilise sur le besoin de faire du prototyping très rapidement. Cela devient ensuite un outil qu’il faut éprouver rapidement dans la vie réelle. Tout cela me fait rapidement penser à la nouvelle société de l’alliance Xebia, Thiga. Thiga propose en effet du conseil en Product management agile. 

S’il y a un crédo à retenir: "Be passionate about the problem, not the solution!". C’est un mot qui reviendra souvent tout au long de la conférence, la PASSION. Le PO doit être capable de constituer une équipe passionnée autour du problème qu’il veut résoudre. Et les équipes ne se construisent pas, elles émergent !

Les slides de la session sont aussi disponibles sur Slideshare.

Prioritising ideas using cost of delay

Özlem Yüce nous propose en ce début de deuxième jour un outil pour aider à prioriser. Il se nomme, le "Cost of Delay". Elle nous propose un guide de survie dans un monde où les demandes fonctionnelles évoluent rapidement et doivent être livrées la veille. Il nous faut donc des outils pour gérer l’urgence.

L’outil proposé est d’associer une notion de prix à une feature. Ce prix dépend :

• de la valeur que l’on compte délivrer au client
• de la probabilité que cette feature trouve son public sur le marché
• de sa date d’arrivée sur le marché

Pour le premier point, on peut s’aider de quatre éléments pour évaluer la "business value". Une feature peut :

• Développer de nouveaux revenus
• Soutenir une source de revenu existant
• Réduire des frais existants
• Consolider des frais existants

On peut tenter d’avoir des informations sur la probabilité qu’une feature fonctionne ou pas, par une étude de marché approfondie par exemple. Mais cela prend du temps et ne reste qu’une estimation.

Le dernier point dépend énormément du marché que l’on attaque. Est-il du type, "premier arrivé, premier servi", peut-on récupérer des parts de marché de ses concurrents…

Avec ces quelques informations et une pincée d’estimations, on obtient une notion de prix pour cette feature. Je peux donc estimer qu’une telle feature pourrait me rapporter 50 000€.

Özlem nous propose ensuite de diviser ce chiffre par la durée de réalisation. On obtient le CD3, Cost of Delay Divided by Duration. Si la durée de mise en place de la feature est de 4 semaines, le C3D est de 12 500€. Cet indicateur peut alors servir pour prioriser les features en comparant leur CD3. Quelle feature représente la plus grande perte si elle est décalée?

Cette présentation a suscité quelques questions en fin de séance. CD3 n’est certes pas parfait. C’est un outil qui, comme bien d’autres, est basé sur des estimations.

REX, Kanban va-t-il fluidifier notre chaîne

Florence Chabanois est Scrum Master pour Explorimmo. Elle nous livre un REX de la vraie vie: "La mise en place de Kanban dans une équipe habituée à Scrum". C’est vraiment de la vraie vie, car la transformation est encore en cours.

Les raisons de l’ajout de Kanban ? Le délai en jours ouvrés entre une idée et sa mise en place est jugée trop long. De plus, la priorisation dans le sprint entre les grands chantiers, les bug fixs de production et les quick-wins sont difficiles. Les chantiers de longues durées sont morcelés par la nécessité de traiter les sujets urgents. 41% des stories vont en production avec des anomalies qui viennent perturber les sprints suivants. De plus, la notion de Sprint est vue comme freinant la fluidité de l’organisation. Ils se donnent un an pour adopter Kanban, et voir le gain. Il se donne comme objectif de réduire le lead-time par 2 !

La transformation au sein de l’équipe est en cours. A l’heure actuelle, du point de vue du PO, les points positifs sont :

• Une priorisation plus souple entre les tickets (chantiers, bug fix, quick win)
• La satisfaction d’avoir des stories qui vont jusqu’au bout, c’est à dire la production
• Un délai de mise en place des features quelques peu réduits. Ce n’est pas encore significatif

Par contre, le PO se rend compte que le Sprint était aussi une protection pour lui, pour gérer la pression des différentes parties prenantes. Impossible d’expliquer que la story ne sortira pas cette semaine à cause du Sprint. C’est donc plus facile pour lui de changer ses priorités, mais cela devient aussi plus fatiguant car il faut le faire en continu.

De la part de l’équipe, ils sont ravis de :

• Avoir un spectre de tâches plus large (comme faire de la recette, traiter la dette, par exemple)
• De répondre au mieux au besoin.

Par contre pour une équipe habituée à Scrum, l’absence "d’engagement" pour le sprint est vécue difficilement. C’est un problème de culture. Ils ont l’impression de passer d’un sujet à un autre, sans trop de fil conducteur.

L’équipe souhaite appliquer pleinement Kanban, avec sa contrainte de Work-In-Progress. C’est l’une des plus grandes difficultés qu’ils ont rencontrées. C’est perturbant pour un développeur de "s’arrêter" volontairement quand un stock a atteint sa limite. Mais cela a permis de favoriser le travail en équipe pour tenter de terminer les tickets déjà démarrés.

Même si les résultats proposés ne sont pas encore tous concluants, je suis ravi par cette présentation. Je suis personnellement habitué à Scrum, et cette mise en place de Kanban a montré des problèmes que je me posais. Merci Explorimmo et bon courage pour la suite.

La culture du programmeur

Un speaker que l’on connait bien chez Xebia, Jean-Laurent De Morlhon. C’est un sujet qui nous est cher aussi. Son message résonne encore entre ces murs. Il préfère dire qu’il est programmeur plutôt que développeur. Comme ça, pas d’ambiguité. Après avoir expliqué les éléments clés qui définissent un craftsman, il nous explique pourquoi c’est intéressant d’avoir un craftsman dans sa société. Le problème, c’est qu’un craftsman est dur à trouver. Alors plutôt que de le chercher, à l’extérieur de votre équipe, pourquoi ne pas en favoriser l’émergence? Ce n’est pas forcément plus simple, mais c’est un choix plus durable. Jean-Laurent distille ensuite quelques conseils plutôt destinés à des managers. Pour avoir des craftsmen, il faut comprendre la culture des programmeurs, sans forcément parler de 42 et des Lego Star Wars.

Un craftsman travaillera avec l’envie de fournir un produit de qualité. Il faut donc valoriser ce comportement et respecter ses choix. Si un programmeur considère qu’un travail de qualité passe par le TDD, du refactoring ou de l’auto-formation, il faut le croire. S’il est investi par sa mission, il prendra ces décisions en connaissance de cause.

Les programmeurs font de la veille technologique. Ils savent ce qu’est un MOOC et en utilisent déjà. Restreindre l’accès à Internet depuis l’entreprise est donc un frein à leurs développements et leur envie d’apprendre. 

Il faut aussi faire confiance au programmeur dans le choix de ses outils. Sans accepter des choses à des prix indécents, de bons outils permettent de mieux travailler. Selon lui, 6 000€ est un bon budget pour avoir un poste de travail (mobilier inclus) vraiment propice au travail. Cela peut sembler beaucoup. Mais ramené à un salaire, cela devient vite dérisoire. 

Conclusion

J’ai beaucoup apprécié Mix-IT, tant pour les participants, les organisateurs et les speakers que j’ai pu rencontrer. Toutes ces personnes ont permis de créer un fil conducteur autour de l’entrepreneuriat, de l’envie de faire des choses ensemble, du DIY, de la diversité au travers des slots, des keynotes. Il y a aussi un détail d’attention avec la Communauté du goût qui nous a proposé une nourriture de qualité et locale. Un grand bravo à tous, c’est une conférence réussie. Vivement l’année prochaine !

J’en repars, motivé, plein d’idées et d’envies, pour tout de suite !