Scrum sans itérations ?

« Scrum sans itérations ? » un concept étrange que d’imaginer une méthode itérative sans itérations … Et pourtant nombre de blogs de l’écosystème agile présentent Kanban, un processus par définition non itératif, comme une évolution intéressante pour les projets Scrum.

L’objectif de cet article est donc d’illustrer comment ces deux approches, d’apparence contradictoires, peuvent se compléter pour le plus grand bonheur de nos utilisateurs ! L’article s’adresse à des lecteurs déjà sensibilisés à Scrum, si vous ne connaissez pas ce kit méthodologique, Wikipedia est un bon point d’entrée.

Quelques illustrations de cet article ont été récupérées de l’excellent blog de Henrik Kniberg.

Les limites de Scrum

Lorsqu’une équipe devient mature sur l’utilisation de Scrum (et ceci peut prendre du temps !) elle commence à en discerner les limites. Pour ma part, voici celles que j’ai pu constater après quelques années de Scrum sur différents projets, et surtout les solutions que nous avons trouvé à l’époque pour y remédier.

• La première frustration était l’impossibilité de changer le backlog de Sprint lors du Sprint. « It’s not a bug, it’s a feature » me direz-vous ! En effet il s’agit d’une mesure destinée à protéger les équipes de développements des changements de dernière minute nuisant à la productivité globale. Néanmoins, que deviennent ces fonctionalités cruciales qui devraient VRAIMENT rentrer en cours de sprint ? Il y a des chances qu’elles prennent la file d’attente … dommage ! On finit donc par autoriser des arbitrages sur le contenu du sprint en cours de sprint (du type : je remplace une user story par une autre) [1]
• Et à l’inverse, si une fonctionnalité ne peut pas « rentrer » en cours de Sprint, elle ne peut pas non plus être livrée en cours de Sprint : il faut attendre la fin de l’itération pour rendre la fonctionnalité disponible aux utilisateurs. Quand bien même la fonctionnalité utile est terminée au bout de deux jours de Sprint, il faudra atteindre la fin pour la livrer. Cette fois, la solution apportée par l’équipe projet fut de faire des livraisons intermédiaires en cours de sprint (toutes les semaines, puis toutes les demi-semaines) [2]

Un cas extrême où la rigidité des sprints mène à des gaspillages ("Travail partiellement fait" au sens Lean)

• A ce stade, rares sont les équipes qui n’ont pas eu l’initiative de raccourcir la durée de leurs itérations à une ou deux semaines. Se pose alors la question du rythme soutenable : la flexibilité est là, mais la cadence élevée des rituels projets (les rétrospectives par exemple) plombent la vélocité et le moral de l’équipe. Nouvel aménagement au processus : on choisit de ne tenir les rétrospectives qu’une itération sur deux [3]
• Une autre évolution apportée par l’équipe de développement fut d’intégrer les activités MOA au sprint [4]. En effet depuis peu les développeurs ne partent plus des user stories mais de spécifications exécutables, rédigées en binôme avec un MOA.
• Enfin l’équipe s’est rendue compte qu’à chaque évolution majeure de l’architecture de déploiement (nouveau composant, nouveaux fichiers de configuration, nouveaux flux à ouvrir …) la mise en production peut être problématique et se solder par un retard de quelques jours. Qu’à cela ne tienne, désormais à chaque livraison jugée sensible un développeur sort du Scrum pour binômer avec un membre de l’exploitation [5]

Après réflexion on se rend compte qu’aucune de ces situations n’était vraiment insoluble. Après micro-ajustements successifs nous avons réussi à contourner l’ensemble de ces limitations. Mais cherchons maintenant à tirer un enseignement de ces améliorations en identifiant les signaux faibles qu’elles portent et en les amplifiant :

