Ma problématique :

1. Scrum et les méthodes agiles connaissent un succès exponentiel en ce moment : il suffit de jeter un oeil au Google Trends…
2. Les SSII veulent manger leur part du gâteau, les entreprises se ruent dessus
3. Il n’est pas aisé pour les SSII ou les entreprises de mettre en place Scrum pour -à mes yeux- deux principales raisons : contractualisation, stabilité/pérénité de l’équipe (la troisième serait “responsabilisation” du product owner, et donc du client quel qu’il soit)

A la lecture de l’article cité ci-dessus je me dis que la solution réside peut être dans KanBan. Il ne règle pas la question de contractualisation mais il peut régler celle de la stabilité de l’équipe. Pourquoi ? Scrum apporte beaucoup de souplesse en réponse aux besoins d’un projet, mais il n’introduit pas nécessairement beaucoup de souplesse au sein de l’organisation. Il nécessite un rituel fort et contraignant : les sprints,  les daily scrum, les retrospectives, le tout organisé autour d’une équipe très stable et très impliquée. Pour une SSII (ou une entreprise) ce n’est pas si simple à mettre en oeuvre. Rare sont les moments où une équipe peut effectivement entièrement se consacrer à son sprint. Rare sont les projets ou une personne/évènement externe ne vient pas bousculer le planning, les priorités. KanBan propose un cadre moins rigide (oups scrum méthode agile serait rigide, non ne me faites pas dire cela), en tous cas il propose moins de recommandations d’une part (pour reprendre les termes de Henrik Kniberg (cf les liens ci-dessous)), et ne l’assujetti pas à des timeboxes et un rituel régulier (stand up, etc..). Mais le cycle de Kanban se différencie de la vélocité de Scrum. Le rythme/”flow” de Kanban me parait beaucoup moins contraignant. la vélocité de Scrum est rythmée par le rituel, mise en exergue par les burndown chart, on se doit de respecter l’itération : si une user storie n’est pas achevée à la fin du sprint elle n’apparaitra pas dans la démo, elle a été hors du rythme et donc exclue. Là où Kanban -il me semble- va être plus docile : on déduit le rythme des faits, on ne s’y soumet pas.

Bref, l’exercice de suivre la rythmique de Scrum n’est pas aisé, je me répète, d’où aussi l’importance de la sensibilisation du management au respect des règles d’un projet Scrum. Mon propos est aussi de dire que des fois ce n’est pas possible et qu’il s’agit peut-être là finalement de plutôt se tourner vers Kanban (sans opposer les deux, ce en quoi je ne fais que redire ce que l’article cité ci-dessus explique bien mieux).

Autre point qui m’amène à évoquer KanBan, il se peut (double conditionnel alto arrière..) que je sois amené à coacher des équipes composées de 1 à 2 personnes dans un prochain temps. Avec 1 personne Scrum perd de sa substance…  On se retrouve simplement dans le mode héro (oyez CMMi niveau 1…), en espérant que cet acteur solo a une bonne culture de la gestion d’un projet informatique, des outils qu’il peut mettre en place, etc, mais nulle question à mes yeux de réaliser un daily stand up seul, surtout si une seconde personne vient de façon épisodique compléter l’équipe.

Là encore KanBan avec son approche -apparemment- plus simple, et beaucoup moins ritualisée, va peut-être pouvoir répondre à ce besoin. En introduisant un simple “radiateur” KanBan je peux amorcer une gestion rythmée du projet, je n’ai pas de sprint à respecter, je peux introduire une seconde personne de façon épisodique. Bref je me répète :  je peux rythmer plus simplement le projet  et qui dit rythme, dit charge et planification et donc indicateurs et prévisions, etc.

Pour finir et afin de le rappeler une nouvelle fois, je n’ai pas encore mis en oeuvre Kanban à l’inverse de Scrum, excusez moi par avance si j’avance ici des grossièretés à vos yeux de Kanbanmaster (?). Je veux simplement souligner pourquoi KanBan serait une piste intéressante. J’en décèle deux : impossibilité d’appliquer le rituel de Scrum et de garantir la stabilité de l’équipe, l’un étant souvent le corollaire de l’autre.

Un autre article très intéressant : Kanban and Scrum a practical guide et surtout le PDF associé qui compare Scrum à KanBan, celui avec la citation de Myamoto Musashi, …

Kanban board

Appliquer Scrum n’est pas simple, surtout pour les SSII. L’un des principaux facteurs dont je souffre actuellement est la stabilité des équipes. les impératifs de production, eux-mêmes menés par des impératifs financiers règnent trop souvent en maîtres, et c’est normal. C’est aussi le signe me direz-vous que les processus et les méthodes ne sont pas assez matures puisqu’au moindre coup de vent (un gros contrat signé, une régie déclenchée pour un élément clef de l’équipe, etc.) ils volent en éclats. Je ne peux pas vous contre-dire. Je n’ai pas eu la chance de connaitre une entreprise qui -quelque soit le contexte (la crise par exemple)-  soit capable de maintenir coûte que coûte l’intégralité de ses processus tout en les faisant progresser (ces derniers mots sont importants sinon c’est la fossilisation qui vous guette).

Aujourd’hui beaucoup de SSII se jettent sur les méthodes agiles car elles ont le vent en poupe. Elles se heurtent à de nombreuses problématiques avec, pour n’en citer que quelques unes :

