Scrumban : la fusion de Scrum et Kanban, vers une amélioration continue

Scrumban supports both “revolution” and “evolution.”
Ajay Reddy, The Scrumban [R]Evolution: getting the most out of Agile, Scrum, and Lean Kanban

Scrumban est un système Agile hybride. Scrumban, c’est la fusion des frameworks Scrum et Kanban.
Une équipe agile qui opte pour cet hybride cherchera à améliorer sa capacité de travail, sa productivité ou la qualité de celle-ci par le biais d'une adaptation de la méthodologie qu'elle pratique.

Pour mieux comprendre comment se compose cette hybridation, un précédent article s'intéresse à l'historique de ces systèmes et explique leurs principaux aspects. Le présent article est plus spécifiquement consacré à Scrumban en tant que tel, à l'intégration de chacune de ses parties et aux implications issues de sa mise en place dans une organisation.

…De Scrum et Kanban

Comme nous avons pu le voir dans le précédent article, Scrum et Kanban ont des points communs, mais aussi des différences… ou plutôt des divergences dans leurs mises en application. En effet, si le but reste principalement le même pour tout framework, méthodologie ou approche de développement — qu'il soit informatique ou non —, il n'y a néanmoins pas de voie royale. Plus d'une façon d'y arriver existent et le fait que ces méthodes évoluent, grâce à la maîtrise de leur pratique, en est la preuve.

Différences

Malgré des similitudes, dont certaines ont été rapportées ci-avant, il existe bien des différences entre les composants de Scrumban qui méritent d'être listées. Beaucoup d'articles et de reviews comparent, de façon plus ou moins détaillée, Scrum et Kanban afin de montrer dans quelles situations leurs potentiels peuvent être pleinement exploités. Ainsi, en reprenant l'avis de Lena Boiser lorsqu'elle conclut, dans sa comparaison des deux frameworks, l'important est de savoir dans quel contexte le choix du framework se fera : meilleure est la connaissance de ce contexte, au niveau business, de l'équipe, de la production ou encore des divers obstacles, meilleure en seront les possibilités d'exploitation d'un framework bien choisi.

Scrumban n'est pas simplement la solution tampon entre deux systèmes qui permettrait d'asseoir une équipe dans un certains confort. Ce doit être un choix délibéré de l'équipe de développement et basé sur une pratique de Scrum et/ou Kanban qui permet de mieux apprécier dans quelles mesures ces différences apportent une complémentarité. Le tableau suivant donne un aperçu des principaux aspects les plus connus de Scrum et Kanban en terme de différences :

Il est important de garder à l'esprit, lorsque vous parcourez ce tableau, que les éléments sans prescription spécifiques ne sont pas écartés d'un framework. En l'occurrence, ce n'est pas parce que Kanban ne prescrit aucun évènement particulier durant les phases de développement qu'une équipe ne peut pas en décider autrement. Dans son cadre, il laisse à l'équipe le soin de mettre en place des évènements, et c'est aussi à l'équipe d'en juger la pertinence vis-à-vis du workflow.

Bâti sur des frameworks qui embrassent des principes et valeurs communs d'Agile, Scrumban profite aussi de leurs différences en exploitant la souplesse de Kanban, ainsi que de la complémentarité qu'il puisse y avoir avec Scrum. Ces deux composants encouragent les équipes à œuvrer pour mener en continue l'amélioration et le flux de délivrables(" both encourage teams to work towards continuous improvement and delivery").

De Scrum à Kanban et vice-versa

Dans son article, Dimitri Ponomareff part du principe qu'il n'y a pas de définition "officielle" de Scrumban et qu'elle n'aurait pas son utilité. Il discute plutôt des possibilités, pour une équipe de développement, d'intégrer les pratiques d'une méthodologie dans leur cadre de travail. Pour cette raison, il explore deux chemins :

•  — l'intégration, pour une équipe Scrum, du système Kanban pour de le développement
•  — une équipe Kanban, qui a déjà une pratique de Scrum, décide de profiter des concepts de celui-ci.