• En amplifiant le signal [1], nous imaginons un projet où les responsables produit peuvent réarbitrer à volonté la liste des user-stories en développement.
• Le signal [2] nous apprend que nous souhaiterions pouvoir livrer toujours plus souvent des incréments logiciels toujours plus petits.
• L’amélioration [3] témoigne du besoin de décoreller totalement les rituels qui rythment la vie du projet des cycles de développement et de livraisons de fonctionnalités.
• Amplifier les signaux [4] et [5] illustre notre volonté d‘élargir l’équipe de développement à tous les acteurs impliqués dans la livraison d’une nouvelle fonctionnalité.
• Pour finir le signal [5] nous apprend que l’on peut minimiser les goulets d’étranglement en réaffectant les membres de l’équipe projet d’une activité à une autre.

Et devinez quoi ? Combiner ces signaux amène tout droit notre équipe vers un processus de type Kanban.

Kanban à la rescousse

kanban est une pratique Lean. Avant d’aller plus loin, je vais tenter de définir ces termes.

Tout d’abord le Lean Management est la vision industrielle de Toyota qui prône :

• Un amaigrissement (lean) perpétuel des processus par chasse aux gaspillages. Ces optimisations contribuent à l’amélioration continue des standards de l’entreprise.
• Une vision globale de l’objectif de l’entreprise. Le Lean va donc favoriser la recherche de l’optimum global (tandis que la quête d’optima locaux peut parfois être contre-productive).

Je ne m’attarde pas sur les autres valeurs Lean qui ne servent pas directement mon propos, mais je vous encourage à lire cet article.

Quant à kanban (avec une minuscule), il s’agit d’un outil de gestion des chaines de production créée par Toyota en respect des valeurs Lean. Lorsque l’on parle de kanban on parle de « flux tiré » : le principe étant que dans une chaine de production, après avoir traité un élément, chaque étape demande à l’étape précédente de lui fournir un autre élément à traiter, quelque soit la taille du stock de pièces qui lui reste à traiter. Cela crée un flux de demande qui remonte le flux de création de valeur, depuis la demande client jusqu’à la première étape du processus.

Ce schéma illustre l'utilisation de tickets kanban pour limiter l'encours : s'il n'y a plus de tickets disponibles dans la phase "Allocate" le processus est bloqué. Signe qu'il faut améliorer le processus pour récupérer un ticket plutôt que d'augment le flot de demandes.

De cet outil inventé par Toyota est né Kanban (avec une majuscule), une méthode agile

• De visualiser la chaîne de valeur dans son ensemble : de la demande initiale jusqu’à la livraison (on retrouve bien le principe Lean d’optimisation globale). Et ceci afin de minimiser le temps de cycle (le temps que mets un élément à parcourir toute la chaîne).
• De limiter l’encours (ou WIP, Work In Process) par distribution de tickets Kanban. Pourquoi limiter l’encours ? Car il s’agit de la meilleure manière d’optimiser le temps de cycle. Si ce point précis vous interpelle, je vous suggère de lire cet article sur la loi de Little.

C’est super ces principes industriels, mais on peut revenir à Scrum et au développement logiciel ?

Ok, établissons maintenant un parallèle entre Scrum et Kanban :

• Scrum est centré sur les activités de développement et ne permet pas d’avoir une vision globale de la chaîne de valeur. On se rend compte que les activités en amont de la chaîne (comme la rédaction de user stories) ou en aval (comme la mise en production de livrables logiciels) sont totalement exclues du périmètre de Scrum.
• Il est difficile en Scrum de mesurer et d’optimiser le temps de cycle. Et ceci à cause même des itérations
• En revanche la vélocité de sprint Scrum correspond bien au concept de limitation de l’encours : le nombre de fonctionnalités en entrée d’un sprint correspond aux nombre de fonctionnalités traitées lors du dernier sprint.

Donc j’arrête Scrum et je mets à Kanban ?

Non car Kanban n’est pas à proprement parler une méthodologie de développement logiciel : Kanban est beaucoup moins prescriptif que Scrum et est donc beaucoup plus difficile à appliquer en partant de zéro.

A mon sens, il faut considérer Kanban comme une évolution possible de certains projets Scrum atteignant des limites « aux frontières » des sprints. Voici pour moi la transition d’un projet Scrum en Kanban :

