Dessine moi un KPI agile (#2-Kanban)

Commentaire 1 Par défaut

« Mesurer et gérer le flux ». Derrière cette proposition se cache la troisième des six pratiques de la Méthode Kanban, telle que proposée par David J. Anderson.

capture-decran-2016-12-30-a-16-30-41

Dans ce second article de ma série consacrée à la description des KPI Agile, je vais vous décrire les principaux KPI utilisés en Kanban et vous présenter le fichier que j’ai mis en place pour effectuer ces mesures, plus quelques autres…

Le premier article, était consacré aux principaux KPI mesurés sur un mode Scrum. Vous pouvez le consulter ici.

Lire la suite

Quel outil pour gérer notre projet agile ?

Poster un commentaire Par défaut

« Que nous conseillez-vous comme outil pour gérer notre projet agile ? ». Cette question tous les coachs l’ont un jour entendue, à chaque accompagnement d’une équipe passant aux pratiques agiles. En fait la réponse à cette question est très simple … « ça dépend … ».

En effet, il existe une telle variété d’outils, que le choix varie fortement du contexte et des attentes de l’équipe et de son organisation. En fait, pour faire votre choix, vous devez d’abord définir ce que vous attendez d’un outil agile.

Je vous propose de faire un état des lieux, non exhaustif (il y a tellement d’outils), des outils que j’ai eu l’occasion d’utiliser ou tester.

Lire la suite

Dessine moi un KPI agile (#1-Scrum)

Poster un commentaire Par défaut

L’une des premières questions que l’on me pose (en dehors de quel outil digital doit-on utiliser), lorsque j’interviens dans l’accompagnement d’une nouvelle équipe qui souhaite mettre en oeuvre les pratiques agile, est comment vont se faire les estimations et la mesure de la capacité de l’équipe à tenir ses promesses.

Bien sur, une réponse facile serait de dire « on verra au fur et à mesure de l’avancement » ou alors « les estimations et les KPI ça ne sert à rien, faisons confiance à l’équipe ». Tout cela est bien gentil, mais la réalité est toute autre. Car, que l’on vienne du top management, du middle management ou de la team agile elle-même, ce sont des questions que l’on va se poser systématiquement lorsque l’on évolue dans un environnement loin d’être agile dans son mode de pensée (oui, ça existe encore), ou les budgets et les délais sont contraints, ou la notion de priorisation par la valeur est quelque chose d’abstrait et ou l’on va demander à un manager de donner une plus forte autonomie à l’équipe, sans lui apporter les éléments lui permettant de gérer ses activités de support, de suivi et de reporting (un manager qui n’a pas les bonnes informations ne peut pas jouer son rôle de facilitateur).

Dans cette série, je vous propose de présenter les différents type de KPI que j’utilise depuis quelques temps, auprès des équipes que j’accompagne.

Ce REX est découpé en trois partie. La première (cet article) portera sur les KPI Scrum, la seconde sur le passage de l’équipe vers un mode Kanban, avec la mise en place des KPI associés et la dernière décrira les indicateurs utilisés dans la mesure de la santé de la team agile, via la mesure de la maturité sur les pratiques (Scrum, Kanban), l’utilisation de pratiques du Management 3.0 (Moving Motivator) et du Health Check Maturity.

Lire la suite

A chaque sprint sa rétrospective (REX)

Poster un commentaire Par défaut

La rétrospective est l’un des moments phare d’une démarche agile. C’est à ce moment que l’équipe se réunit et fait le bilan de la période écoulée. L’objectif en est simple, fêter les victoires et les points positifs et chercher ensemble les solutions à apporter sur les éléments empêchant l’équipe de tenir ses promesses et de travailler dans un environnement sain et bienveillant.

En Juillet 2016, j’ai rejoint une équipe projet, constituée pour réaliser un nouvelle application mobile et débutant sur les pratiques agiles. Dès le début, j’ai voulu mettre en avant l’importance de la rétrospective, dans la capacité à s’améliorer régulièrement et à réduite les tensions pouvant exister entre les différents acteurs. L’objectif ? Faire que, sur un projet stratégique (ou les relations entre les partenaires pouvaient parfois être tendues), la team agile devienne une équipe soudée, solidaire et performante.

Pour cela, il a été décidé, avec l’implication précieuse du Scrum Master, de proposer un nouveau format d’animation lors de chaque rétrospective.

Au moment ou j’écris cet article, nous en sommes à la rétrospective 5 et ce REX va vous présenter les différents formats que nous avons mis en oeuvre, avec les bénéfices que nous en avons tirés.

Lire la suite

SAFe from the inside (#2 – PI Planning – Day 1 AM)

Poster un commentaire Par défaut

Le Release Planning est incontestablement l’un des cérémonials le plus important du framework SAFe. Bien que son nom est changé, dans la version 4.0 (Release Planning deviens PI Planning), ses objectifs et son déroulé reste globalement les mêmes.

Je vous propose de vous présenter comment s’est déroulé le Release Planning de l’organisation que j’accompagnais et surtout les difficultés que nous avons rencontrés dans son application. Pour cela, j’ai découpé cette description en 4 articles, décrivant chacun une demi-journée du PI Planning. Cet article représente la première demi-journée.

Pour ne pas créer de confusion avec la dernière version 4.0 de SAFe, j’utiliserais le terme PI Planning, dans le suite de cet article.

Nota : contrairement à ce que j’ai pu lire dans un récent article, PI ne signifie pas Product Increment, mais Program Increment. Cela fait sens, étant donné qu’un programme peut contenir plusieurs produits et que SAFe a justement pour objectif de gérer des programmes à l’échelle.

Vous pouvez lire le premier article de cette série : SAFE from the inside : #1 Big Picture.

Lire la suite

SAFe from the inside (#1 big picture)

Poster un commentaire Par défaut

En 2009, j’ai découvert le monde de l’Agilité et ses valeurs, au sein d’une grande banque Française. A l’époque l’adoption de l’agilité n’en était qu’à ses débuts en France et peu d’entreprises avaient osées sauter le pas. Au fil des années, la communauté agile Française a grandie, les valeurs et apports de l’agilité ont commencés à démontrer leurs bénéfices sur les équipes et les organisations (même s’il reste encore du travail) et les entreprises sont passées de petites expérimentations à la volonté d’adopter l’agilité à grande échelle.

La problématique s’est alors posée sur la façon d’accompagner ce changement de paradigme, à l’échelle d’une entreprise. Jusqu’alors, les transformations agiles concernaient le plus souvent des équipes IT, de petite taille (principe de Scrum), rarement en dépendance entre elles. Ces équipes IT étaient souvent les seules à être passées à l’agilité (90% du temps sur du Scrum) et se retrouvaient déconnectées des autres services/équipes de l’entreprise, qui eux gardaient leur anciennes méthodes de travail.

Les Framework Agile ont alors fait leur apparition, dont Less pour la partie Scrum à l’échelle, suivi de son concurrent Nexus et le plus connu, SAFe (Scaled Agile Framework), qui commence à s’implémenter dans quelques grands groupes en France.

De nombreux articles ont été écrits sur ces Framework et sur SAFe en particulier, bien souvent très mitigés, voir négatifs. Ces derniers temps, je constate néanmoins une certaine atténuation de ces critiques et une analyse plus objective de la mise en place d’un framework agile, comme cette vidéo de Henrik Kniber et  Lars Roost sur l’expérimentation de SAFe chez Lego.

Cette série a pour objectif de partager avec vous ma modeste expérience dans la mise en place et l’utilisation de SAFe, auprès d’un grand groupe, sur une période d’environ une année.

Ce REX est basé sur la version 2.5. Une comparaison sera faite entre cette version et les nouveautés apportées par la V3.0.

Commençons par une description de la Big Picture SAFe.

Lire la suite

Running lean your Agile transformation (partie 1 – Le plan A)

Poster un commentaire Par défaut

Lorsque je me suis lancé dans le coaching agile, j’ai découvert la philosophie Lean Startup au travers du livre et des articles d’Eric Ries, ainsi que la méthode Running Lean promue par Ash Maurya. Le constat a été immédiat : une transformation agile n’est pas la mise en place d’une méthode mais doit être perçue comme un produit à part entière, que l’on souhaites proposer (vendre) à des clients, dans l’objectif de résoudre un ou plusieurs de leur problèmes.

Lire la suite