Cela fait presque 10 ans que j’ai commence a travailler avec l’agile. Je me souviens que ma premiere experience a ete lorsque je travaillais dans le sud de la France pour Amadeus. A cette epoque, la direction de l’entreprise avait propose de changer et de mettre a jour la facon de travailler des equipes de developpement, et de proceder a une adoption des methodologies agiles, principalement en utilisant le framework Scrum. Dans mon equipe, on m’a propose une formation de Scrum Master, qui a dure 3 jours, apres quoi j’ai du passer un examen pour obtenir la certification. Et c’est ainsi que je suis devenu un Scrum Master certifie.

Depuis lors, j’ai eu l’occasion de travailler avec Scrum dans 3 entreprises et 8 equipes differentes, realisant des projets et developpant des produits pour des objectifs tres divers. Cependant, j’en ai garde un sentiment mitige. D’un cote, je crois que l’idee de Scrum de decomposer le travail en petites iterations et de publier des versions frequemment pour que les clients les testent et fournissent des retours nous a beaucoup apporte. Mais d’un autre cote, assez souvent j’ai vu comment la productivite de l’equipe se degradait, et je ne sentais pas que le framework nous donnait les outils pour faire face a la situation. De plus, sa nature tres prescriptive semblait parfois quelque peu rigide pour resoudre nos problemes.

Ces dernieres annees, j’ai egalement travaille avec des equipes qui utilisaient Kanban pour les operations et Scrumban pour le developpement, mais comme avec Scrum, je n’ai pas eu le sentiment qu’ils apportaient toute la valeur que nous attendions.

C’est pour ces raisons que j’ai decide de revisiter les frameworks et methodologies agiles les plus courants pour essayer de comprendre 1) quelle est la philosophie et les idees cles derriere chacun d’eux et 2) quelles ont ete les deficiences ou erreurs possibles commises lors de leur mise en oeuvre dans nos equipes. Mais je veux anticiper que cet article ne vise pas a etre complet dans la description des differentes methodologies et de leurs problemes, mais plutot un compendium d’idees et d’experiences qui sert de point de depart pour explorer plus en detail la methodologie qui nous interesse. Pour cela, les references a la fin de l’article sont vivement recommandees.

Je me suis concentre sur 4 outils, methodologies ou frameworks agiles : Extreme Programming, Scrum, Kanban et Scrumban, car ce sont les plus connus dans l’industrie du logiciel. Mais avant toute chose, je voudrais commencer par le debut : le manifeste agile.

Manifeste Agile

Il a emerge le week-end du 11 au 13 fevrier 2001, lorsqu’un groupe d’ingenieurs logiciels comprenant Martin Fowler, Robert C. Martin, Kent Beck ou Jeff Sutherland, entre autres, se sont reunis dans une station de ski dans les montagnes de l’Utah pour discuter et essayer de parvenir a un cadre commun qui exprimait comment ils concevaient le developpement logiciel. Il est ne en reponse au modele dominant jusqu’alors, qui misait sur de longs processus pilotes par une documentation extensive. Son objectif principal etait de remettre les personnes sous les projecteurs, elles qui avaient ete releguees au second plan dans les grandes organisations bureaucratisees de l’epoque. Les personnes reunies voulaient definir les valeurs et principes d’un nouveau mouvement “culturel” qui servirait a creer des communautes et organisations ou ils sentiraient qu’ils avaient envie de travailler.

agilemanifesto.org

En relisant le manifeste, des situations me viennent a l’esprit ou meme en travaillant avec des frameworks agiles, nous n’avons pas ete fideles au manifeste. Je me souviens d’un cas qui represente bien la valeur de prioriser : “La collaboration avec les clients plutot que la negociation contractuelle.” Il y a quelques annees, dans un projet que nous executions avec une equipe Scrum, nous devions developper une fonctionnalite qui avait ete engagee par contrat, bien que le client nous ait ensuite commente (lors d’une des reunions hebdomadaires) qu’il n’allait pas l’utiliser. Meme ainsi, l’equipe commerciale nous a demande de l’implementer pour eviter de rompre le contrat. Analyse retrospectivement et avec le manifeste sous les yeux, je crois que la maniere appropriee de proceder aurait ete d’appliquer les principes agiles egalement lors de la redaction du contrat. Nous pourrions continuer a inclure des fonctionnalites dans le contrat, mais en ajoutant une clause ou ces fonctionnalites pourraient etre changees pour d’autres (de cout similaire) avec l’accord prealable des deux parties.