Dans le premier cas, lorsqu'une équipe intègre Kanban dans son cadre Scrum, plusieurs modifications structurelles sont à entreprendre. Il faut ici se rappeler que les principes de base de Kanban et surtout le premier : "Faites ce que vous savez faire". De ce fait, une équipe qui sait travailler efficacement avec Scrum comme framework principal doit absolument continuer à appliquer Scrum. Les similitudes qu'il entretient avec Kanban, telles que le tableau de planification de sprint (s'approchant d'une visualisation du flux de travail) ou la rétrospective du sprint (où l'équipe entière s'implique dans l'amélioration continue du processus de travail), aideront à parfaire l'intégration. Ponomareff détaille les perspectives d'intégration pour chacun des principes de Kanban. Il met aussi en avant la transparence, ainsi que les mécanismes de régulation et d'autogestion de Scrum comme participant à la mise en place de Kanban en son sein.
Le second cas laisse entrevoir un des points importants de la conclusion de Ponomareff et sur lequel plusieurs auteurs s'accordent aussi : la maîtrise des pratiques. En effet, si une hybridation telle que Scrumban peut fournir le meilleur de ses composants, c'est en grande partie grâce à la maîtrise qu'une équipe peut avoir de ceux-ci. L'auteur, en détaillant les modifications structurelles qu'implique l'adoption de Scrum, explique en quoi une équipe Kanban éprouvée verra ces modifications comme de simples étapes d'amélioration. C'est, ici aussi, un des principes de Kanban : "allez vers une adaptation mutuelle".

Mesures

Une divergence notable de Scrum et Kanban se retrouve dans les métriques utilisées pour mesurer les performances. D'une part, Scrum, par le biais de ses sprints, se fonde sur un découpage temporel prédéfini pour focaliser le développement incrémentiel d'un produit. D'autre part, presqu'à l'opposé, Kanban cherche à concentrer l'effort de développement sur un nombre préétabli de tâches. On comprend dès lors que les indicateurs de performance principaux (souvent appelés KPI pour Key Performance Indicators) puissent ne pas correspondre d'un système à l'autre, ou paraître difficiles à interpréter et à adapter en dehors de leur framework respectif. Une question légitime serait alors de savoir si la mesure de ces indicateurs pourra encore être interprétée de la même façon avec Scrumban. En d'autres termes, si la vélocité de Scrum représente bien le nombre de stories achevées durant un sprint, par exemple, son interprétation dans Scrumban reste-elle identique, sachant que les sprints intégreront la limite du WIP?

La réponse dépend grandement de la façon dont Scrumban a été mis en place ainsi que des connaissances qu'une équipe possède de ses composants. En effet, comme le relève Claude Aubry dans son guide sur Scrum, les indicateurs de Kanban peuvent sembler plus ou moins pertinents. Par exemple, dans le contexte de Scrum, le lead time (indicateur Kanban défini par la durée complète pour produire un délivrable) "n'aurait un sens que pour des features, à condition qu'on les déploie une fois finies". Ces features, des fonctions ou services réalisés durant les releases, sont peu nombreuses et cela fait donc douter Aubry sur leur pertinence en tant que KPI dans un framework hybride. A contrario, l'introduction du burndown chart de Scrum dans le framework Kanban peut porter à faux. Une équipe peu mature pourrait effectivement se contenter de relever arbitrairement la limitation sur le WIP pour diminuer le burndown sans pour autant en chercher la ou les réelles causes.

Un indicateur permet de renforcer, ou pas, la confiance dans la tenue d'un objectif de sprint ou de release.

Ces exemples simples montrent à quel point la bonne connaissance des pratiques de chaque composant de Scrumban est essentielle et doit accompagner la connaissance métier et technique du domaine. Elles permettent, réunies à ce niveau, d'obtenir les mesures de performances d'une équipe en s'appuyant sur les indicateurs adéquats. Au-delà d'influencer uniquement le développement, les mesures des KPI ont un effet sur l'équipe elle-même, ce qui, au final, aura un impact sur le développement aussi.

Shu Ha Ri : la rigueur de l'apprentissage

Le Shuhari, du japonais 守破離 (Hiragana: しゅはり) peut être interprété comme :

•  守 (Shu) : obéir, respecter ou encore protéger
•  破 (Ha) : se détacher, s'écarter ou encore digresser
•  離 (Ri) : quitter ou partir

Bien que l'origine de ce terme soit souvent ramenée aux arts martiaux, il est important de comprendre que c'est surtout l'apprentissage qui est le sujet de ce modèle. La culture japonaise est connue pour l'appliquer avec une rigueur toute particulière dans divers domaines, tels que le théâtre (Nō, un style de théâtre traditionnel japonais), la cérémonie du thé (ou voie du thé, chadō), les métiers artisanaux, etc.

La première phase, le Shu, est emprunte de respect et d'obéissance. Une équipe de développement aura soin, lors de cette phase, de ne pas sortir des sentiers battus. Il est important de respecter et appliquer les frameworks, quels qu'ils soient, à la lettre. C'est lors de la deuxième phase, le Ha, que l'on acquiert une maîtrise qui permet de "prendre des initiatives dont comprend les impacts et qui ne modifient pas l'objectif final [...]"; l'équipe sait faire des écarts qui restent toujours dans le framework initial. Pour finir, comme il l'a été évoqué précédemment, c'est lorsqu'une équipe arrive à la maîtrise de son framework, dans la phase Ri, qu'elle peut sereinement envisager de l'adapter pour en améliorer tout ou partie. C'est à ce moment que l'équipe peut et doit continuer à s'améliorer en puisant à l'extérieur du framework.

Nombre d'auteurs insistent sur le fait que Scrumban, issu de l'intégration de Kanban dans Scrum ou l'inverse, doit être appliqué dans cet état d'esprit.

Conclusion

Choisir d'appliquer Scrumban revient en réalité à choisir parmi différents frameworks, méthodologies et méthodes de développement celui ou celle qui sera le plus en adéquation avec l'esprit de l'équipe, ainsi qu'avec les résultats escomptés — que ce soit en termes de production, de workflow ou autre.

En résumé

Après un bref rappel sur Scrum et Kanban, les composants de Scrumban, les premiers éléments mis en évidence ont été leurs différences. Bien que cela ait pu montrer Kanban comme un peu plus facile et léger à mettre en place en tant que méthodologie de travail, il n'en reste pas moins que le point important de cette comparaison est leur complémentarité. C'est une des raisons pour lesquelles Scrumban est souvent décrit comme une "évolution" d'un de ces composants vers l'autre. Dans cet article, le terme d'intégration lui sera toutefois préféré. Elle est d'ailleurs discutée dans une deuxième phase de la présentation où la mise en place de Scrumban est vue lors de l'intégration de Kanban par Scrum et vice-versa. Il en ressort la nécessité, pour une équipe, d'avoir une connaissance approfondie du contexte (métier, technique, etc.) dans lequel elle veut entamer cette "hybridation". La dernière phase, qui pointe les mesures de performances dans Scrumban, fait le constat du rapport très étroit entre le choix d'indicateurs de performance (KPI) et le contexte d'application de Scrumban. Afin de garantir la pertinence de ces mesures, une équipe doit savoir choisir et interpréter judicieusement ces indicateurs.

La dernière partie, le ShuHaRi, n'est pas un élément à proprement parlé de Scrumban. C'est un modèle d'apprentissage qui prône une recherche constante de l'amélioration à tous les niveaux et s'applique particulièrement bien aux visions de Scrum et Kanban… et, donc, Scrumban. Il se divise en trois parties où l'apprenti suit respectueusement les règles, au début, pour s'émanciper, par la suite, et, à terme, maîtriser. C'est le maître-mot : maîtriser.

Continuer à apprendre

Il n'est généralement pas recommandé d'appliquer Scrum ou Kanban à moitié. De la même façon, biaiser ces frameworks avant de savoir exactement quels impacts cela pourrait avoir n'est pas une bonne idée. Scrumban, de facto, n'y échappe pas. Contrairement à ce que nous pourrions penser, ce n'est pas une passerelle entre Scrum et Kanban qui permet de réajuster le développement en cas de problème. Scrumban pousse une équipe vers la maîtrise, au minimum, de son framework de départ et, au mieux, des deux. Pour une équipe qui serait dans sa phase "Shu", par exemple, le framework fournira la structure et la vision qu'elle devra suivre pour y arriver.

This is why it's hard to come up with a maturity model when using agile
methodologies. Because of this continuous improvement focus, you can never
say you are at the top.

Toute la beauté du modèle ShuHaRi, c'est que la phase d'apprentissage la plus longue, n'est autre que le Ri. En effet, c'est lors de cette phase que l'apprenti devenu maître peut se rendre compte qu'il est dans une phase d'apprentissage sans limite. Sa maîtrise lui permet de continuellement réapprendre en intégrant de nouveaux éléments. Scrumban supporte cette vision grâce, entre autres, à ses composants dont la recherche d'amélioration, que ce soit dans la façon de travailler, dans la qualité de la production ou encore dans les liens collaboratifs, est un engagement pris par l'équipe développement.

Scrumban supports both "revolution" and "evolution". More importantly,
it’s structured in a way that strongly supports all levels of learning and
understanding — at a level of quality that is greater than that provided by
either Scrum or Kanban alone.

Lectures complémentaires :

Scrum : valoriser l’équipe pour améliorer le développement par Thierry Sorg

Using Scrum in Digital Communication by Adeleh Mojtahed

1. Corey Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development, Lulu.com, 2008, ISBN-13: 978-0578002149
2. K. Schwaber and J. Sutherland, The Scrum Guide, scrumguides.org, 11.2017
3. Claude Aubry, Scrum: Le guide pratique de la méthode agile la plus populaire, 4^èmeéd., Dunod, 2015, ISBN-13: 978-2100742165
   [RET]
4. Manifesto for Agile Software Development, agilemanifesto.org, 11-13.02.2001
5. H. Takeuchi and I. Nonaka, The new new product development game, Harvard Bussiness Review, Jan-Feb 1986
6. Thierry SORG, Scrum: valoriser l’équipe pour améliorer le développement, gbnews.ch, 09.2020
7. Scrum.org,
8. Dimitri Ponomareff, Scrumban — Blending Agile, Scrum and Kanban into a methodology that works for you, kanbanzone.com, 21.09.2017
   [RET]
9. Ajay Reddy, The Scrumban [R]Evolution: getting the most out of Agile, Scrum, and Lean Kanban, Agile Software Development Series, Addison-Wesley, 07.2015, ISBN-13:978-0134086217
10. Thierry SORG, GBN Talk 4: Kanban, gestion des workflows et amélioration continue — p.2, gbnews.ch, 07.2019
    [RET]
11. Thierry SORG, GBN Talk 4: Kanban, gestion des workflows et amélioration continue — p.1, gbnews.ch, 07.2019
12. Lena Boiser, Kanban vs Scrum, kanbanzone.com, 28.02.2019
    [RET]
13. Alex Novkov, Kanban and Scrum: What You Need to Know, kanbanize.com, 04.06.2019
14. Françoise Baroffio, GBN Talk 4: la méthode Kanban présentée par Robert Falkowitz, gbnews.ch, 07.2019
15. GBN Talk 4: an interview with Robert Falkowitz, gbnews.ch, 07.2019
16. Florian Ivan, Becoming agile with ShuHaRi, article présenté au PMI® Global Congress 2015 — EMEA, London, England. Newton Square, PA: Project Management Institute
17. Nikita Murashko, Agile + Scrumban For Better Productivity: How to Create a Hybrid Software Development Process, hackernoon.com, 03.12.2018
18. Scrum vs. Kanban vs. Scrumban: Planning, Estimation, and Performance Metrics, eylean.com, 02.05.2013
19. Scrum vs. Kanban vs. Scrumban: Iterations, Work Routines, and Scope Limits, eylean.com, 22.04.2013
20. Kanban Software Development, kanbantool.com,
21. Wikipedia: Lean thinking, wekipedia.org,
22. David J. Anderson et Teodora Bozheva, Kanban Maturity Model: Evolving Fit-For-Purpose Organizations, Lean Kanban University Press, 2018, ISBN-13: 978-0985305154
23. David J. Anderson et Andy Carmichael, Essential Kanban Condensed, Lean Kanban University Press, 2016, série: Essential Kanban, vol: 2, ISBN-13: 978-0984521425
24. Kanbanizing the Kanban Maturity Model, kanbanize.com,
25. Kanban and Scrum Software: Detailed Comparison, kanbanize.com,