Greenhopper et Kanban font bon ménage

La première conférence ‘Lean Kanban France’ se tenait les 18 et 19 Octobre dernier à Paris, mobilisant plus d’une centaine de personnes à cette occasion. JIRA et Greenhopper étant résolument orientés Agile, il était naturel que nous répondions présents à l’invitation des organisateurs, et c’est avec une certaine excitation que nous sponsorisions l’évènement aux côtés d’Atlassian.

Nous avions surtout hâte de venir à la rencontre des adeptes les plus avancés des méthodologies Agile qu’ils soient férus de SCRUM ou plus enclin à démocratiser les pratiques KANBAN –  afin de nous inspirer toujours plus de leur vision et de mieux appréhender leurs attentes.

Chose remarquable : une ambiance très bon enfant a parcouru la conférence tout du long de ces deux journées, favorisant les rencontres et le partage de perspectives. Nous n’avons pas rencontré un seul participant qui n’était pas enjoué à l’idée d’échanger avec ses pairs, tous secteurs d’activité confondus.

Mais le plus surprenant était sans aucun doute de rencontrer des personnes aux profils variés – développeur, coach Agile, responsable R&D – convaincues et désireuses de pouvoir révolutionner de manière incrémentale les pratiques de développement, et de transformer intrinsèquement l’outillage de leurs entreprises au risque parfois d’entrer en conflit avec un top management très (trop) conservateur ou pointant du doigt un équilibre budgétaire fragile.

Toutefois s’il ne fallait retenir qu’un seul précepte (et quel précepte !), c’est qu’en définitive nous sommes tous au fait des méthodes Agile, sciemment ou non, et possédons déjà le capital nécessaire qui favoriserait leur émancipation. Qu’on se le dise, l’Agile se démocratise jour après jour ; et à travers une série de séances plénières (notamment animée par David J. Anderson – pionnier mondial du Kanban), de workshops et de retours d’expérience, il n’était pas difficile de réaliser en sortie que nous pouvons tous pratiquer ces méthodes à moindre effort.

Pourtant, il semble que la méthode soit encore assez peu répandue à ce jour (surtout en comparaison avec Scrum), certainement du fait d’un certain scepticisme ; car provenant à l’origine du Toyotisme et relevant davantage du monde industriel que des logiques propres aux équipes de développement.

Mais qu’en est-il concrètement ? Dimitri BAELI et Guillaume LOURS, tous deux conférenciers réputés dans le monde de l’Agile, tenaient justement une séance introductive aux principes fondamentaux du Kanban dont je vous propose ici la synthèse – et surtout une mise en relief à travers Greenhopper.

1/ VISUALISER

Quel que soit votre activité ou métier, tous vos collaborateurs doivent avoir une visibilité sur l’ensemble du processus et des informations associées. Ces dernières doivent  être traçables et accessibles par le management qui assure le suivi.

La traçabilité est l’essence même de JIRA et c’est ce qui plait tant au management. Greenhopper pour sa part apporte un confort d’utilisation et permet de visualiser de manière très ergonomique un sprint, votre backlog ou bien entendu votre workflow via le Rapid Board –  chaque colonne représente ainsi une étape ou statut.

2/ LIMITER LE WORK-IN-PROGRESS

Certainement le principe le plus intéressant et le plus délicat à faire respecter. Car il s’agit purement et simplement de limiter l’encours des tâches affectées aux collaborateurs, dans la logique de favoriser la productivité. Chaque chose en son temps, point barre.

En mode Kanban, Greenhopper vous offre la possibilité d’appliquer deux contraintes (min et max) par colonne, c’est-à-dire de définir un intervalle de demandes à respecter par étape (statut de workflow). Un affichage visuel vous prévient si vous êtes en sous ou sur-production, et donc vous permet de lisser votre encours de tâches.

3/ RENDRE LES REGLES DE TRAVAIL EXPLICITES

Il s’agit de règles communes à tous les collaborateurs, qu’il faut rendre le plus simple possible afin de ne pas créer d’ambigüité. A titre de comparaison, on pourra évoquer ici la similitude avec le « Definition of Done » existant pour le Scrum. Et à titre d’exemple, on peut citer la phrase-type : « A partir de quel moment passe-t-on d’une colonne à une autre ? ».

Ce n’est plus un secret : depuis la v5.x Atlassian met le paquet sur les aspects collaboratifs et fait en sorte que JIRA (on ne mentionnera pas l’utilisation intégrée à Confluence qui en décuple les effets !) soit un outil central pour l’équipe de développement. Impossible donc de passer outre les multiples facettes optimisant la communication entre collègues et favorisant l’adoption des mêmes règles/codes/habitudes/pratiques (rayez les mentions inutiles) de travail. Greenhopper permet en outre de faciliter l’édition des tâches à la volée et le partage d’informations (notification, commentaires, etc.).