Ce n’est qu’un exemple de la facon dont la philosophie agile va bien au-dela de l’organisation du travail d’equipe et implique un changement de mentalite et de facon de travailler pour l’ensemble de l’organisation. C’est pourquoi lorsqu’une entreprise veut mener une transformation agile, elle doit comprendre que cela signifiera un changement de culture et de travail dans nombre de ses departements, pas seulement dans les equipes de developpement. Dans cette optique, il est facile de voir que payer un cours de Scrum Master pour les developpeurs suffira difficilement a mener cette transformation agile dans toute l’entreprise.

Un autre point qui semble interessant a mentionner est celui qui dit “(nous valorisons) les individus et les interactions plutot que les processus et les outils.” J’ai le sentiment que souvent les frameworks et methodologies agiles sont suivis mecaniquement, cochant des cases sur une liste de controle, ignorant qu’ils devraient etre des outils au service des personnes et non l’inverse.

Je ne veux pas m’etendre davantage sur ce point, mais je vous recommande de visiter la page du manifeste et de le lire attentivement. Je suis sur qu’il servira de miroir pour voir comment vous travaillez avec l’agile et voir s’il y a des choses dans votre facon actuelle de travailler que vous pouvez repenser selon les principes agiles.

Extreme Programming

C’est une philosophie de developpement logiciel developpee par Kent Beck a la fin des annees 90, qui est devenue publique en 1999 avec son livre Extreme Programming Explained. On pourrait dire qu’elle sert a inspirer (avec d’autres methodologies existantes) le manifeste agile qui declenche le mouvement agile. L’auteur dit qu’il choisit l’adjectif extreme parce qu’il pense que pour developper un logiciel de qualite, il faut pousser les pratiques de programmation a l’extreme ou a leur expression la plus pure. L’une de ces pratiques qu’il prescrit est le pair programming, qui selon lui devrait etre utilise pour programmer tout le code de production (ce qui personnellement me semble assez extreme).

Beck dit que XP est une tentative de concilier humanite et productivite dans la pratique du developpement logiciel. Et il exprime qu’il a verifie que plus on se traite soi-meme et les autres humainement, plus on est productif. Il preconise d’accepter que les programmeurs sont des personnes dans une activite entre personnes, fuyant les idees prevalentes dans les organisations qui traitaient les developpeurs comme des pieces d’un engrenage complexe denue d’humanite.

La philosophie XP introduit une serie de valeurs, principes et pratiques recommandees pour le developpement logiciel. Et de nombreuses nouvelles idees contraires aux processus prevalents a cette epoque, principalement le Waterfall. Parmi les plus importantes, on trouve le travail en petites iterations ou l’ecoute frequente des retours clients pendant le developpement. Elle recommande egalement que les developpeurs programment la plupart du temps en binomes (pair programming) ou commencent le developpement par les tests (tests first). Elle introduit aussi des concepts comme l’integration continue ou les builds en 10 minutes (nous parlons de 1999), qui ont ete adoptes comme standards de l’industrie.

Ron Jeffries — The Circle of Life: XP Practices

Ces pratiques et principes sont bases sur les valeurs de communication, retour d’information, simplicite, courage et respect. Les deux dernieres valeurs se concentrent sur l’individu. D’une part, il est commente qu’il faut avoir le courage de bien faire son travail, de chercher le succes et de faire face aux consequences (c’est ce que Beck decrit aussi comme extreme). Et d’autre part, les individus d’une equipe doivent avoir suffisamment de respect mutuel avec toutes les parties prenantes, et une ouverture a essayer de nouvelles facons de travailler si c’est la volonte de l’equipe.

