Nous avons eu la chance de participer à la conférence Lean Kanban France, les 5 et 6 novembre. Cette conférence de 170 participants a présenté un programme de grande qualité, avec des intervenants internationaux et des sujets relativement avancés. Dans ce billet, nous avons regroupé en trois grands thèmes les sessions auxquelles nous avons assistées et qui nous ont le plus marquées :
- L’utilisation de métriques à tous les niveaux : pour construire son produit, innover ou s’améliorer ;
- (Re)mettre le budget au centre des arbitrages ;
- L’excellence agile passe par la technique.
Construire un produit, innover, s’améliorer : oui, mais pas sans métrique
Outcomes over outputs with the Mobius loop
Gabrielle Benefield nous adresse quelques bons messages et un outil actionnable dans beaucoup d’environnements. En guise d’introduction, Gabrielle nous a parlé de métriques et pose trois questions :
- How do we gonna create value?
- Why do we measure things?
- Why do we measure what we measure?
Pour ces questions, elle donne une réponse qu’il faut garder à l’esprit : ce n’est pas la mesure qui importe, mais son sens. La mise en garde est pertinente : l’adoption de l’agilité passe par la mise en place d’indicateurs et il est facile de se limiter aux KPIs les plus classiques (ou les plus faciles à exhiber).
Là où elle souhaite nous amener, c’est qu’une métrique doit servir à être un instrument de l’amélioration continue. Pour s’améliorer, il faut savoir d’où l’on part et ce que l’on peut viser à court ou moyen terme.
Gabrielle lève alors le voile sur son support : la boucle de Mobius. Ce gabarit est une alternative au format A3. La mécanique est assez proche, cela se base sur du PDCA (ou PDSA) et repose, sans surprise, sur des métriques ‘sur-mesures’. La mécanique peut se résumer ainsi :
Recherche du problème -> Recherche d’options -> Mise en place de l’option retenue -> Mesure des effets -> Adaptation
Plutôt que de lancer des activités d’innovation à l’aveugle, en ‘arrosant large’, Gabrielle nous indique un chemin qui doit permettre de répondre aux questions suivantes : Quels sont les problèmes de mes utilisateurs ? Quels sont ceux à traiter en priorité ? Quel retour sur investissement en attendre ? C’est une tranche de lean Start Up qui se concrétise par cette fameuse boucle.
Comme fil conducteur de la présentation de son outil, Gabrielle s’est appuyée sur l’impact de faire se laver les mains au personnel soignant systématiquement avant d’interagir avec un malade. L’objectif est bien entendu de réduire le risque de propagation des maladies nosocomiales. J’ai particulièrement aimé cet exemple : à partir d’une action très simple (se laver les mains), on peut notablement améliorer un objectif VRAIMENT important. Une métaphore à garder en tête pour frapper les esprits et convaincre de l’intérêt de petites actions, autant de petits pas réalisables pour atteindre un plus grand objectif.
Dernier bonus, une punch line : ‘Management does not care about Scrum, Kanban or whatever… Management cares about investments and risks’!
Vous pouvez retrouver le support de Gabrielle sur la mobius loop ici.
Une recette du Maker-Entrepreneur
Nicolas Deverge se présente comme un micro-entrepreneur. Sa session nous démontre, au travers d’un storytelling bien ficelé, l’importance de la mesure dans la construction d’un produit.
Après une présentation du Lean Startup, Nicolas pose le problème (retrouver ses clés quand on les a perdues dans la rue) et enchaîne avec la solution (un porte-clé avec un code pour contacter le propriétaire des clés). Il nous expliquera cette erreur « cartésienne » de chercher une solution avant même de valider les hypothèses relatives au problème.
Chaque boucle d’apprentissage est régulée par une mesure, prise à partir d’une hypothèse, parfois déroutante étant donné son incroyable simplicité. Comme celle de compter le nombre de clés retournées après en avoir semées délibérément (on imagine Nicolas déposant timidement ses clés dans les rues de Toulouse, dans la crainte de se faire interpeller).
Ces mesures vont lui permettre d’apprendre, d’améliorer le produit, de trouver sa cible, de renforcer l’expérience utilisateur, parfois même de pivoter et l’emmènera jusqu’à la fabrication du produit dans un FabLab.
Vous l’aurez compris j’ai été très inspiré par cette session, qui met l’expérimentation du Lean Startup à la portée de tous.
Petit bonus la méthode de Van Westendorp pour déterminer le prix d’un produit.
Le support de Nicolas est disponible ici.
Lean Takeoff : plongez dans un monde incertain !
L’atelier proposé par Alfred Almendra a pour objectif de faire découvrir la posture du Lean Startup par la pratique, un programme alléchant. Notre objectif en tant que startuper est de valider le plus rapidement possible trois hypothèses du Lean Canvas que sont :
- Qui est concerné ?
- Pour quel besoin ?
- Pour quel usage ?
Chaque hypothèse est composée d’une description et d’une justification. Ces deux éléments traversent la boucle d’apprentissage du Lean Startup et sont soit conservés soit remis en cause (les parties Build et Mesure sont simulées au travers d’un lancer de dé).
L’expérience est très étonnante, notre idée d’origine a subi tellement de pivot qu’elle n’a plus aucun rapport avec le résultat. L’atelier nous apprend l’importance de valider chaque hypothèse et qu’une hypothèse peut engendrer un pivot des trois autres.
Je retiens qu’il est difficile de focaliser notre réponse sur une seule cible, un seul besoin et un unique usage.
NoEstimate avec Monte Carlo
Dans sa présentation Dimitar Bakardzhiev nous propose d’aborder le sujet récurrent des estimations sur un projet. Cette information constitue un élément essentiel pour la communication avec le client, lui permettant d’établir un budget prévisionnel. L’approche de Dimitar est de considérer qu’il est impossible de réaliser une estimation d’expert en phase amont d’un projet, la complexité, la variabilité et le manque d’informations précises rendant ce travail long, coûteux, et trop peu précis pour être utilisable. Il propose donc une approche statistique de ce problème.
Pour cela, Dimitar propose de constituer une banque de données issue de projets passés. Cette banque de données est constituée des Takt Time des éléments produits. Le Takt Time est le temps constaté entre deux deliveries.
Un exemple peut permettre de mieux appréhender cette notion : Considérons un projet constitué de 3 user stories. Si au jour 5 l’US1 sort du système, elle a un Takt Time (TT) de 5. 3 jours plus tard 2 User Stories sortent du système la 1ère (US2) est donc sortie 3 jours après la précédente l’US2 a donc un TT de 3, par contre la 2eme (US3) est sortie zéro jour après la précédente (US2), elle a donc un TT de zéro.
Pour être utilisable et pertinente, cette banque de données doit être organisée en fonction du type de projet. Par projet de même type, on entend des projets utilisant les mêmes technologies, ayant la même structure d’équipe, utilisant les mêmes méthodes de travail et un domaine fonctionnel similaire.
Une fois cette banque de données constituée, il convient de l’utiliser correctement. En effet l’utilisation d’une simple moyenne ne prend pas en compte la variabilité des éléments. Pour cela Dimitar utilise la méthode de Monte Carlo pour simuler plusieurs dizaines de milliers de projets en tirant aléatoirement des TT dans la banque de données. Il en déduit alors la durée moyenne du projet. Cet exercice peut encore être affiné en considérant les différentes phases du projet et en calculant des délais pour chacune de ces phases.
Cette approche m’a semblé intéressante en proposant une façon d’évaluer la durée d’un projet à très faible coût. Le seul écueil me semble d’être la constitution d’une banque de données suffisante.
Un lien de la présentation de Dimitar Bakardzhiev est disponible ici.
Mettre le budget au centre des arbitrages
Beyond Budgeting
Bjarte Bogsnes a donné la meilleure keynote de l’évènement, dont un des supports est disponible ici.
Même s’il n’a pas parlé d’un sujet Lean ou Kanban, sa présentation sur le beyond budgeting est tout à fait éligible à une conférence agile. Il n’a pas tant parlé de gestion du budget que de culture d’entreprise et des nécessaires changements à adopter dans les processus et le leadership à l’heure actuelle.
Ce qui m’a particulièrement frappé dans sa présentation, ce sont les principes de leadership que Statoil met fortement en avant :
- Ayez des valeurs : définissez des objectifs et des limites, ne gouvernez pas avec des budgets détaillés et fixes ;
- Instaurez un climat de performance qui repose sur des objectifs relatifs ;
- Soyez transparents ;
- Pour ce qui est de l’organisation, appuyez-vous sur des équipes légères et engagées ;
- Promouvez l’autonomie, pas de micro-management ;
- Tout le monde doit travailler à améliorer les bénéfices pour les clients.
Pour obtenir cela, Statoil s’appuie notamment sur un canvas, ‘Ambition to action’. De gauche à droite, il comprend 3 zones principales :
- Les objectifs stratégiques à atteindre ;
- Les KPIs pour mesurer l’avancée dans l’atteinte de ces objectifs ;
- Les 5 prochaines actions à mener pour chacun des 5 thèmes chers à Statoil.
Comme vous le pressentez peut-être, le culte de la mesure est là aussi très présent.
Cost of Delay
Donald Reinertsen nous a gratifié d’une longue session sur le cost of delay, le coût du retard en bon français. Il pose le problème suivant : nous ne mettons pas suffisamment les données budgétaires au centre des décisions. Cela lui semble d’autant plus étonnant qu’elles ne nécessitent qu’un niveau minimal en mathématiques. Il faut créer un ‘economics framework’ qui va permettre d’améliorer la qualité des décisions que nous pouvons être amenés à prendre au niveau :
- des projets ;
- du portefeuille de projets ;
- de l’entreprise ;
- de la conception de processus.
Sans cela, les décisions sont lentes, incorrectes, opaques et ne convainquent pas.
Le premier réflexe face à ce genre de démarche est d’opposer une probable difficulté à obtenir les informations de coût de la part de ceux qui les détiennent. Donald pense que c’est un faux problème : il ‘suffit’ d’obtenir la confiance du service financier et/ou du management, et une bonne approximation. Dans tous les cas, c’est un premier pas tout à fait suffisant.
Et bien entendu, on ne prend pas en compte le CoD pour prioriser au niveau des User Stories mais plus sur des features.
Si vous désirez creuser le sujet, Donald partage beaucoup de supports sur son site, http://reinertsenassociates.com.
L’excellence agile passe par la technique
Le retour d’expérience de lesfurets.com
Impressionnant… c’est le mot qui s’est le plus partagé entre coachs à la suite de cette présentation sur l’aventure DevOps/Déploiement Continu du site lesfurets.com. Ce retour d’expérience montre qu’on peut partir de très loin, et aller très loin dans ce domaine. Le chiffre qui symbolise le mieux le chemin parcouru est certainement celui d’un passage d’une mise en production tous les 6 mois à une mise en production tous les jours… Mais d’autres font également rêver : phase de test passant de 4-6 jours à … 0 (la confiance est telle et le coût des anomalies de prod si petit qu’il n’y a plus de phase de test à proprement parler) ; commit to prod passant de 5-20 jours à temps de codage+1 jour.
Lesfurets.com est passé en 18 mois d’une organisation solide de type "éditeur logiciel" avec une release par mois à une organisation non moins solide en "Continuous Delivery". Comment ?
- Automatiser à l’extrême ;
- Obtenir du feedback quasi-live sur les problèmes et les bugs ;
- Aller tellement vite dans les merge de branch qu’on évite les conflits.
Chaque partie du produit et de son cycle de vie y est allé de sa transformation en commençant par la fin. C’est le bienfait de l’approche "Stop starting : start finishing!".
Ainsi, l’équipe est partie de la fin. D’abord la production, en mettant en place un monitoring et un alerting technique mais surtout fonctionnel complets. Ensuite un delivery zéro downtime avec le blue/green deployement. Puis la validation rendue hyper visible avec l’outil de régression visuel Zeno et du Selenium qui ici reprend des lettres de noblesse, boosté à l’exécution parallélisée. Enfin, le continuous integration et le continuous merge sur base de feature branching combiné avec Git Octopus Merge (éviter le conflit en mergeant tout le temps au lieu de résoudre le conflit). analysis and coding.
Bref, le process c’est bien, mais le technique permet au process agile d’exister. Ce message est important à porter, car sans cela un plafond de verre ne peut être enfoncé pour aller vers une organisation agile extrêmement efficace.
En conclusion
‘Petite’ conférence en affluence et en apparence, LKF a proposé un contenu de très bonne facture. Cette taille a permis d’être exigeant sur le niveau des interventions, de ne pas proposer trop de sessions en parallèle et c’est bien moins frustrant. Il y en avait pour tous les goûts : des keynotes, des retours d’expérience et des ateliers. Cerise sur le gâteau, les organisateurs sont parvenus à inviter des intervenants de haut niveau. Bravo d’avoir mis la barre aussi haute, la conférence est un modèle du genre !