Préface de Kanban pour l'IT, 1ère partie

Kanban considère le processus courant comme un système

Écritures

La première fois que j’ai parlé de Kanban dans ce blog, c’était en 2008, un billet suite à ma lecture de Scrum-Ban de Corey Ladas. Depuis Kanban a fait son chemin dans l’IT.

On en parle de plus en plus dans les conférences. Sur le terrain, je vois de plus en plus d’équipes qui s’y intéressent.

Maintenant j’aborde régulièrement de Kanban dans mon blog. Les formations, comme celle de sensibilisation à Toulouse la semaine dernière suscitent de l’intérêt.

Le livre de Laurent Morisseau, Kanban pour l’IT, publié en juillet 2012, est devenu la référence pour cette approche.

Et voilà que Laurent me demande d’écrire la préface de sa deuxième édition, à sortir en avril.

J’avais déjà écrit une préface l’an dernier, celle du livre de Thierry Cros, Spécifiez Agile.

Mais pour Kanban pour l’IT l’exercice m’est apparu plus délicat. D’abord parce que c’est David Anderson, le “gourou” du Kanban, qui avait écrit la première préface. Et aussi parce que le positionnement de Kanban reste délicat et sujet à interprétations.

Les discussions avec Laurent m’ont rassuré, nous sommes en phase sur comment situer Kanban. Et comme j’aime de plus en plus ce Kanban là, j’ai pris beaucoup de plaisir à écrire cette préface.

Voici la première partie :

Introduction

Je commence cette préface dans le TER vallée de la Marne, après une journée d’accompagnement à Scrum chez un client. Mon travail a consisté à aider une dizaine de futurs Product Owners ou ScrumMasters à la sélection et l’adaptation des pratiques pour leurs projets. Ils veulent faire du Scrum comme d’autres déjà chez eux.

Aujourd’hui, comme de plus en plus souvent dans mes missions d’accompagnement, j’ai apporté des réponses et orienté vers des pratiques qui sortaient du cadre de Scrum. Elles venaient de Kanban.

Scrum et Kanban

Attention il ne s’agit pas de proposer Kanban comme alternative à Scrum. Non. En fait dans ces situations, Kanban enrichit Scrum. Car, contrairement à une idée répandue, Kanban n’est pas une méthode agile opérationnelle, similaire à Scrum. C’est une méthode d’amélioration de processus, qui peut donc tout à fait s’appliquer en complément à Scrum.

Quand je représente le backlog sous forme de bacs , quand je limite le nombre d’éléments dans un tableau Scrum, quand je compte le nombre d’urgences pendant un sprint, cela reste du Scrum, mais c’est aussi du Kanban. On peut nommer cela du ScrumBan, mais ce qui compte c’est de pouvoir mieux répondre à des problèmes courants.

Amélioration de processus

Kanban considère le processus courant comme un système. L’amélioration consiste à rendre plus efficace ce système kanban, avec des mesures de ses entrées et sorties. Kanban pousse à représenter la façon de travailler, le workflow, mais n’est pas un retour aux gros processus qui pourrait chatouiller les aficionados du Manifeste Agile.

à suivre…

Lire aussi