Une idee importante est que les pratiques doivent etre ancrees dans des principes et des valeurs. Il faut comprendre pourquoi nous suivons une pratique ; si la raison est qu’elle est imposee par les managers, alors elles deviennent fastidieuses et sujettes a ne pas etre faites correctement ou a etre evitees. Personnellement, je crois que la personne qui introduit les pratiques devrait expliquer la motivation de l’utilisation de cette pratique aux nouveaux membres de l’equipe, puis assurer le suivi de l’adoption de la pratique et souligner la valeur obtenue lorsque les nouveaux membres commencent a l’utiliser. C’est lorsque nous utilisons et voyons de premiere main la valeur qu’une pratique nous apporte que nous avons les informations necessaires pour l’accepter et l’integrer dans notre facon de travailler.

Un autre point important est de vraiment comprendre les pratiques et ce qu’elles nous apportent. Ainsi, nous evitons d’implementer la pratique de maniere incomplete ou de la substituer par une qui semble similaire mais ne l’est pas. Cela se produit, par exemple, lorsque nous substituons le Test Driven Development (TDD) par le Unit Testing. En Test Driven Development, il est prescrit de commencer par ecrire les tests, de les executer pour voir comment ils echouent, puis d’ecrire le code applicatif jusqu’a ce que tous les tests reussissent, et a ce moment-la s’arreter (TDD prescrit que nous ne devrions ecrire que le code necessaire pour passer tous les tests). De cette facon, les tests deviennent le mecanisme pour detecter quand nous avons termine une fonctionnalite et pouvons arreter de coder, en plus de nous forcer a concevoir l’architecture du code pour qu’elle soit testable. Cependant, si nous ecrivons seulement les Unit Tests apres avoir termine le codage de la fonctionnalite, le test ne sert plus a guider le codage de la fonctionnalite, mais sa valeur est reduite au test de la fonctionnalite. De plus, en faisant ainsi, la fonctionnalite est deja codee, donc dans notre tete il y a un sentiment d’avoir termine bien que nous devions encore remplir la formalite fastidieuse des unit tests.

Personnellement, je n’ai connu personne qui travaille avec Extreme Programming dans son expression la plus extensive, et je n’ai pas l’impression que beaucoup d’entreprises le fassent de nos jours non plus (j’ai fait une recherche rapide sur LinkedIn et seulement 30 offres d’emploi en Espagne contiennent les mots Extreme Programming contre plus de 6000 qui contiennent le mot Scrum). Neanmoins, je crois qu’Extreme Programming est une source tres interessante de pratiques et de principes qui peuvent etre appliques dans n’importe laquelle des autres methodologies agiles ; en fait, beaucoup sont deja utilises quand nous travaillons en Scrum, par exemple. De plus, contrairement a d’autres outils qui fonctionnent davantage comme des recettes a suivre, dans le cas de XP, il approfondit les motifs et les raisons, ce qui nous donne plus de ressources pour prendre des decisions robustes qui affectent la facon dont nous travaillons.

Scrum

C’est l’un des frameworks agiles les plus populaires dans l’industrie du developpement logiciel, bien qu’il ne soit plus specifique au logiciel mais soit utilise dans differentes industries. Il est apparu en 1995 et est defini comme une facon d’effectuer le travail d’equipe, plus specifiquement dans de petites equipes multidisciplinaires et autogeneres, ou l’on travaille sur de petites taches avec des cycles de developpement courts (appeles Sprints), a la fin desquels on obtient un increment de fonctionnalite potentiellement livrable.

C’est un processus empirique base sur 3 piliers : transparence, inspection et adaptation qui se manifestent de la maniere suivante : le processus et l’etat du travail en cours sont visibles pour l’equipe et les autres parties prenantes (principe de transparence), cela permet d’inspecter la progression par rapport aux objectifs fixes (principe d’inspection) et d’adapter/ajuster le cap en cas de deviations (principe d’adaptation). Cette adaptation est le resultat de l’amelioration continue que les equipes doivent mener.

