Le calendrier visuel, un outil de suivi très agile

Ce billet est l'œuvre d'un blogueur invité, Bruno Sbille.

Calendrier visuel 1

Bruno écrit régulièrement sur Scrum, les méthodes agiles et le management de projets ; il publie sur son blog Scrum and Agile in Belgium, en français et en anglais.


Lors de la dernière release de notre projet j’ai eu à travailler avec une équipe de 7 personnes. Or parmi les membres de l’équipe, personne n’était staffé à 100 % sur le projet.
Pour vous décrire la situation, nous avions:

  • Deux personnes à 80% sur le projet
  • Deux personnes à mi-temps
  • Un expert qui devait prester 15 jours sur le projet, sur une durée de 3 mois
  • Une personne à 20% sur le projet
  • Une personne qui devait intervenir 5 jours sur le projet, mais quand cette personne était présente…toute l’équipe devait être présente.

Cette situation aurait pu tourner au cauchemar… comment être sûr que chacun ait le bon niveau d’information ? Comment communiquer ? Comment fixer une réunion ? Comment lorsqu’un développeur « preste » sur le projet, être sûr que « la webdesigneuse » soit là etc…

Bon j’avais d’abord pensé vous dire que j’avais inventé un nouvel outil élaboré avec un algorithme de calcul très avancé, des technologies de pointes de planning et un module de gestion des disponibilités. Mais rassurez-vous, il n’en est rien les amis. La vérité est bien plus simple !

Rendez-le tout V-I-S-U-E-L

En fait ces « problématiques » ont été réglées assez rapidement car nous utilisions un «calendrier visuel» : un outil de suivi et de communication extrêmement simple à mettre en place, et néanmoins très puissant.

Le calendrier visuel consiste en une grande feuille de papier (type paperboard) sur laquelle on réalise un calendrier de la durée du sprint et sur lequel on colle des post-it. Voici comment procéder:

De quoi avez-vous besoin pour créer le "calendrier visuel" ?

  1. Lors du sprint planning, nous réalisons le calendrier visuel sur le mois courant. Une bonne pratique est de le faire correspondre à la durée de votre sprint. Exemple: imaginons que votre sprint n°2 se déroule du 19 octobre au 13 novembre. Vous savez aussi que la planification du sprint n°3 se fera le 15 novembre. Vous réalisez donc votre calendrier du 19 octobre au 15 novembre.
  2. Sur le calendrier vous identifiez les jours fériés, ou les jours éventuels de fermeture de votre client.
  3. On place sur le calendrier les dates importantes déjà négociées avec le Product Owner ou le client : démos spéciales, revue de sprint, go live,…
  4. Chaque intervenant (Team Member, Scrum Master et Product Owner) est identifié par une couleur.Calendrier visuel 2
  5. Chaque membre de l'équipe spécifie ses éventuelles vacances et disponibilités sur le calendrier. On distingue les jours "ON", la personne est sur le projet, et les jours "OFF", la personne n’est pas disponible sur le projet.

Ensuite à vous de jouer avec les concepts de jour ON et OFF, afin de ne pas surcharger votre calendrier et d’avoir une visibilité maximum. Dans notre exemple les personnes à temps plein précisent leurs jours d’absences jours OFF, pour les personnes à mi–temps, elles précisent leurs jours de présence "jours ON".

  • Exemple1 : Bob est à 80% sur le projet, il ne sera pas disponible pendant 4 jours sur le sprint, il colle 4 post-its de sa couleur sur le calendrier avec la mention «Bob OFF», ces jours là il n’est pas présent sur le projet
  • Exemple2 : Gérard preste 2 jours sur le projet, il place 2 post-its de sa couleur avec la mention «Gérard ON» sur le calendrier.

Tout évènement important est ajouté en cours de sprint : présence du Product Owner, réunion éventuelle, déplacement à l’extérieur (et donc indisponibilité) etc... Afin de conscientiser l’équipe à l’importance que nous donnons à cet outil, chaque mois une personne différente le réalise (temps de réalisation entre 5 et 15 minutes). C’est aussi l’occasion pour chacun d’y aller d’un soupçon de créativité.