4/ MESURER ET PILOTER

Ce principe simple doit permettre aux collaborateurs d’échanger et d’argumenter de manière précise et ciblée quant à la nécessité de modifier (ou non) un processus, en se basant sur des éléments factuels et tangibles (et donc mesurables).

Burndown Charts, rétrospectives de sprint, analyse de tendances… que de belles courbes et pixels en pagaille que les habitués de Greenhopper vous conseilleraient ! Les rapports natifs de l’outil raviront les amateurs de KPI (oui, pour ma part je plaide coupable) et vous assisteront régulièrement dans l’orientation des efforts de votre équipe.

5/ AMELIORATION CONTINUE

Si le processus offre une visibilité suffisante et que celui-ci est bien implémenté au sein d’une équipe, il devient alors possible d’identifier naturellement des obstacles ou des incohérences et donc de les supprimer progressivement. Logiquement, cela pourra se vérifier à travers le principe n°4 (Mesurer et Piloter) et l’objectif ultime est donc d’obtenir un cercle vertueux de ses processus.

L’innovation est la clef de l’amélioration continue : rien de plus simple via Greenhopper que de visualiser la progression d’une équipe, la vitesse d’exécution (via les estimations et les temps passés) qui laisseront apparaitre des obstacles dans le processus, et donc de modifier en conséquence la configuration de votre projet. Plus d’informations : http://atlassian.com/agile/overview

A ces fondamentaux s’ajoutent quelques règles de bon sens. La première étant qu’il faut « commencer par finir, et finir par commencer » : comprenez par là que tant qu’une tâche n’est pas réalisée, il ne sert strictement à rien d’entamer autre chose au risque de vous disperser dans vos efforts et donc d’être anti-productif. Il faut donc initier un « flux tiré » : si une tâche n’est pas terminée, on ne peut pas la transférer dans la colonne suivante et donc on ne peut pas (on ne doit pas) faire avancer des tâches en amont. Pour l’image, on peut retenir le phénomène des vases communiquant.

Autre règle : le traitement de l’urgence. Sur le papier, le principe du Work-In-Progress (WIP) est très séduisant, mais encore faudrait-il pouvoir faire abstraction des demandes « ultra-urgentes » ou « top priorité » qui nous parviennent quotidiennement pour nous focaliser sur l’encours des tâches. Mission impossible ? Pas du tout vous répondrait Tom, mais à condition d’être ferme et de définir stricto sensu l’urgence comme très exceptionnelle.

Greenhopper vous permet à ce titre d’avoir recours à la fonctionnalité des Swimlanes, permettant de dissocier d’un seul coup d’œil les tâches urgentes du reste.

De manière générale, le système de développement doit être fluidifié au maximum. Pour cela, on s’appuiera par exemple sur un confort de visualisation qui peut s’opérer par l’adoption de codes visuels et de couleurs (omniprésents dans Greenhopper). Mais on retiendra surtout la notion du temps, qui tient une place centrale, à travers la chaîne ou chemin de valeur qui décrit le temps écoulé entre l’idée d’un développement et la livraison de celui-ci.

Selon les pratiques de développement en vigueur, cette chaîne peut s’avérer longue et la méthode Kanban vise justement à l’améliorer (la raccourcir) continuellement. En effet, il devient simple (« et plaisant » d’après Dimitri Baeli) de pouvoir reconstruire le chemin de valeur pour mesurer le temps écoulé entre chaque étape et de le réduire au maximum par des actions mécaniques (Par exemple : si votre Todo est trop longue, une action mécanique sera de la découper en deux Todo !).

Implicitement, la mécanique Kanban suggère surtout que ce soit l’équipe de développement qui (re)vienne demander du travail aux utilisateurs finaux, afin d’alimenter régulièrement l’encours des tâches et de ne pas se retrouver en sous-production. A contrario, cette logique de flux tiré (initié et mené par les développeurs) permet d’éviter tant que possible un engorgement de l’encours et donc la dégradation de la qualité du à la surcharge de travail.

Cela implique forcément que des équipes Kanban et des utilisateurs non-Kanban – du fait de leurs pratiques de travail différentes – doivent apprendre à collaborer en essayant progressivement de définir une cadence commune de travail.

En revanche, une équipe Kanban ne pourra jamais s’engager formellement sur les délais de production : c’est à ce prix que l’on pourra s’assurer de préserver la qualité du développement. En définitive, nous voyons émerger l’ère du Just-in-Time de l’informatique.

Mais au fait, quelle est la relation entre Scrum et Kanban ?

D’après Dimitri Baeli, ces deux pratiques sont en réalité complémentaires : Scrum est un système « de base » permettant de bien stabiliser le travail d’une équipe, auquel Kanban apporte une dimension supplémentaire en limitant le nombre de tâches et de user stories. Welcome to SCRUMBAN !