Scrum.org: Valeurs Scrum

Bien qu’il partage de nombreuses pratiques de gestion de projet avec XP, il ne prescrit aucune pratique ou principe technique, et bien sur ne presente pas de philosophie specifique sur la facon d’etre developpeur. Ce manque de prescription de principes et pratiques techniques est ce qui a cause et continue de causer de nombreuses implementations defectueuses, ou la dette technique du projet continue de croitre et provoque un declin de la productivite de l’equipe, comme Martin Fowler l’avait deja commente en 2009, dans son article Flaccid Scrum.

Le framework prescrit une serie de roles : Scrum Master, Product Owner et Developers. Le Product Owner est responsable de la vision et de l’objectif du produit. C’est aussi lui qui definit les user stories et les priorise dans le backlog. Le Scrum Master est le garant du processus, celui qui forme l’equipe, leve les impediments et facilite, entre autres choses. Et ensuite les Developers sont ceux qui planifient et executent le travail en garantissant sa qualite et sa conformite aux objectifs du Sprint. Un des problemes que j’ai couramment rencontres est que les personnes couvrant les roles de Product Owner et Scrum Master ont d’autres responsabilites en dehors de Scrum, ce qui fait qu’ils deviennent souvent des goulots d’etranglement qui impactent la productivite de l’equipe. Un cas typique est un Product Owner qui par manque de temps ne definit pas les criteres d’acceptation dans les user stories, obligeant les developpeurs a revoir des user stories deja fermees pour les completer, avec la frustration consequente des clients et des developpeurs eux-memes.

Un autre probleme courant est l’absence de definition of done ou son non-respect. La definition of done sont des criteres generaux qu’une tache doit remplir pour etre fermee. Par exemple : avoir une code review faite par 2 personnes, avoir ajoute/modifie de nouveaux unit tests, et avoir merge les branches de code dans la branche d’integration. De mon experience personnelle, la definition of done est quelque chose qui doit venir des developpeurs. Il est important qu’au moins un developpeur de l’equipe (idealement plus) comprenne le besoin et la valeur qu’elle apporte. Si la definition of done est definie par le manager, mais qu’au sein de l’equipe il n’y a pas de conviction de sa valeur, il est fort probable qu’a la premiere occasion elle sera ignoree et tombera en desuetude.

Parmi les ceremonies que le framework prescrit, l’une des plus longues est le Sprint Planning, qui vise a ce que l’equipe examine les user stories priorisees par le product owner, les estime et les attribue jusqu’a completer sa capacite pour ce Sprint. Sans aucun doute, la tache la plus longue est l’estimation des user stories, ou l’equipe entiere discute de la facon de decomposer la story en sous-taches et des aspects techniques et d’implementation sont discutes pour ensuite estimer en story points. Parfois j’ai vu comment une seule user story a pris une heure a estimer. Dans une equipe de 8 personnes, c’est 8 heures juste pour estimer une story. Il est vrai que l’exercice d’estimer meticulement en equipe permet de commencer a concevoir comment la story sera implementee et avoir l’avis de plusieurs personnes fournit de nouveaux points de vue et permet d’anticiper des problemes et des problemes potentiels, mais de mon point de vue, c’est trop couteux. Sans parler du fait que souvent seules 2 ou 3 personnes participent, tandis que le reste reste silencieux et souvent se deconnecte, ce qui demotive generalement.

A mon avis, Scrum peut etre un framework interessant a considerer dans les equipes qui commencent a developper un nouveau projet/produit et n’ont pas deja une facon de travailler efficace. Mais des le depart, il faut definir des pratiques techniques que l’equipe entiere comprend et suit, en etant tres conscient que la dette technique sera toujours a l’affut. Je mettrais egalement un accent particulier sur la visualisation du flux de travail, en utilisant un tableau Kanban (de preference physique et sinon, Jira incorpore deja un tableau dans les projets Scrum aussi), pour savoir minute par minute comment le travail avance et detecter les blocages des qu’ils se produisent. Et si la productivite n’est pas celle attendue ou decline au fil du temps, j’envisagerais d’introduire davantage d’elements Kanban et Scrumban.

