Il était une fois un projet IT en Kanban (Episode 3) : Tenez vos promesses avec la prédictibilité

Poster un commentaire Par défaut

« C’est bien votre Kanban, mais comment je fais pour planifier mon projet ? ». Cette phrase revient souvent dans la bouche des Managers, sur les projets que j’accompagne vers une transformation Agile en Kanban.

Les DSI, après avoir rêvées devant les bénéfices de l’Agilité, ont maintenant besoins de résultats tangibles et pérennes auxquels les Burndown Chart et Vélocité ne peuvent répondre seuls.

Cela me rappelle l’époque des débuts de l’informatique en France où les « bidouilleurs » étaient les Rois, ensuite le besoin de professionnalisation a amené la mise en place de normes et pratiques de gestion de projets qui ont produit des effets positifs, dans un premier temps, avant d’être écrasées par la lourdeur des processus.

Aujourd’hui c’est au tour de l’Agilité d’évoluer et d’apporter aux Managers et aux équipes Agiles les éléments de visibilité nécessaires au suivi de la performance et au pilotage des projets.

Ce troisième épisode porte sur l’apport des indicateurs mesurés dans la capacité d’un système kanban à être prédictible.

Lire la suite

Mesurer la Prédictibilité en Kanban – Part II : Le Débit des Cartes

Poster un commentaire Par défaut

La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations.

Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système Kanban à produire des métriques permettant une visibilité forte sur la capacité des équipes projet à tenir leurs promesses.

Une des métriques les plus intéressantes reste sans conteste la prédictibilité, dont vous pouvez retrouver un retour d’expérience dans l’excellent article de Yannick Quenec’hdu « La Prédictibilité au pays de kanban ».

La prédictibilité est mesurable via deux métriques, le Cycle Time et le Débit des Cartes.

La première partie de cet article « Mesurer la Prédictibilité en Kanban – Part I : Le cycle time », a décrit le processus de calcul de la prédictibilité via le cycle time des cartes (Stories, Anomalies).

Dans cette suite, je vous propose une autre façon de mesurer votre prédictibilité, au travers du débit des cartes kanban.

Lire la suite

Mesurer la Prédictibilité en Kanban – Part I : Le Cycle Time

Poster un commentaire Par défaut

La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations.

Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système kanban à produire des métriques permettant une visibilité forte sur la capacité des équipes projet à tenir leurs promesses.

Une des métriques les plus intéressantes reste sans conteste la prédictibilité, dont vous pouvez retrouver un retour d’expérience dans l’excellent article de Yannick Quenec’hdu « La Prédictibilité au pays de kanban« .

La prédictibilité est mesurable via deux métriques, le Cycle Time et le Débit des Cartes.

Dans cette première partie, je vous propose une description du calcul de la prédictibilité de votre projet, au travers du Cycle Time.

Lire la suite

Il était une fois un projet IT en Kanban (Episode 2 – Part II) : Mesurer la performance du système avec les KPI

Poster un commentaire Par défaut

Dans le premier épisode de la série « Il était une fois un projet IT en Kanban« , je vous ai présenté la mise en place d’un Management Visuel Kanban, depuis la phase de Story Mapping « Il était un fois un projet IT en Kanban (Episode 1 : Du Story Mapping au Kanban)« .

La première partie du second épisode m’a permis de décrire les indicateurs graphiques utilisés dans le suivi quotidien de notre système kanban « Il était un fois un projet IT en Kanban (Episode 2 – Part I : Indicateurs Graphiques)« .

La seconde partie de ce second épisode a pour objectif de vous présenter l’ensemble des mesures (KPI) que nous avons mis en place sur notre projet, dans la mesure de la performance de notre système et dans l’aide à la prise de décisions.

Lire la suite

Il était une fois un projet IT en Kanban (Episode 2 – Part I) : Indicateurs Graphiques

Poster un commentaire Par défaut

« [..] éliminer le Muri, réduire le Mura et encourager une approche évolutive du changement« . Voilà comment David Anderson a décrit son intention initiale lorsqu’il a transposé le modèle Kanban vers l’IT (Lean and Kanban Benelux 2011). L’objectif d’un système kanban est donc d’éliminer le gaspillage (Muri) et de réduire les irrégularités du système (Mura).

L’atteinte de ces objectifs passe par un suivi au quotidien du système kanban, afin d’identifier les blocages et goulets d’étranglement et améliorer le système sur le long terme. Le suivi du système se base sur différents indicateurs :

  • Indicateurs Graphiques ;
  • Indicateurs de performance du système ;
  • Prédictibilité.

J’interviens actuellement dans l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basée sur Kanban, depuis 4 mois environ.

Dans le premier épisode de la série « Il était une fois un projet IT en Kanban« , je vous ai présenté la mise en place d’un Management Visuel Kanban, depuis la phase de Story Mapping « Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban« .

Cet article est découpé en deux parties, dont la première porte sur la description des Indicateurs Graphiques utilisés dans le suivi quotidien de notre système kanban et la manière dont ceux-ci nous ont permis d’améliorer la performance des différents intervenants, qui sont les Product Owner, la Qualification et l’équipe de développement.

L’objectif est de vous présenter de façon synthétique les graphiques utilisés sur mon projet. L’explication détaillée fera l’objet de billets dans la série « Le Cockpit Kanban ».

Lire la suite

Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban

Poster un commentaire Par défaut

Il était une fois, un Consultant Agile Xebia à qui l’on avait donné pour mission d’accompagner la transformation Agile de l’ensemble des acteurs d’un projet IT, du Product Owner à l’équipe de Recette, en passant par l’équipe de développement.

Tout lien avec des personnes ou projets ayant existé n’est absolument pas fortuit, car cette histoire est celle que je vis actuellement au sein d’un grand groupe, dans le cadre d’une transformation Agile à grande échelle.

Je vous propose de partager avec vous cette aventure, au travers d’une série de billets décrivant toutes les étapes de la mise en œuvre d’un projet IT, associant le cadre Scrum aux pratiques Kanban.

Au début de chaque billet, je rappellerai le contexte du projet, ainsi qu’un rapide résumé des épisodes précédents :

  • Le projet : Evolution d’une application IT existante, ayant pour objectif l’intégration d’une nouvelle gamme de produit
  • L’équipe Agile :
    • Un Product Owner et un Proxy Product Owner basés en région Parisienne
    • Une équipe de développement, dont un ScrumMaster basé en Province
    • Une personne en charge des tests et de la Recette, basée en Province
    • Une ergonome basée en Province.
  • Le Plan de Release : 5 Itérations de 3 semaines chacune
  • Méthodes Agiles mises en oeuvre : Cadre Scrum (rôles, cérémonials) associé aux pratiques de gestion de flux et d’amélioration continue Kanban.

Lire la suite