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.