Kanban

C’est une methode lean pour l’amelioration des processus de travail basee sur le Systeme de Production Toyota. Elle est souvent mal comprise et est entendue comme une methode d’organisation du travail, laissant de cote precisement son essence, qui est la partie amelioration des processus.

Elle est basee sur les idees du Lean Manufacturing qui preconisent de produire en juste-a-temps et de reduire le gaspillage. La surproduction et les defauts sont consideres comme du gaspillage. Pour eviter la surproduction, le travail en cours est limite dans les differentes etapes du processus, en les ajustant pour s’assurer que l’etape la plus couteuse fonctionne toujours a capacite maximale, atteignant ainsi une productivite maximale (c’est base sur la Theorie des Contraintes). Pour assurer la qualite, des processus de validation et de controle qualite sont inclus dans le processus productif lui-meme. Dans le cas de Toyota, tout operateur de la chaine de production etait autorise a arreter la production s’il detectait un probleme, ce qui representait un changement radical dans la facon dont les usines fonctionnaient et une autonomisation des travailleurs.

Contrairement a Scrum, qui est tres prescriptif, Kanban est assez minimaliste et ne prescrit que quelques pratiques, laissant la flexibilite a chaque equipe de trouver sa facon optimale de travailler dans son contexte. Parmi ses principales pratiques : utiliser un tableau pour visualiser le travail, avec des colonnes pour representer les etapes qu’une tache traverse et avec des limites explicites de travail en cours (WIP) pour chaque etape. Il est recommande que le tableau soit physique ; de nos jours c’est difficile… mais si l’equipe est physiquement au meme endroit, je pense que c’est interessant car cela cree un espace de rencontre et de socialisation, ou l’on peut voir le flux de travail et en discuter, ce qui avec un tableau virtuel n’est pas la meme chose. Bien que s’il n’y a pas le choix, on peut le faire aussi.

Les implementations incompletes de Kanban sont courantes, comme utiliser un tableau pour organiser le travail mais sans definir de limites WIP ou sans definir explicitement les politiques de validation pour les differentes etapes. Certains des outils disponibles sur le marche, comme Jira, n’aident pas, puisque par defaut les limites WIP ne sont pas etablies lors de la creation d’un nouveau projet Kanban (il faut le faire via la configuration). Cela empeche d’obtenir la veritable valeur de l’outil pour detecter les goulots d’etranglement et ameliorer le processus.

Ci-dessous, je partage un exemple de tableau pour une entreprise de photographie que j’ai aidee a implementer Kanban. Les cartes superieures sont les politiques du processus, qui sont explicites, permettant a toute l’equipe de suivre le processus sans avoir a se fier a la memoire. Cela permet egalement aux nouvelles personnes de connaitre le processus et tout est sur le tableau.

Exemple de tableau Kanban. Utilise dans une entreprise de photographie

L’idee principale de Kanban est de visualiser le travail et de limiter le travail en cours avec l’objectif de detecter les problemes et les blocages des qu’ils se produisent, d’analyser les causes profondes et de les resoudre. Et repeter, pour ameliorer le processus de maniere iterative.

Contrairement a Scrum qui est un systeme push ou les taches sont “poussees” dans le Sprint Backlog et assignees a un membre de l’equipe pendant le Sprint planning, Kanban est un systeme pull ou les taches sont dans le backlog non assignees et l’equipe les prend au fur et a mesure qu’elle a de la capacite et toujours en respectant les limites WIP. Cela permet egalement de liberer le manager de l’obligation d’assigner des taches a chaque personne. Dans le cas de l’entreprise de photographie que j’ai mentionnee precedemment, le manager m’a dit qu’il n’a plus besoin d’aller poste par poste distribuer les taches, mais les membres de l’equipe vont au tableau et prennent les taches quand elles sont disponibles. C’est l’idee de Kanban : “Gerez le flux de travail, pas les travailleurs.”

