Scrum et Kanban revisités

Mise à jour: Voir le webinar du 30 Août de Steve Porter et Dan Vacanti intitulé Scrum and Kanban: Make your teams better by busting common myths [scrum.org]. Il est excellent de voir une telle collaboration, et je suis heureux de reconnaître qu’ils sont la source originale des 6 intitulés ci-dessous (pas le contenu – qui reste le mien). Mes excuses à Steve et Dan – erreur involontaire, j’aurais dû creuser un peu plus.

Tard la semaine dernière, j’étais invité par Fasih Sandhu à partager mes réactions à un post LindedIn au sujet de Scrum et Kanban. Ma réaction initiale était « Oh, c’est reparti, 2012 nous voilà », mais j’ai fini par laisser un commentaire suffisamment long que j’ai dû l’éditer pour le faire rentrer. Voici une version du réalisateur ! Je ne suppose pas que cela va résoudre les problématiques une fois pour toute, mais cela donne au moins l’opportunité d’expliquer comment quelqu’un qui s’est engagé dans une integration réfléchie approche le sujet.

Penses-tu que combiner les principes #Kanban aux pratiques du Framework #Scrum améliorera la collaboration dans tes équipes agiles ?

L’espace ne m’a pas permis d’adresser cette question sur LinkedIn, mais s’il n’y a avait pas eu « améliorer la collaboration dans tes équipes agiles » dans la phrase, je ne m’y serais probablement pas engagé du tout.

Pour comprendre pourquoi cette phrase était si cruciale, voici le True North [1] d’Agendashift :

Tout le monde capable de travailler continuellement de son mieux : 
 • Les individus, les équipes, entre équipes, dans toute l’organisation
 • Les bonnes conversations, les bonnes personnes, au meilleur moment possible
 • Les besoins anticipés, satisfaits juste au bon moment

Je suis intéressé à améliorer la collaboration non seulement dans les équipes agiles (comme dans la question), mais entre les équipes (de tout genre) et dans toute l’organisation – les bonnes conversations survenant entre les bonnes personnes au meilleur moment possible, où que ce soit dans l’organisation ou en dehors si besoin. Est-ce que je crois qu’une combinaison de Scrum et Kanban peut aider à produire cela ? Oui je le crois, et je peux pointer de nombreux projets où j’ai pu en être témoin.

Dans une semaine environ, je participerais à un événement sur #Scrum versus #Kanban et je serais intéressé par la réaction de mes followers LinkedIn aux affirmations qui y seront discutées :

1) Scrum est pour les équipes « produit »; Kanban est pour les équipes « services »
2) Scrum est pour du travail complexe; Kanban pour du travail simple
3) Notre équipe Scrum a évolué pour devenir une équipe Kanban
4) On fait du Scrumban
5) On fait du Kanban parce qu’on ne peut pas planifier un Sprint complet
6) Scrum est révolutionnaire; Kanban est évolutionnaire

Oh mon dieu. “Scrum versus Kanban”. On retourne en 2012. Passons:

1) Scrum est pour les équipes « produit »; Kanban est pour les équipes « services »

Réaction rapide: Ugh. Propagande (au mieux basée sur une erreur de logique, au pire un mensonge basé sur une mauvaise orientation).

Une réponse plus longue, expliquant la phrase ci-dessus, mais menant à une conclusion bien moins controversée :

Oui, Scrum est, par conception, pour les équipes « produit ». Scrum.org le décrit comme « un processus de gestion et de contrôle qui réduit la complexité pour se focaliser sur la construction de produits répondant aux besoins business ». Pas de débat ici, et dans ce contexte, cela est bien compris et bien documenté. Pour certains, c’est le framework de choix, pour d’autres un bon point de départ ou quelque chose que l’on doit connaître.

Est-ce que Scrum est conçu pour les équipes « services » ? Pas vraiment. Est-ce que Kanban peut aider dans ce cas ? En d’autres termes, est-ce que les équipes « services » peuvent bénéficier du management visuel Kanban, du contrôle sur le travail en cours, de l’amélioration collaborative pilotée par le feedback du processus, etc, etc ? Beaucoup le peuvent et beaucoup en bénéficient !

Ce qui est également vrai (et c’est ce qui rend cette affirmation si frustrante) est que le management visuel, le contrôle sur le travail en cours, l’amélioration collaborative pilotée par le feedback du processus… sont aussi très utiles pour les équipes « produit », qu’ils utilisent Scrum ou non.

Alors… Kanban n’est pas que pour les équipes « services », et Scrum et Kanban ne sont pas mutuellement exclusifs. Ennuyant, mais vrai ! Et vos équipes « produit » peuvent-elles se permettre d’ignorer la dimension service de toute façon ? Probablement pas, et certains commenceraient même d’ailleurs par là…

