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]
Limites Scrum

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.

Tickets Kanban

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 !

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 quune 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 :

yes we kanban

10 commentaires pour “Scrum sans itérations ?”

  1. Hum…

    Si je comprends bien, Kanban sert à groomer le Backlog?
    Si Kanban sert à groomer le Backlog, que fait l’équipe? le PO?
    s’il n’y a pas d’équipe ou PO, il n’y a pas de Scrum, non?

    Pour ma part, Scrum ne se réduit pas seulement au développement de logiciels, il s’agit avant tout d’une méthodologie de management participative.

    Adopter les principes de Lean sont très efficaces, mais à utiliser en amont de l’équipe dans la relation avec le Management (Business) afin de définir la Vision et la Roadmap.
    L’approche Lean est excellente, cependant, la réaction au changement, comme décrite dans l’article, est un peu en deçà de la réalité: le rythme (vélocité) dans Lean est un peu plus long que dans Scrum.

    Rappel Scrum:
    - si bug il y a, alors DoD pas défini et rejet par le PO (cf. Kent Beck dans XP)
    - si modif. du Backlog, alors analyse par le PO et réajustement lors du Review.

    Non?

  2. Peux tu préciser ce que signifie « groomer le backlog » ?
    Merci !

  3. Salut Christian,

    Groomer le Backlog:
    - entretenir, nettoyer, vider le fonds fu backlog.
    - Activité principale du PO qui met en place (si possible) 15′ de Grooming Meeting avec l’équipe après chaque Daily Scrum.

    Backlog: Product Backlog & Sprint Backlog.

    Bien à toi

    Pierre

  4. [...] Scrum sans itérations [...]

  5. [...] Scrum sans itérations [...] c’est pas du SCRUM.

    Pourquoi réinventer la roue?

    L’approche Scrum est intéressante et dans le retour d’expérience de Kniberg, je reste toute fois un peu sceptique.

    Je m’explique: il y a une démarche Scrum venant d’XP qui promeut l’abscence de Chef de Projet dans cette démarche.

    Pour ma part, je partage la Vision de Cohn et de Pichler, qui mettent en avant la puissance de l’organisation Scrum: 1 gestionnaire du Process (SM), 1 gestionnaire du Produit (PO). De ce fait, la conduite du projet est partiellement bi-polaire (partiellement car l’équipe est active dans la gestion du projet) et les responsabilités clairement définies: le SM dans sa compétence technique et le PO en tant coordinateur du métier (MOA).
    A l’instar des approches traditionnelles, le PO n’est pas à l’extérieur de l’équipe, mais dans l’équipe. Cela permet à l’équipe de gagner en éfficacité: la modification des stories, l’ajout et le retrait se fait durant les sprints.

    Dans les projets matures, l’approche se fait de cette façon car elle permet de découper le backlog/release plan en différentes parties: scrum de dév., scrum de test, scrum de documentation, etc… (c’est un example) et dans ce cas la direction est prise vers un meta scrum.
    A ce niveau, les PO alignent la Vision globale et gèrent une partie du backlog en mettant davantage l’accent sur les tests de fonctionnalités.

  6. Bonjour,

    J’ai lu avec attention votre article que j’ai trouvé très enthousiaste mais truffé de contre vérités. Une chance qu’à la conclusion vous signalez apprécier XP (du coup je comprends beaucoup mieux).
    Soyons clairs : je suis pro XP, mais surtout Scrum, Lean.
    L’approche Kan Ban dans Scrum est extrêmement bien expliquée dans le livre blanc de Kniberg & Skarin (dispo chez infoQ)…. mais je vais rajouter mon petit grain de sel
    1. Rappel de Scrum
    Artifacts: Backlogs (Product, Sprint), Burndown Charts (Product, Sprint, Release), Impediment List… Vélocité
    Objectif: livrer un produit apportant le maximum de valeur
    Scrum Team: une équipe (Dev, Archi, DBA, Tester, Ergo, etc.…), Scrum Master (Resp. du Process), Product Owner (Resp. du Produit)
    Process :
    a. Le PO définit une Vision avec les « stakeholders » (Business, MOA, Clients, utilisateurs)
    b. Le PO rédige des User Stories (merci XP !) relatives aux exigences des utilisateurs, les prioritisent, et construit un Product Backlog initial
    c. Le PO construit une Roadmap et un Release Plan Initial avec les utilisateurs et élabore une Definition of Ready et les critères d’acceptation des utilisateurs (Definition of Done initiale)
    d. Le PO vient ensuite rencontrer l’équipe et le Scrum Master pour soumettre les exigences des utilisateurs : Sprint Planning
    e. L’équipe analyse les stories sur leur clarté, faisabilité, testabilité (cf. Mike Cohn)
    f. L’équipe estime : Planning Poker (merci XP !)
    g. Le PO discute avec l’équipe sur la Definition of Ready et la Definition of Done du Sprint
    h. Le Sprint se déroule :
    i. Découpage des users stories en tâches (habituellement la DOR convient qu’une story ne doit pas dépasser une journée de développement, et la compréhension de celle-ci ne doit pas dépasser les 30’ : dans la négative, il s’agira d’un IMPEDIMENT et devra être traité par le Scrum Master)
    ii. Daily Scrum
    iii. Revue de Backlog ou de Stories avec le Product Owner (surtout en début de projet)
    i. Fin de Sprint : Sprint Review Meeting : présentation du produit développé lors de l’itération et validation ou non du résultat par le Product Owner conformément à la DOD.
    j. Retrospective : faite par le Scrum Master, point de situation sur le Process Scrum. Calcul de la vélocité.
    k. Le Product Owner prend les informations concernant la vélocité, analyse la taille du backlog, traduit la vélocité en terme de j/h, calcule le temps nécessaire pour livrer le produit, revoit le Release Plan et calcule le ROI.
    l. Le Product Owner fait le reporting aux utilisateurs et au Business en tenant compte de : date prévisionnelle de fin de Scrum (Go Live), valeur crée
    2. Et Kan Ban dans tout çà :
    Kan Ban intervient dans la planification des tâches de l’équipe (Kniberg l’explique mieux que moi).
    En effet, par défaut toutes les tâches du Backlog sont ouvertes sur le tableau de progression. Kan Ban induit une notion de flux, c.à.d. Toutes les tâches sont « ouvertes (par ex.), ensuite chaque membre s’attribue une tâche qu’il doit remplir, si il n’y arrive pas, celle-ci passe dans l’Impediment List et analysée par le SM.
    Donc Kan Ban renforce la notion de rythme dans Scrum afin d’améliorer :
    - La vélocité de l’équipe
    - L’affinage des user stories (par le PO)
    L’objectif derrière ceci est de mettre le SCRUM en mode d’hyper productivité (cf. Sutherland).

  7. Eh bien Pierre, vous me voyez bien désolé de vous avoir asséné autant de contre-vérités ;-) En tout cas, je constate que vous êtes un commentateur assidu de cet article, je suis donc heureux qu’il vous inspire autant.

  8. Bonjour Christian,

    Le débat est dans Scrum… n’est-til pas?

    Je vais être sincère: ce débat était entendu.

    Je m’explique: l’approche Scrum en France est fortement dépendante d’XP (il me semble que la communauté XP en France et très puissante… positivement).
    Faisant partie de la Scrum Alliance, je suis au désespoir de voir si peu de CSPO en France, alors encore moins de CSP, et je crois qu’il n’y a pas de CSP. Désolé pour XP, mais chez nous, nous aimons les certifications ;o))

    Dans XP, on recherche la proximité directe avec le client (validation agile: OK), donc il n’y a pas de projet, etc….

    Scrum est moins souple (et j’accepte moins agile, c’est exact) est repose sur l’équilibre des trois forces l’équipe, le Scrum Master et le Product Owner. L’inexistance de l’une ou l’autre de ces « forces » désorganise le process(petit provoc vs Manifesto). Comme par ex. dans l’Agile Modelling, l’absence du Scrum Master remplacé par l’unique Product Owner crée un déséquilibre.

    Cher ami « jouteur », il serait peut être intéressant de démontrer les aspects Projet de Scrum?

    Sujet à réflexion N° 1: Scrum ne serait-il pas un LEAN (Hoshin Kanri)? avec des itérations plus courtes? une plus grande réactivité au changement? un LEAN pour des projets critiques?

    Cordialement

    Pierre

    N.B. faites donc un petit tour par http://www.systematic.com/, Systematic a utilisé Scrum pour implémenter LEAN (étonnant non?)
    et pour nos amis XP, l’université de Trèves (D) a accompagné un projet de développement de puces électroniques uniquement avec XP!

  9. [...] Scrum sans itérations [...]

  10. [...] Scrum sans itérations [...]

Laissez un commentaire