Calendrier visuel  FR« Okay Bruno, c’est bien ce que tu nous racontes mais, tu nous dis d’être visuel et dans ton article tu écris plein de texte… »,
« Bruno je dois dire… là je suis un peu perdu… »
Ok tu as raison mon ami voici donc les points 1 à 6 réexpliqués de manière plus visuelle (cliquer pour agrandir).

This is it !

Une fois cet outil réalisé vous pourrez instantanément répondre à des questions comme :

  • Team Member: « Quand Gérard est-il présent ? J’ai besoin de lui pour finaliser mon module ! »
  • Product Owner: « J’aimerais valider les User Stories terminées, quel est le meilleur jour pour que je vienne cette semaine ? »
  • Team Member: « Quand organiser notre meeting avec le client et notre expert technique ? »
  • Team member: « il vient quand le Product Owner ? »
  • X: « C’est quand encore la démo ? J’ai pas reçu l’invitation ? »
  • Scrum Master: « Quel est le meilleur jour pour offrir un verre à l’équipe ? »

et cerise sur le gâteau… ça fonctionne même en cas de panne du réseau, virus ou autre problème informatique ! Comme toujours, faites évoluer votre outil au fur et à mesure des sprints et en fonction des différents feedbacks des participants !

Comme toujours, je ne vous demande pas de me croire…je vous invite juste à essayer. Allez-y, testez cet outil, personnalisez le à votre façon, inventez vos propres règles…et donnez moi du feedback sur votre expérience

Bonne visualisation à tous.

Bruno

Présentation de l'auteur

Bruno SbilleJe suis dans la consultance ICT & Business depuis plus de 10ans. En plus de mes expériences en gestion de projet, ces quatre dernières années j'ai pu découvrir de nouveaux ustensiles à ajouter dans ma boîte à outils : Scrum, Agile, la PNL, le Coaching, Le "People Management", Diverses Techniques de Créativité etc...
Ma passion : mettre les gens ensemble et "y arriver" tout en gardant du sens.
Je blogue régulièrement sur Scrum, Agile et le Management : Scrum and Agile in Belgium.

Le Lean Startup

J'ai le plaisir d'accueillir un invité qui va nous parler du Lean Startup.

C'est seulement la deuxième fois que mon blog publie un billet que je n'écris pas moi-même. Le premier était de Bruno, qui est devenu célèbre depuis.

Mon deuxième invité est Nicolas Deverge, lean startuper chez ekito, créateur de TeamMood.


A l'instar de Scrum, le Lean Startup est très simple à comprendre. Ce n'est que du bon sens, mais exactement ce que l'on ne fait pas traditionnellement.

Le Lean Startup est une démarche scientifique qui permet de valider des hypothèses (ideas), à partir d'une série d'expérimentations auprès de ses clients.

En effet, le “lean startuper” part du principe que tout n'est qu'hypothèse (le problème, la solution, le segment client, etc.) et il va chercher à démontrer ou réfuter chacune de celles-ci en menant des expérimentations.

Chaque expérimentation consiste à mettre entre les mains de ses utilisateurs un produit minimum viable (acronyme MVP en anglais), contenant un certain nombre de sondes de mesures permettant de valider ou réfuter objectivement l'hypothèse de départ.

Lean Startup



Le fait de réfuter une hypothèse et d’en essayer une nouvelle s’appelle le pivot.

Le Lean Startup est une démarche apprenante qui force à être au plus tôt sur le terrain, au plus près de ses utilisateurs/clients.

À noter que le Lean Startup n'est pas seulement réservé aux startups, mais qu'il peut aussi être mis en œuvre dans le contexte de grandes sociétés pour supporter leur démarche d'innovation.

Traditionnellement, une approche par la planification est utilisée, grâce aux Business Plans (à 3 ans ou 5 ans pour les plus téméraires), qui tentent de prédire ce qui va se passer dans la vie du projet. Malheureusement, une startup, qui par définition tente d'apporter une innovation (pas forcément sur le produit, mais peut être sur le modèle économique, le canal de distribution ou autre), évolue dans un milieu plus qu'incertain.

Le Lean Startup a été conçu à partir du constat qu'il est presque impossible de prédire l'avenir, et donc plutôt que d'essayer d'écrire l'avenir, nous nous plaçons en mode réactif en essayant de rebondir sur les opportunités qui se présentent à nous.


Plus sur Nicolas :

