Mes tweets 2010

@lmorisseau

Réflexions sur les stratégies d'amélioration des processus et méthodes agiles

Lors de mon retour d'expérience de Scrum au Kanban, je faisais part de mon constat opérationnel que le Kanban minimise l'impact du changement et réduit la résistance à l'adoption de l'agilité.

Est-ce une bonne chose?
Un changement de paradigme comme l'apporte Scrum permet de bousculer les choses, des prises de conscience plus radicales, plus rapides mais plus perturbantes peut être dans certains contextes. Ce sont tous les freins à l'adoption de l'agilité que l'on rencontre régulièrement. L'accompagnement au changement devrait être plus présent dans ce cas. Dans la réalité, elle se résume à une formation, et plus rarement à du coaching. Bien que je constate avec satisfaction que ces missions de coaching se développent bien.

Avec Scrum et le Kanban, on a deux stratégies d'amélioration différentes:

• L'amélioration par rupture avec Scrum : vs les approches traditionnelles
• L'amélioration continue avec le Kanban : commencer là ou on est par petits incréments d'amélioration, c'est un principe fondamental du Kanban

Ce qui peut être perturbant avec Scrum, c'est que cette amélioration par rupture lors de son adoption est en décalage avec le cadre d'amélioration qu'elle propose : une amélioration au quotidien par tous les mécanismes de feed-back qu'elle met en oeuvre et par son modèle d'Inspection et d'Adaptation, proche du PDCA.

Pour moi, il n'y a pas de jugement autour de l'une ou l'autre de ces stratégies d'amélioration, puisque les deux sont nécessaires pour innover. Mais là encore, une contextualisation importante est à faire.

Le Kanban permet une approche Kaizen facilitant l'adoption de l'agilité et pour imager cela, je prends l'exemple d'un projet que j'accompagne depuis quelques mois avec une équipe d'une vingtaine de personnes. Récemment, j'ai eu plusieurs retours par quelques acteurs du projet que l'on ne faisait pas d'agilité sur le projet. Bonne nouvelle! Car d'abord ce n'est pas une fin en soi, donc j'évite de mettre le mot Agile à toutes les sauces. Mais surtout c'est le signal faible que la stratégie petit pas du Kanban a été payante, car en réalité le degré d'agilité sur le projet est important.

Je vais faire un focus sur les limites du travail en cours, car déjà Guillaume m'en faisait la remarque sur le trajet des XP Days Benelux récemment et d'autre part c'est un élément différenciant du Kanban qui met une limite sur le travail en cours sur les états, là ou Scrum met une limite indirecte via la vélocité.
Je n'ai pas de limite explicite sur le travail en cours sur ce projet, en théorie je ne suis pas dans les standards du Kanban. Mais la limite est implicite et surtout elle a largement évolué pendant le projet: J'ai commencé d'abord par deux tag names par personne. Puis à l'occasion d'un refactoring du tableau de taches, j'en ai profité pour ne laisser physiquement que de la place pour une tache en cours par personne sans autre contrainte. Résultat, les taches dépassaient régulièrement la colonne En cours. Mais au fur et à mesure, cette contrainte a forcé naturellement les personnes à finir les taches ou à binômer.

Dernièrement, à l'occasion du dernier refactoring du tableau pour passer à trois équipes en parallèle, je suis passé à un tag par personne, ce qui n'a pas posé de problème à l'équipe.

Donc en quelques mois sans tambour ni trompette, et surtout sans pression sur l'équipe, nous sommes maintenant et durablement sur une limite implicite de travail en cours à une tache par personne, à une limite physique par équipe et à une limite physique sur le projet; Et une équipe qui se focalise d'elle-même sur les taches à finir avant d'en commencer d'autres.

C'est un exemple simple mais significatif. L'amélioration sur le processus a lui aussi été appréhendé par petits pas et n'est pas encore fini.

Ce qu'il est possible de faire au niveau projet (une rupture avec Scrum) est plus difficile à faire au niveau organisation (amélioration Kaizen du Lean). il y a bien derrière ces deux stratégies, portées par des approches différentes, un enjeu d'adoption de l'agilité aux différents niveaux d'une organisation. C'est l'un des messages que l'on entend bien sur dans la communauté Lean & kanban. La relation entre un projet agile réussi et une adoption agile réussie n'est pas bijective.

Agile Tour Rennes 2010 : Supports et vidéo

Bonne nouvelle, vous pourrez trouver les supports et les vidéos des conférences d'Agile Tour Rennes 2010 sur le site d'Agile Tour Rennes, rubrique Programme.