2) Scrum est pour du travail complexe; Kanban pour du travail simple

Réaction rapide : Double ugh. Comme la question 1, mais avec une dose d’Appel à autorité dedans.

Je pourrais donner une réponse étendue ici, mais il suffit de dire que si vous ne comprenez pas ce que Scrum et Kanban recherchent tous les deux – à leur manière, à la fois techniquement et philosophiquement – pour aider leurs organisations (non pas juste leurs produits) à évoluer en présence de frictions internes et de pression compétitive externe, alors vous ne les comprenez pas bien du tout, ni Agile, Lean ou Lean-Agile d’ailleurs.

3) Notre équipe Scrum a évolué pour devenir une équipe Kanban

Des réactions positives, négatives, ou mixtes pourraient être appropriées ici – il est difficile de commenter celui ci sans connaître les spécificités du scénario.

Malheureusement, une affirmation comme celle ci peut signifier un grand nombre de choses, de « On a arrêté de faire un paquet de trucs liés à Scrum et on ne sait pas vraiment ce que l’on fait » à « On utilise à présent un certain nombre de nouvelles techniques en quête du flux, laissant derrière nous de vieilles pratiques une fois que l’on ait établi que cela était sûr et efficace dans ce sens ».

Technicité mineure : Par la conception des deux, une « équipe Kanban » n’est pas aussi bien définie qu’une « équipe Scrum ».

4) On fait du Scrumban

Comme documenté [2, 3, et autre part], mon expérience de Scrumban a été très positive.

Pour célébrer la partie Scrum, les équipes avec lesquelles j’ai travaillé ont beaucoup apprécié la focalisation du sprint dans les premiers jours de chaque projet; pour les organisations non habituées à produire des choses rapidement, l’expérience peut être incroyable !

Concernant la partie Kanban, cela a grandement aidé dans la quête d’un flux de bout-en-bout (voir ma réponse à la question 3 ci-dessus). Ce n’est pas juste une meilleure gestion des tâches, c’est intégrer un processus qui commence bien avant le développement et qui se termine bien après la livraison en production.

Je suis ravi de pouvoir dire que Scrumban est bien mieux documenté aujourd’hui qu’auparavant; regardez par exemple le livre [4] de mon ami Ajay Reddy et (de la même écurie) quelques outils [5, 6].

5) On fait du Kanban parce qu’on ne peut pas planifier un Sprint complet

Réaction rapide : je trouve difficile de voir cela autrement qu’une piètre excuse.

Chaque équipe est sujette à des sources d’imprévisibilité – en fait la plupart des équipes semble générer une bonne partie des ces éléments elles-mêmes ! Et pourtant, il y a tant de choses qui restent sous votre contrôle :

• La fréquence à laquelle vous planifiez dépend de vous (indice: choisissez une longueur de sprint appropriée)
• Que vous planifiez avec ou sans marge de manoeuvre dépend de vous (indice : prenez de la marge)
• La confiance que vous attachez à vos plans dépend de vous (indice : comprenez que cela est crucial au processus de planification, et que vos choix ici devraient être informés par à la fois la capacité et le besoin)

6) Scrum est révolutionnaire; Kanban est évolutionnaire

Réaction rapide : Il y a du vrai là dedans, exaggéré pour faire son effet, mais pas en soi un jugement de valeur utile.

Scrum est révolutionnaire si vous n’avez rien fait d’autre avant. Avec le temps et vu qu’il y a de plus en plus de choses à son sujet, cela deviendra de moins en moins révolutionnaire, (une victime de son propre succès peut-être). Et n’oubliez pas qu’il a des objectifs évolutionnaires (voir la question 2 ci-dessus).

Kanban est souvent décrit comme le plus simple des deux à introduire, mais essayez de l’introduire dans une organisation allergique à la transparence !

En toute franchise, les discussions autour de ce qui constitue ou non un changement évolutionnaire deviennent rapidement stériles, et dans tous les cas je ne crois pas que ce soit une base sensée pour des décisions sérieuses à propos de l’intégration d’outil (et que vous l’aimiez ou non, toute adoption Agile réussie est une intégration, pas juste une sélection). C’est pourquoi de nos jours, je préfère prendre une approche plus basée sur des principes : Commencez par les besoins, Entendez-vous sur les résultats, et ainsi de suite [7, 8].

Références

[1] A True North for Lean-Agile? (See also chapters 1 and 5 of [2])
[2] Agendashift: clean conversations, coherent collaboration, continuous transformation, Mike Burrows (yours truly) (2017, Leanpub)
[3] Kanban from the Inside (2014, Blue Hole Press)
[4] The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Ajay Reddy (2015, Addison-Wesley Professional)
[5] GetScrumban
[6] ScrumDo
[7] Agendashift in 5 principles
[8] (Non-)Prescription, frameworks, and expertise