Le blog a déménagé sur morisseauconsulting.com

Pour continuer à suivre ce blog sur les méthodes Agiles, Lean et Kanban, je vous donne rendez-vous à cette nouvelle adresse morisseauconsulting.com.

MyProjectStuff ~ prochains épisodes

Changement de blog, les prochains épisodes du roman fil rouge du livre Kanban pour l'IT sont publiés ici.

Kanban Digest #14

Lu sur Twitter

Très heureux que mes coéquipiers adoptent #Kanban de manière positive comme un outil d'amélioration continue. via @nintinbadole

#Kanban est un outil puissant pour gérer les flux. via @m0n4k0

Kanban est-il meilleur? Les difficultés en #Scrum restent des difficultés en #Kanban. Ça  ne résout pas magiquement les dysfonctionnements organisationnels systémiques. via @sdunnrocket9 

Vu sur le web
La vidéo de l'USI pour:

Repenser l'organisation devient une nécessité : mise en place de feature teams et de communautés de pratiques. Diffuser la culture du flux continu est une priorité, par exemple Kanban.

Hervé Lourdin, d'Octo, propose quatre points de rupture pour le déploiement de l'agile à large échelle:

1. Étendre le workflow et avoir une approche orientée flux.
2. Avoir d'autres indicateurs partagés par les différentes équipes en passant au Lead Time.
3. Garder des cycles courts mais planifier au fil de l'eau et désynchroniser les rituels.
4. Avoir une organisation en feature team et des communautés de pratiques.

Cela confirme ce que j'ai expérimenté. Ce point de vue bouscule l'idée reçue que le Kanban se cantonne à une activité de support ou de TMA mais a un intérêt sur les grands projets.


Les livres
D'autres livres, en anglais, sont actuellement en écriture sur le Kanban ici ou là.
Bonne nouvelle! Après les pionniers du Kanban ayant écrits sur les concepts, une vague de livres arrive axés sur la mise en action du Kanban. Preuve de l’intérêt et de la maturité grandissante du Kanban. 

MyProjectStuff ~ épisode 3

Troisième épisode du roman fil rouge du livre Kanban pour l'IT:

• Episode 1
• Episode 2

\

Sophie réfléchit au système kanban qu’elle doit concevoir.

Eléments de travail de l’Aldébaran 

Son équipe implémente principalement des stories et un lot d’anomalies corrigées. Stories et anomalies constituent le flux de travail d’Aldébaran.

L’équipe propose des stories techniques même si elles ne sont pas encore sélectionnées par le Product Owner. A l’équipe de bien vendre ces stories pour les faire rentrer dans le sprint backlog.

Sophie continue l’analyse des données. En moyenne, l’équipe arrive à produire une quinzaine de stories par sprint de deux semaines. Cela représente une cinquantaine de stories par version avec les reports d’anomalies et les tâches récurrentes de mise en production.

En regardant de plus près les chiffres, l’équipe traite en moyenne par sprint et par catégorie de taille :

• 1 story XL
• 3 stories L
•  9 stories M
• 2 stories S

Le temps moyen pour réaliser une story est de 2,5 jours, dont deux jours de développement, avec une dispersion de 0,25 à 5 jours.

Sophie opte pour 4 types de stories S, M, L, XL basées sur la taille et un type de story technique. Elle occulte délibérément le traitement des urgences dans un premier temps.

Les stories sont sélectionnées en suivant la priorisation du Product Owner. L’engagement de l’équipe est de réaliser toutes les stories identifiées lors du sprint planning meeting.

L’idée de Sophie est de passer plus tard à un engagement plus fin, celui de la story. Descendre à ce niveau permettrait plus de souplesse vis-à-vis de l’équipe Véga. Elle n’en est pas complètement sûre, elle a peur que l’engagement de l’équipe soit moins fort qu’aujourd’hui. L’équipe Véga n’est d’ailleurs pas non plus prête à travailler comme cela.

Eléments de travail de l'équipe Véga 

Sophie aimerait avoir une vision globale des types de travail. Pour cela, elle aimerait faire cette analyse avec l’équipe de maintenance mais elle hésite. Charles souhaite ne pas perturber son équipe. C’est un interne bien ancré dans la société. Sophie est externe. Elle a été missionnée au démarrage du projet MyAgileStuff pour mettre en place Scrum. Elle a peu d’arguments pour motiver Charles et aucun retour d’expérience pour appuyer son discours sur le Kanban. Pourtant, ils vont devoir mieux travailler ensemble, d’une manière ou d’une autre, pour atteindre les objectifs d’entreprise.

De son côté Charles ne croit pas à l’agilité pour son projet. Sans y être opposé en général, il pense que cela ne marche pas bien dans son contexte mixte de maintenance, support et développement. Difficile pour lui de planifier avec une visibilité suffisante sur deux semaines. Impossible donc pour son équipe de s’engager sur un sprint.