La conception que c’est une methode uniquement pour les equipes d’operations et de maintenance ne correspond pas a la realite. Par exemple, chez Microsoft, ils ont plusieurs equipes de developpement de produits comme Xbox et Windows qui travaillent avec Kanban. Beaucoup de ces equipes font la transition depuis Scrum parce qu’elles voient comment l’exces de ceremonies du framework provoque un declin de la productivite (comme Eric Brechner le raconte dans son livre, voir references).

Scrumban

C’est le plus recent de tous et peut-etre le moins connu. C’est un hybride entre Scrum et Kanban, combinant l’accent de Scrum sur la gestion de projet et la livraison de produit avec le systeme pull de Kanban, la visualisation du flux de travail et l’amelioration des processus.

Les ceremonies et pratiques sont principalement celles de Scrum, mais en utilisant le tableau Kanban ou les etapes du flux de travail, les limites WIP et les politiques pour valider et faire transiter les taches entre les etapes sont definies.

Un autre changement important par rapport a Scrum concerne la facon de faire la planification : en Scrum, les user stories sont estimees individuellement (normalement en story points), la capacite de l’equipe pour le Sprint est calculee et celles-ci sont assignees aux membres de l’equipe jusqu’a ce que la capacite soit remplie. En Scrumban, cependant, il n’est pas necessaire d’estimer toutes les taches, il suffit de faire un calcul approximatif de la taille moyenne des taches et d’utiliser le nombre de taches terminees lors des Sprints precedents pour remplir le backlog. C’est une difference substantielle puisque l’estimation des user stories est une tache assez couteuse et fastidieuse dans les equipes Scrum (ceux qui les ont vecues savent de quoi je parle). Une autre difference est que dans Scrumban, la planification se fait a la demande quand le backlog se vide, contrairement a Scrum ou celles-ci sont fixes dans le temps, et souvent sont realisees quand il reste encore beaucoup de taches ouvertes du Sprint precedent.

La seule experience que j’ai de travail avec Scrumban a ete courte et dans une equipe qui l’a adopte pour rendre les Sprints plus flexibles et celebrer les ceremonies Scrum a la demande, avec l’objectif d’eviter de faire la planification avec beaucoup de travail en cours. Le probleme est que nous n’avons pas adopte le tableau Kanban ni par consequent defini de limites WIP, donc nous n’avons pas vu d’amelioration significative de la productivite. C’est parce que nous avons fait la transition vers Scrumban a un moment ou nous etions submerges de travail et voulions supprimer les barrieres de Scrum, mais nous avons manque de nous arreter un peu pour comprendre Scrumban et l’implementer correctement.

Selon l’introducteur de Scrumban (Corey Ladas), c’est un framework de transition et les equipes qui l’adoptent correctement verront au fil du temps comment beaucoup des idees de Scrum ne sont plus utiles et peuvent transcender le framework, en gardant le systeme pull de Kanban.

Personnellement, maintenant que je comprends le concept, et que j’ai vu Kanban fonctionner, si je devais choisir un framework pour une nouvelle equipe de developpement qui doit commencer un projet, je pencherais probablement vers Scrumban. Je pense qu’il reunit le meilleur des deux mondes : Scrum et Kanban. En plus de rendre plus flexibles certains des aspects les plus fastidieux de Scrum, comme les estimations et la planification. Et en donnant a l’equipe la liberte de definir sa propre facon de travailler.

Conclusions TL;DR

Dans cet article, j’ai essaye de revoir certaines des idees du mouvement agile et ses manifestations dans les frameworks et methodologies. Bien sur, il ne couvre pas toutes les idees ou concepts, mais j’ai essaye de faire en sorte qu’il serve de point de depart pour revisiter les outils disponibles afin d’analyser et d’affiner la facon dont nous les utilisons dans les entreprises et equipes avec lesquelles nous travaillons.

Voici quelques-uns des points que je considere les plus importants :