Après avoir passé six ans dans une startup où il se posait beaucoup de questions en terme d'organisation, Nicolas Deverge a découvert l'Agilité en 2007 en intégrant la société Toulousaine ekito.

Depuis 2010, il accompagne de petites et grandes sociétés dans leur transition vers l'Agilité, et, depuis 2012, il travaille avec des entrepreneurs en s'inspirant de la démarche Lean Startup. C'est en étant au contact de toutes ces startups que Nicolas a eu l'envie de réaliser ses propres projets entrepreneuriaux, comme TeamMood.

Arrêter Scrum pour le flux, un début d’expérience

Suite à ma présentation à Lean Kanban France, j'ai reçu un message de Sophie. Elle accompagne une équipe confrontée à des difficultés avec Scrum qu'elle a aiguillée vers Kanban.

Son expérience est intéressante et elle la raconte bien, alors nous avons décidé de la publier.

Il s'agit donc d'un billet invité, autrement dit de guest blogging.

Voici le message de Sophie de Sophia :


Bonjour Claude,

Je viens de lire ta présentation “Appliquer Kanban sur Scrum”... j’aurais bien aimé y assister ! Cet article m'a fait revenir de fil en aiguille à ton post "Arrêter Scrum pour le flux, mmmmh !".

Voici un cas concret qui peut alimenter les réflexions : il y a quelques mois, j'ai été sollicitée pour accompagner une équipe vers l'agilité (tout un programme !).

Le contexte : un acteur industriel avec du cycle en V dans ses chromosomes, du développement embarqué critique sur du hardware spécifique. S’ajoutent à ça des contraintes d’externalisation de certains types d’activités au cours du développement et de nombreuses dépendances externes (tout étant spécifique, quand le hardware ou les bancs de tests sont buggués ou pas prêts à temps, ça coince très vite)

…Votre mission, si vous l’acceptez… j’ai accepté ;-)

Lorsque je suis arrivée, l’équipe avait déjà itéré quelques fois, en Scrum car c’est la méthode qui avait été choisie pour ce projet. Il y avait en fait 2 Scrums cascadés : un pour le développement, l’autre pour la validation, décalés d’un sprint, en théorie (sprints de 3 semaines). Toujours en théorie, il fallait donc 6 semaines à une user story pour traverser toutes les activités de réalisation…

Ça c’est la théorie... dans la pratique, le temps de traversée est plutôt plus long, ce qui se traduit par une difficulté systématique à tenir l’engagement du sprint, pas mal de stories “traînant” de sprints en sprints (trop grosses, mais difficulté à les découper plus, pas le même besoin de granularité entre développement et validation, blocages nombreux, etc.)

La première chose qui m’a frappée en arrivant a été le silotage des activités, très difficile à casser, en partie à cause du changement culturel que ça impose à la fois dans les équipes et auprès du management, mais aussi à cause de la réalité du terrain : changer d’activité demande la prise en main d’outils complexes et parfois peu disponibles mais aussi un savoir-faire spécifique. J’ai donc très vite pensé à Kanban, en premier lieu en l’appliquant “par-dessus” les deux Scrums en place, pour tenter de compenser le silotage par une meilleure circulation des stories de silo en silo.

Ça a eu le mérite de fluidifier la coordination entre les deux Scrums (dev et validation), mais ça ne nous a pas permis d’avancer sur deux points fondamentaux :

  1. le temps de traversée à plus de 6 semaines… mais combien au juste ? On a même commencé à voir fleurir des user stories du type “spécifier la fonctionnalité X” pour avoir des éléments de backlog qu’on pouvait réaliser en 3 semaines,
  2. on ne semblait pas non plus se rapprocher de l’objectif de fournir à intervalles réguliers des incréments logiciels “potentiellement livrables”... vu qu’on commençait à se réjouir de livrer des bouts de spécifications en fin de sprint pour dire qu’on avait fini quelque chose, je voyais bien qu’on commençait à diverger sérieusement.

S’ajoute à ça le début de la phase d’externalisation qui renforce le silotage : le prestataire a contractuellement le droit de réaliser certaines activités, mais pas d’autres. Gros point positif néanmoins : client et prestataire tombent très vite d’accord pour rester en “one team” d’une dizaine de personnes des 2 sociétés. Les locaux du prestataire étant à 200m, une petite promenade matinale et hop, un daily scrum co-localisé !