Elle déclenche tout de même une réunion de travail avec lui.

Charles lui explique que leur activité de support est prise à tour de rôle par un membre de l’équipe. Elle consiste à répondre aux appels et aux mails des clients et de faire du support niveau 1, 2 s’il le peut. Le support niveau 3 est généralement pris par Etienne, l’expert technique, très bon mais rarement disponible.

Le marketing définit le périmètre d’une version en s’appuyant sur le chiffrage des évolutions. Cette activité est réalisée les deux semaines qui suivent la mise en production de la version en parallèle du premier patch à livrer.

L’équipe souhaiterait pouvoir réaliser des chantiers techniques pour désendetter le produit mais le marketing n’en voit pas l’intérêt :

-          « Difficile de construire un argumentaire commercial sur les " problèmes de plomberie " des développeurs » a l’habitude de répondre Marc.

Sophie fait la synthèse du contenu d’une version :

·        60% d’évolutifs, soit une vingtaine d’évolutions, dont

• 20% sont complexes
• 60% sont moyennes
• 20% sont simples

·         40% d’anomalies, soit une soixantaine de corrections, dont

• 40% d’anomalies majeures
• 60% d’anomalies mineures

On a donc deux types d’éléments, évolutif et correctif, chacun découpé plus finement, l’un par la complexité et l’autre par la gravité. L’engagement porte sur le périmètre fonctionnel de la version. Il porte également sur la qualité avec aucune anomalie bloquante avant de démarrer la nouvelle version, moins de 10 anomalies majeures et moins de 20 anomalies mineures. Cependant, l’équipe a de plus en plus de mal à tenir cet engagement depuis l’arrivée de MyAgileStuff.

Le flux de demandes est relativement continu toute l’année, avec un léger temps mort pendant les vacances d’été. Rien de très marqué.

Charles et Sophie passent ensuite au processus de réalisation de l’équipe Véga.

Flux et éléments de travail de l'équipe Véga  

Comment définir l’élément de travail pour cette équipe? Est-ce les demandes, les spécifications, le code ou les tests ?

Sophie sent bien que ça va poser un problème pour passer à un système en flux. Éventuellement, ça peut suffire pour commencer à limiter le travail en-cours.

Pourquoi n’a-t-elle pas eu ces difficultés avec son équipe ? Leur support est la story. Bien que ces stories aient une signification différente pour chacun des intervenants, c’est un support qui parle à tous. Pour un développeur, une story se traduit en code, pour le Product Owner elle se traduit par des critères d’acceptation et par son usage pour les utilisateurs.

La story, un bon candidat pour un flux de travail agile

Charles montre quelques signes d’impatience pendant que Sophie avance dans ses réflexions.

Elle se rappelle maintenant les difficultés qu’elle a eu à introduire les stories sur un de ses premiers projets Scrum avec des équipes travaillant à partir de spécifications. Ils avaient finalement utilisé les cas d’utilisation avec succès.

C’est peut-être un bon point de départ pour avancer avec Charles, pense Sophie.

-          « C’est déjà ce que nous faisons pour les évolutions complexes. » concède Charles. « On peut essayer de généraliser pour les autres évolutions mais ça ne doit pas prendre plus de temps à l’équipe ! »

Sophie commence à construire sa vision des éléments :

Analyse de la demande de MyWaterFallStuff 

\

Au prochain épisode, Sophie analyse les éléments du backlog avec Pauline, le Product Owner.

Kanban Digest #13

Lu sur twitter
"Je ne crois pas en ScrumBan. Utiliser Kanban avec Scrum ne conduit pas à du Non-Scrum ou du ScrumBut. C'est juste #Scrum avec #Kanban." via @kanbanery

Lu sur le web
Lean-Kanban University annonce le premier programme de formateurs accrédités kanban basé sur l'expérience du formateur et le support revu par le board. Les formations ne sont pas certifiantes. Les réflexions n'en sont qu'à leur début.
J'ai été contacté par LKU pour être formateur accrédité Kanban. Malheureusement le ticket d'entrée pour être membre de LKU n'est pas réaliste...

Kanban et lean Startup
"Le Build-measure-learn du lean Startup est un système kanban optimisé pour les temps de réponse" via agilejournal; . L'objectif est de réduire le temps de parcours de cette boucle de feedback pour découvrir le prochain pivot le plus vite possible.

Lu sur le groupe KanbanDev
Utilisation du Kanban en dehors de l'IT :  média, marketing et design, ventes, finances, production de livres, affaires juridiques et d'autres encore.

Conférences
La prochaine conférence Lean Kanban a lieu à Madrid les 9/10 Mai. L'inscription early bird est valable jusqu'à ce week-end. Je serais présent à cette conférence.
Alexis Nicolas y présentera une session sur le management, à suivre sur @alexis8nicolas.

