Quel outil pour gérer notre projet agile ?

Commentaires 2 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 (#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

Vivre, Mourir, Recommencer (ou l’importance de l’Amélioration continue dans l’agilité)

Poster un commentaire Par défaut

2014-07-10-EdgeofTomorrowMovie2014

« Je vais vous raconter une histoire. D’abord, elle vous paraitra ridicule, mais plus je parlerais, plus elle paraitra logique … ». Ces paroles sont celles du commandant Cage (Tom Cruise) dans la bande annonce du film « Edge of Tomorrow », sortie le 4 juin 2014 au cinéma.

L’histoire est assez simple (enfin, pour un fan de science-fiction) et décrite comme suit par le synopsis de Wikipédia :

« Dans un futur proche, des hordes d’extraterrestres extrêmement organisés, les « mimics » ont envahi la Terre. Alors que l’humanité lutte de toutes ses forces, le commandant Cage (Tom Cruise) est tué lors d’une bataille mais, pris dans un paradoxe temporel, il se réveille un jour avant la bataille. Ce cycle se reproduira sans cesse et chaque fois qu’il mourra, il ressuscitera et entrainé par un super soldat, le sergent Rita Vratasky (Emily Blunt) deviendra de plus en plus expérimenté. »

Lorsque je lis ce synopsis, je ne peut m’empêcher de faire le rapprochement avec une des pratiques essentielles de l’agilité, trop souvent négligée au fil du temps … l’Amélioration Continue.

Lire la suite

Kanban pour l’IT : Concevoir – Identifier votre flux d’activité

Poster un commentaire Par défaut

La démarche Kanban, inspirée du modèle PDSA (Plan-Do,Study-Act) de Walter A. Shewhart, s’inscrit dans une approche empirique d’amélioration continue.  La démarche s’articule donc autour de 4 phases :

  • Phase 1 : Concevoir (Plan) ;
  • Phase 2 : Mettre en oeuvre (do) ;
  • Phase 3 : Etudier (Study) ;
  • Phase 4 : Améliorer (Act).

Cet article porte sur la phase de conception (Phase 1 : Concevoir) d’un Système Kanban et plus particulièrement sur la définition de la nature des éléments de travail.

Capture d’écran 2014-05-19 à 15.15.24

Cet article fait partie d’une série, portant sur les différentes étapes de mise en oeuvre d’un système kanban IT, inspiré de mon expérience personnelle et de la seconde édition du livre « Kanban pour l’IT » de Laurent Morisseau.

Précédents articles :  Kanban pour l’IT : Concevoir – Quels types de cartes pour mon kanban ?

Lire la suite