Adopter une methodologie agile necessite non seulement un changement d’habitudes mais aussi un changement de culture et de mentalite au niveau de l’equipe mais aussi au niveau organisationnel. Relire les principes du manifeste agile peut toujours etre un bon point de depart.
Il est tres courant de trouver des implementations incompletes de methodologies agiles qui reduisent leur efficacite, principalement parce qu’elles ne sont pas completement connues, et souvent des pratiques et principes fondamentaux sont elimines ou mal interpretes.
Changer de methodologie de travail en plein milieu d’un projet peut etre delicat car tout grand changement de processus necessite une marge d’adaptation et une periode de grace ou la productivite peut temporairement decliner. Si nous le faisons dans un projet qui accumule deja des retards, il est facile de tomber dans le piege de n’implementer que la partie de la methodologie qui n’impacte pas la productivite immediate.
Les formations et certifications sur les outils agiles peuvent aider a se familiariser avec les frameworks et methodologies. Mais internaliser une nouvelle philosophie de travail et changer de mentalite est un processus plus lent qui necessite de la pratique, de la reflexion et une re-etude.
Extreme Programming va au-dela d’etre une methodologie et est mieux defini comme une philosophie pour les programmeurs, les guidant sur la facon d’etre de bons professionnels, de s’organiser en equipes saines et de livrer de la valeur aux clients de maniere continue. Bien qu’il semble ne plus etre beaucoup utilise actuellement, il reste une excellente source pour complementer d’autres frameworks.
Alors que XP prescrit de multiples pratiques techniques, Scrum, Kanban et Scrumban ne le font pas. Mais s’il y a quelque chose de cle, quel que soit l’outil que nous selectionnons, c’est que nous devons avoir des valeurs, principes et pratiques techniques bien definis car c’est la seule facon de developper un logiciel de qualite.
Kanban n’est pas une facon d’organiser le travail ; c’est une facon de visualiser et d’ameliorer comment nous travaillons. Cela necessite une evaluation et une adaptation continues de notre facon de travailler. Le resultat de Kanban est un processus de travail affine et adapte a notre equipe.
Parfois les outils et plateformes disponibles peuvent nous conduire a des implementations erronees ou incompletes. Par exemple, dans Jira, les limites WIP (travail en cours) ne sont pas definies lors de la creation d’un projet Kanban mais doivent etre definies plus tard via la configuration. Par consequent, il est important de connaitre les methodologies avant de les implementer.
Le tableau Kanban est le lieu ou le flux de travail est visualise et ou les travailleurs vont chercher des taches. Le manager n’a plus a assigner lui-meme les taches. Le flux de travail est gere, pas les travailleurs.
Scrumban combine la facon de travailler en iterations de Scrum avec l’amelioration des processus de Kanban. Et il rend plus flexibles la duree des iterations et l’estimation des user stories, entre autres choses. En plus de donner plus de liberte que Scrum pour que l’equipe definisse sa propre facon de travailler.

En note finale, les methodologies et outils agiles, comme tout autre outil cree par des humains, ne sont pas parfaits et ont leurs limitations que nous experimentons en les appliquant dans le monde reel. C’est dans ces situations que le bon sens et le retour aux valeurs et principes agiles peuvent nous permettre de continuer a avancer. Et nous ne devons jamais oublier qu’ils sont des outils qui doivent servir les personnes et non l’inverse. Le manifeste agile le disait deja : nous valorisons “les individus et les interactions plutot que les processus et les outils.”

References

Agile Manifesto

Scrum Guide

Scrum.org

The Essence of Agile Software Development — Martin Fowler Web

Clean Agile Book — Rob. C. Martin

Extreme Programming Explained. Second Edition Book — Kent Beck & Cynthia Andres

Agile Alliance Article on Scrumban — Corey Ladas

Scrumban Book — Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean) — Corey Ladas

What is Scrumban? Book — Andrew Stellman

Free Kanban and Scrum Book — Making the most of both — Henrik Kniberg & Mattias Skarin

Agile Project Management with Kanban Book — Eric Brechner

Agile Project Management with Kanban Video — Eric Brechner at Google