Mardi avait lieu le Scrum Day 2012. A cette occasion, nous avons réalisé avec @guillaumelours et @dbaeli un atelier getkanban avec 24 participants. Le prochain atelier aura lieu à Agile France si la session est retenue.
A propos de ce jeu, Hakan Forss propose de modifier certaines règles. Je pense tester ces modifications à ma prochaine session. Si certains essayent avant, je suis preneur de vos feedbacks.

Participez à une enquête pour un outil kanban, première étape, quelles sont les problèmes à résoudre?

MyProjectStuff ~ épisode 2

Rétrospective Aldébaran sprint 1 – Version mineure 3.1

Sophie, la ScrumMaster de l’équipe, annonce le thème de la rétrospective : Réfléchir aux problèmes d’adhérences techniques et de dépendances fonctionnelles avec l’équipe Véga.

Les idées d’amélioration ne manquent pas mais les obstacles principaux semblent se situer hors de l’équipe projet. Il semblerait que les problèmes proviennent surtout de l’équipe Véga. Aucune solution n’émerge cette fois-ci.

La première partie de la rétrospective a fait remonter le manque de disponibilité du Product Owner et le flou qui accompagne beaucoup de nouvelles stories. Visiblement, Pauline n’a plus la capacité d’alimenter correctement l’équipe, avec pour conséquences de la ralentir et diminuer sa vélocité.

Pauline n’étant pas présente à la rétrospective, impossible de prendre une contre mesure efficace, si ce n’est d’envoyer Sophie mener son enquête.

De son côté, la réflexion de Charles tourne autour de la dette technique. Son équipe tourne bien, et si l’on veut réduire le cycle de réalisation, il faut revoir la gestion des contextes. Une première idée est de migrer sur un framework qui devrait éliminer une partie des anomalies techniques et du code de « plomberie ». Il l’a déjà évoqué à plusieurs reprises avec le métier, mais rien à faire, les évolutions fonctionnelles restent prioritaires.

Charles et Sophie partagent leurs maigres conclusions et leurs inquiétudes. Elle retourne chez elle en refusant ce statut quo et pense que l’on doit pouvoir mieux travailler, mais comment ?

Comment relancer la dynamique d’amélioration qui marchait bien les premiers mois ? Comment répondre aux attentes du marketing ?

Heureusement, c’est l’heure des retrouvailles avec la communauté Agile pour la grand’messe de l’agilité Parisienne. Une grande bouffée d’oxygène, Sophie y va pour y retrouver de l’énergie et de l’inspiration auprès de ses collègues agilistes.

Elle assiste à une session sur la méthode Kanban. Cela semble répondre à quelques-unes de ses préoccupations du moment : relancer l’amélioration continue, aller vers plus de planification juste à temps, mieux répondre aux urgences et travailler avec d’autres équipes.

De retour sur le plateau projet, après deux jours riches mais épuisants, elle se renseigne plus précisément sur cette méthode. Cela ne semble pas trop s’éloigner de son implémentation de Scrum, c’est parfait pour commencer.

Rétrospective Aldébaran sprint 2 – Version mineure 3.1

Sophie propose à son équipe d’expérimenter Kanban sur le sprint 4. Reste maintenant à concevoir le système de l’équipe.

A suivre...
Episode 1

Roman MyProjectStuff ~ épisode 1

Mon livre Kanban pour l'IT va être publié en Juillet. 

En attendant sa sortie, je vous propose de suivre la mise en place de l'approche Kanban dans une organisation fictive, travaillant sur des projets et avec des personnages imaginaires au cours d'une vingtaine d'épisodes.

Ce roman est un fil rouge du livre permettant une mise en pratique de la démarche et des concepts Kanban. Il propose des cas concrets que vous pourriez rencontrer sur vos projets. Ce roman ne fait référence à aucun retour d’expérience précis.

Il illustre également la conduite de changement qui accompagne la mise en place d’un système kanban. Enfin, il donne un repère temporel pour l’adoption du Kanban par les équipes. Commençons dans ce premier post par poser la trame de cette histoire.

MyProjectStuff est un éditeur de logiciel proposant depuis cinq ans un portail web permettant la gestion de projet en ligne. MyWaterFallStuff, son produit phare, propose une approche en cycle en V. L’équipe Véga l’a développé, le maintient et en fait le support.
Depuis quelques temps, le marketing voit en l’agilité un fort relais de croissance pour le portail. Il suggère une nouvelle gamme de fonctionnalités autour de la gestion de projet agile. L’intérêt pour celle-ci se confirme de jour en jour.
Les décideurs soutiennent ce projet, MyAgileStuff, plein de promesses. Ce serait un avantage concurrentiel indéniable et doit être sorti rapidement.
Mais à une condition, c’est de ne pas perturber le travail de l’équipe Véga. Le portail marche bien alors il y a de la pression pour maintenir la réactivité de l’équipe.
Des raccourcis ont été pris à l’époque sur la conception et la qualité pour tenir les jalons. L’équipe paie maintenant une dette technique qui se matérialise par un suivi d’anomalies bien fourni, des évolutions difficiles et des patchs hors version. 