C’est à ce moment là que le livre de Laurent Morisseau “Kanban pour l’IT” provoque un déclic :

  • ça renforce mon idée que le Kanban semble adapté à la situation, car casser les silos est une trop grosse révolution pour l’instant et je ne suis même pas sure que ça soit totalement possible,
  • les cadences pour vider le bac de sortie me parlent tout de suite.

Je lance donc l’idée de passer à du flux tiré plutôt que d’essayer de tenir à tout prix un engagement de sprint (des pistes comme le découpage artificiel des stories ou le rallongement de la durée des sprints à... 8 semaines étant vite écartées).

On commence donc à refaire un seul Kanban pour tous, avec le bac “stories prêtes” en amont, un bac “stories à démontrer” en aval et au milieu, nos colonnes modélisation, développement, tests unitaires, validation. L’équipe élabore également les DoD et des limites de travail en cours par colonne.

On garde de Scrum :

  • les sprints, qui deviennent la cadence du Kanban. Le dernier bac “stories à démontrer” est vidé après chaque Sprint Review,
  • les rôles de PO et Scrum Master, car tout le monde en a pris l’habitude et commence à trouver sa place,
  • les cérémonies Scrum à l’exception du sprint planning (l’affinage étant fait au besoin une à deux fois par sprint) puisqu'on visualise les stories prêtes dans leur ordre de priorité, il suffit donc de piocher dedans dès que les limites de travail en cours le permettent.

Pour résumer, ça ressemble à du ScrumBan, mais on a enlevé l’engagement du sprint planning pour le remplacer par du flux tiré. On s’autorise de fait à ce qu’une story prenne plus d’un sprint à être réalisée, et on se focalise sur la mise en évidence et l’optimisation du temps de traversée.

Donc, oui, dans notre cas, on a allègrement zappé le “Shu” du Shu-Ha-Ri (voir l’article Arrêter Scrum pour le flux, mmmmh !). Je suis sincèrement convaincue que c’est pour la bonne cause. Nous appliquons cela depuis une itération et demie, il est encore tôt pour savoir où le chemin emprunté va nous amener :

  • à une analyse fine des blocages et à une meilleure manière de découper nos stories qui nous feront mieux revenir vers Scrum avec des durées de sprints adéquates ?
  • à la conclusion que nos stories sont longues à implémenter et que nous devrons rester sur ce mode ?
  • à une adoption “trop molle” de l’agilité qui ne poussera pas vraiment à l’introspection et à l’envie de travailler plus efficacement ? Est-ce que l’abandon de l’engagement de sprint aura un effet délétère sur la vision de l’avancement avec pour conséquence un inévitable retard ? (je livre ici la peur du management quand nous avons annoncé que nous essayions Kanban et qu’il n’y avait plus “d’engagement” par sprint)

Dans les deux premiers cas, peu m’importe : si à l’arrivée, il s’avère que nous avons pu livrer très souvent des incréments qui ont du sens et qui peuvent être embarqués sur le hardware définitif avec très peu de travail supplémentaire, ce sera une grande victoire !

Dans le dernier cas... eh bien, mauvais chemin !

J’accompagne avec beaucoup de vigilance ce tournant dans notre manière de faire, car effectivement, Kanban bien appliqué requiert beaucoup de discipline et je suis tout à fait en phase avec toi Claude : “Parce que faire vraiment du Kanban, c'est comme pour le vrai Scrum, ça demande de l'investissement”.


Mais qui es tu, Sophie ?

J’ai découvert l’agilité au début des années 2000 en expérimentant l’eXtreme Programming dans une start-up. Ce n’est que bien des années plus tard que j’ai vraiment compris l’étendue du changement de culture auquel invitait l’ensemble des courants agiles. Après une quinzaine d’années d’expérience des projets IT dans divers types de structures, j’ai choisi depuis deux ans de me consacrer à l'accompagnement d'équipes ou d'organisations qui choisissent d'emprunter ce chemin passionnant et riche en aventures.

Je suis également active dans la communauté agile de Sophia Antipolis, au travers de l’organisation de l’Agile Tour Sophia et de l’Agile Playground Sophia.

Sophie Durand (@soph06250, durand.sophie@gmail.com)


Merci Sophie, et à bientôt pour nous dire où ce chemin vous aura conduit.