• Les débuts et fin de sprint de moins en moins marqués conduisent à la suppression des itérations. En revanche le rythme trouvé par la dynamique des sprints est conservé : stand-ups, rétrospectives, brainstorms …
• Le tableau Scrum (qui devient un tableau Kanban) voit ses activités étendues : de la définition du besoin à la mise en production.
• Le process est continuellement alimenté en nouvelles demandes (dans la limite de l’encours) et non plus seulement au début de chaque itération. De plus le tableau Kanban n’est plus jamais réinitialisé.
• Le rythme de vie de l’équipe (les rituels projets : stand-ups meetings, rétroscpectives) est décorellé du cycle de développement et de livraison
• Les incréments logiciels livrés sont désormais des fonctionnalités unitaires (des MMF). Ceci n’emêche pas d’organiser le regroupement des MMF au sein de releases cohérentes

Comparaison de calendriers Scrum et Kanban : si les itérations ne sont plus là, l'esprit itératif y est toujours !

Je vous encourage vivement à jeter un oeil sur ce strip qui illustre de la meilleure de manière comment un tableau Kanban vit (pour votre compréhension le chiffre en haut des colonnes indique l’encours maximal pour une activité : ici pas plus de 2 tâches en développement en simultané)

Non vraiment allez voir ce strip avant de poursuivre la lecture de l’article, c’est très pédagogique :)

De l’agilité à monter soi même

En conclusion j’ai repris ce titre d’une session de Laurent Bossavit qui me parle particulièrement.

De nombreux blogs ont déjà rabâché le fait de ne pas sectariser l’utilisation de Scrum plutôt que XP mais plutôt d’habilement mêler les pratiques de l’un dans le process de l’autre. De la même manière je pense que le passage à Kanban doit uniquement être une source d’inspiration pour des projets agiles (Scrum ou non) qui atteignent aujourd’hui des limites que les seules pratiques agiles ne peuvent résoudre.

Quels bénéfices attendre d’une Kanbanisation de votre projet ? Principalement :

• Une identification et une résolution plus aisée des gaspillages et des goulets d’étranglement
• Une flexibilité accrue et une capacité d’arbitrage plus importante
• Au final, un débit de livraison plus élevé

Mais attention, la mise en oeuvre de Kanban est exigeante et requiert des équipes déjà particulièrement matures sur les valeurs lean et les pratiques agiles. Voici à mon sens quelques unes des qualités exigées pour se lancer dans l’aventure Kanban :

• Une grande rigueur dans le suivi des rituels projets, notamment stand-up-meetings et rétrospectives.
• Une capacité à embarquer et à impliquer au plus tôt tous les acteurs participant à la chaîne de valeur logicielle.
• Une capacité à apprendre de l’existant pour améliorer les standards. Par exemple Kanban ne préconise pas les activités à suivre ni les encours à fixer : expérimentez, apprenez et améliorez !
• Sensibilisation au principe lean « build quality in » qui consiste à ce qu’une tâche soit réalisée en une fois avec la qualité maximale (avec tests unitaires, documentation …) sans que l’on ait à revenir dessus. En Kanban, lorsqu’une fonctionnalité est terminée, elle est livrée (tandis qu‘une itération fournit une sécurité de quelques jours)
• Gestion de configuration logicielle éprouvée. Etes vous capable avec votre gestion CVS ou Subversion de livrer vos fonctionnalités indépendamment les unes des autres ?

Alors … saurez-vous franchir le pas de faire du Scrum sans itérations ?

Pour aller plus loin

Je vous ai déjà matraqué de liens tout du long de cet article, néanmoins voici quelques lecture intéressantes pour approfondir le sujet :

• Implementing Lean Software Development, de Mary et Tom Poppendieck
• Kanban vs Scrum, un livre blanc signé Henrik Kniberg
• http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
• http://leansoftwareengineering.com/ksse/scrum-ban/
• Le blog de David Anderson (référence et instigateur de la méthode)
• Le groupe de discussion Yahoo
• Le site de la federation des initiatives « WIP oriented »