Un grand merci à:

• tous les orateurs, cela fait un beau cocktail de films et de présentations
• tous les participants d'avoir répondu présent
• l'équipe de Frédéric HANNOUCHE du CIRM  pour avoir réalisé la captation des vidéos

A l'année prochaine!

Feed back XP Days Benelux 2010

De retour des XP Days Benelux aux Pays-Bas cette année, en quelques chiffres logistiques pour moi et Guillaume:
20 h de déplacement pour 1 jour et demi de conférence. Il fallait 4 trains au départ de Rennes pour arriver jusqu'à Heeze.
Sinon 160 personnes en moyenne, 5 tracks en parallèle, très bien organisé avec Vera en fée clochette.

Mon feed-back de cette année renforce celui des XP Days Benelux 2009. Il faut être disponible, reposé pour que la magie opère pour moi. Je n'étais ni l'un ni l'autre le premier jour. J'ai donc zappé le dîner pour aller apprécier la piscine et le sauna de l'hôtel. Le deuxième jour a été meilleur.

Ce qui a bien marché

• Le retour en voiture avec Régis et Emmanuel jusqu'à Bruxelles
• La rétrospective avec Guillaume dans le train retour
• Les petites sessions de yoga collectives pour s'énergiser
• Assez de français pour discuter pendant les pauses
• Revoir ceux que j'apprécie et que je croise à Londres, Belgique, Paris, ...

Ce qui a moins bien marché

• Les sessions trop débutantes ou trop éloignées de notre quotidien opérationnel bien d'intéressantes
• Être dans un autre hôtel que la conférence
• Pas assez d'apprentissage
• Ne pas avoir pu participer aux deux dîners

Ce que j'ai appris

• Meilleure compréhension du Lean grâce à Régis, que j'avais récemment croisé à Agile Tour Nantes sur sa session Problem Driven Development

Les questions que je me pose

• Vais-je y retourner l'année prochaine? Ça dépendra sûrement du lieu de la conférence

Des retours de quelques sessions auxquelles j'ai assisté
Political Economy of Agile projects
La vision de laurens : l'agilité est la démocratisation du développement logiciel et au-delà. Le pouvoir (thème de la session) change ce qui provoque des résistances. La transition à l'agilité doit donc être plus subtile. Je partage cette conclusion surtout au niveau du middle management.
Il pointe du doigt l’intérêt de constituer une matrice sociale de l'organisation dans laquelle on intervient, que l'on veut changer, avec l'intensité des pouvoirs de chacun.

Complexity vs Lean
Nouvelle conférence de Jurgen Appelo que j'avais pu déjà voir au Spa à Londres au sujet de la théorie des systèmes complexes qu'il utilise comme fondement de son approche du management. Il continue donc sur ce sujet en le confrontant au Lean. Sa présentation est assez rhétorique et cherche les réactions.
J'aime bien son approche pour bousculer les choses même s'il se laisse embarquer un peu trop dans sa démarche. Il démontre également certaines mauvaises compréhensions du Lean et du Kanban.

Things never change no matter what we do
Un lien entre cette session et la session sur les diagrammes de causes-effets, déjà vu avec Laurent Bossavit lors de sa session Agilité à monter soi-même. Les outils pour adresser des problèmes de systèmes non linéaires doivent prendre en compte cette non linéarité: Il faut utiliser des outils systémiques comme les diagrammes de causes - effets avec leur boucle de feed back. Les diagrammes d'Ishikawa, les 5 pourquoi ... ne sont-ils pas trop linéaires?  Lors de cette session, j'ai encore pu vérifier qu'on se laisse facilement embarquer par ces outils. Il faut vraiment avoir un facilitateur neutre qui challenge le résultat. Les discussions provoquées lors de ces ateliers sont toujours plus riches que le résultat en lui-même.

Agile Community Building - Using StrategicPlay with Lego

Utilisation des Legos (ici, ici aussi et déjà avec Yves Hanouille,  sinon on trouve aussi des playmobil là) pour modeler une vision partagée de la communauté agile. J'ai bien aimé les différentes étapes pour en arriver à une vision partagée. J'ai regretté qu'une partie des participants ait oublié la vision initiale de la communauté agile pour se focaliser sur une équipe agile.

D'autres feed back des XP Days à lire ici et plein d'autres liens.
Merci à Pascal et Willem pour les dépannages en voiture qui ont grandement simplifié la logistique et merci aux organisateurs pour cette conférence.

Prochaine étape : L'Agile Open France, début 2011!