Il a été décidé de constituer une nouvelle équipe, Aldébaran, pour ce projet, en mode Scrum, avec cinq développeurs agiles et un ScrumMaster. Son objectif est de livrer en production tous les deux mois, là où l’équipe Véga livre trois fois par an. Pour sortir une version stabilisée de bonne qualité, l’équipe Véga doit passer par une phase de recette de 3 semaines et une préparation de mise en production d’une semaine par l’équipe d’exploitation.
Les deux premières versions de MyAgileStuff ont été une réussite. Le marketing souhaite pouvoir utiliser l’interface visuelle de MyAgileStuff (tableau de tâches, glisser/déplacer de tâches, ...) à des projets de MyWaterFallStuff pour la prochaine version 3.0.
Pour l’équipe d’Aldébaran, cela implique de découpler le rendu visuel du processus de gestion de projet. Il faut pouvoir modifier le tableau Scrum avec d’autres colonnes de conception, développement, test, ... 

Après une première intégration difficile des deux projets, le logiciel arrive en production avec son lot d’anomalies résiduelles.

Timeline de MyProjectStuff

L’équipe Véga corrige les anomalies les plus bloquantes et livre rapidement un patch. L’équipe Aldébaran doit intégrer ces évolutions dans les sprints qui suivent. Cela va perturber les sprints de l’équipe.
Il est décidé d’ajouter une phase d’intégration de deux semaines, rendue indispensable par l’adhérence entre les projets, pour assurer la bonne intégrité du portail lors d’évolutions structurantes. Voici l’équipe agile partie sur un rythme alternant une version mineure, découplée de MyWaterFallStuff, et une version majeure intégrant le portail. 

Quant à elle, l’équipe Véga n’est plus motivée. Les deux produits rendent plus difficiles le suivi de production, la maintenance et le support. Il y a beaucoup de feux à éteindre. Leur statut en a pris un coup également. Autrefois acteurs de la réussite de l’entreprise par le développement du produit phare, ils sont maintenant cantonnés à la maintenance des projets de l’entreprise. 

Les décideurs demandent à Pauline, le Product Owner, de réduire les temps de cycles de production pour pouvoir répondre au besoin du marketing. L’idéal serait d’avoir une livraison mensuelle pour épauler leur modèle économique de souscription.
-          « Impossible... » répond Charles, le chef de projet de MyWaterFallStuff. « Difficile de faire mieux en l’état. Bien sûr on pourrait ajouter une nouvelle équipe pour alterner les livraisons. Mais on va recréer de nouveaux problèmes de dépendances comme c’est le cas avec Aldébaran. Ce n’est pas une solution. »
Refus catégorique du chef de projet qui envisage déjà l’effort d’intégration supplémentaire que cela va représenter.
Il est demandé à chacun d’essayer de répondre à ce challenge.

A suivre...

Quelques nouvelles Kanban

Livre Kanban pour l'IT
Peu de messages depuis quelques mois sur le blog. L'écriture du livre Kanban pour l'IT m'a pris toute mon énergie d'écriture. Mais bonne nouvelle, le manuscrit est dans les mains de l'éditeur Dunod depuis quelques semaines. Le manuscrit sera finalisé vers mi-mars. Le livre est préfacé par David Anderson, himself!

Sommaire du livre Kanban pour l'IT  

Les prochains évènements
A paris
Rendez-vous d'abord au Scrum Day, le 27 Mars à Paris, pour un Kanban Game:

Vous voulez découvrir le Kanban par la pratique?
Vous voulez savoir combien de dollars vous allez gagner avec votre nouvelle start-up en 21 jours? Et si vous ferez-vous les bons choix d'injection, de sélection ou d'allocation pour établir le nouveau record?
Alors venez relever le challenge atelier Kanban avec quatre plateaux GetKanban et trois coachs (Laurent Morisseau, Dimitri Baeli et Guillaume Lours) pour vous accompagner!
Vous y découvrirez comment fonctionne un système kanban avec ses limites kanban, les classes de service et les cartes de contrôles avec cet atelier ludique.

Vous ne pouvez pas venir ce jour là, alors vous pourrez assister à une séance de rattrapage, toujours à Paris. Ce sera à l'occasion de la conférence Agile les 24 et 25 mai, à voir ici.

A Rennes
Les forums Grafotech Agile reprennent. Et pour commencer la saison, rien de mieux qu'un open space. Alors venez nombreux le 5 avril, c'est à l'ESC de Rennes.