• la contractualisation (le  problème majeur actuellement, puisque ce n’est que le début de leur offre dans ce domaine, et que c’est un élément très fondateur,),  ils leur faut trouver une troisème voie entre le forfait et la régie (merci Christophe).
• la redistribution des rôles : le client (product owner) est responsable, l’équipe (team) est responsable, le Chef de projet disparaît, il était le responsable, le fusible, Atlas qui portait le projet (accessoirement avec le directeur de projet) ; le Scrummaster apparaît, il est un facilitateur, mais nullement un responsable.
• la stabilité des équipes durant les sprints, les itérations, est nécessaire.
• la maturité des clients et des équipes, personne n’est interchangeable, chaque collaborateur est différent d’un autre, etc.

Les SSII entament donc un difficile périple. Aujourd’hui si je regarde l’un des projets que je pousse vers l’agilité je me heurte de plein fouet à la difficulté de la stabilité de l’équipe. Il ne s’agit pas d’un projet client, mais d’un projet interne. Il est d’autant plus saccadé. Sa priorité est difficile à établir. Les ressources affluent (fin de projets clients) et elles refluent (signature de projets clients). Moi même je ne peux avoir qu’une activité chaotique à son encontre. Appliquer les fondements de Scrum dans ce contexte devient très compliqué. Mais l’agilité c’est aussi une dynamique de l’adaptation. Je me tourne donc aujourd’hui pour ce projet vers Kanban.

Pourquoi ? Il me propose des valeurs qui sont en adéquations avec mes besoins (certains sont aussi associées à Scrum), ne pas développer de fonctionnalité que personne ne va utiliser, ne pas écrire plus de specs qu’il n’y aura de code, ne pas écrire plus de code que je ne puisse tester, ne pas tester plus de code que je ne puisse déployer. Très concrètement ne pouvant bâtir une équipe stable, ne pouvant garantir de daily scrum journalier, n’ayant pas assez de garanties sur la pérennité de mon équipe, etc. je vais me focaliser sur ce que j’imagine être l’essentiel de la pratique Kanban et à partir de là reconstruire un processus agile (si cela marche). Soyons clair, il permet surtout de simplifier excessivement le processus, et si cela fonctionne il me permettra de rebondir sur quelque chose de plus puissant. Ceci dans le cadre de ce projet.

Je ne sais plus où (ah si, ici)  j’ai lu cet exemple mais en gros, de façon imagée : je pose des portes sur une voiture (Kanban vient -encore- de Toyota), j’ai un tas de 10 portes devant moi, lorsque j’arrive à la 5ème porte je vois une étiquette sur la voiture (étiquette = kanban en japonais). L’étiquette m’indique que je dois prévenir la personne qui fabrique les portes de me fabriquer 10 portes supplémentaires. Je trouve cette personne et lui demande 10 portes supplémentaires. Elle arrête la tâche qu’elle était en train de réaliser, et commence à fabriquer 10 portes supplémentaires. Elle savait que je passerais, mais travaillait sur autre chose. Je retourne à mon assemblage. Lorsque je finis presque mon tas de 10 portes, la personne a qui j’avais demandé les nouvelles portes arrive, elle dépose les portes, et naturellement, sur la 5ème, au milieu du tas, une petite étiquette est présente.etc.

Ici, sur ce fameux projet interne, je dispose d’un backlog et d’une équipe fluctuante dont la disponibilité est fluctuante.Ma difficulté est le WIP (Work in progress). Je ne dois pas avoir un membre de l’équipe qui démarre quelque chose et qui malheureusement ne peut l’achever (pour x raisons). Sinon je me retrouve avec une tâche de coordination (du nouveau membre remplacé par l’ancien), de transfert de compétences (du nouveau …) , et potentiellement de rework (le nouveau membre de l’équipe aborde différemment la résolution de sa tâche). Bref 3 plaies essentielles sources de gaspillage.

Mon objectif est de définir des User Story (ou MMF : minimal marketable feature) assez compactes et assez indépendantes les unes des autres pour qu’elles puissent être abordées unitairement et assez rapidement : pour ne pas risquer de perdre l’acteur qui l’a prise en charge, pour qu’il puisse appréhender la MMF rapidement. Avoir assez de visibilité sur l’ensemble des MMF pour qu’elles puissent s’enchainer et constituer de la valeur ajoutée. Faire des livraisons plus rapidement, plus rythmées. Quand un flux régulier sera mis en place j’aurais mis en place un premier niveau d’efficacité. L’objectif de ce flux est de réussir à créer un rythme et une régulation entre les différentes tâches liées au projet, en limitant au maximum le “work in progress” car c’est lui qui m’empêche de livrer régulièrement et qui rigidifie la marche du projet. Chaque tâche s’emboite avec d’autres, ou peut en déclencher d’autres sans que les personnes qui aient la charge de ces autres tâches ne soient impactées. Elles ont donc du “temps libre” pour leurs autres activités (sachant qu’ici le procédé est inversé, c’est quand elles ont du temps libre qu’elles se consacrent au projet “interne”) . Enfin il est plus aisé d’intervenir sur le projet quand chaque tâche est plus compacte (ceci n’est malheureusement pas si simple et pas si souvent vrai).

D’ici là, et si j’atteins ce but… nous en reparlerons.

Pour en savoir plus sur Kanban, appelez Google, ou utilisez cette page de cet excellent blog : targetprocess : kanban.