Série - Préface de Kanban IT, le livre de L.Morisseau

Fil des billets - Fil des commentaires

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

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…

Préface de Kanban pour l'IT, deuxième partie

Cette deuxième partie évoque les approches processus pour montrer en quoi Kanban est différent.


Représentation de processus

Il y a une quinzaine d'années, je m'intéressais de près aux notations, langages, modèles et méta-modèles (UML, SPEM, BPMN) pour représenter les processus.

On retrouve dans Kanban les mêmes notions de rôle, activité et élément de travail, mais avec une approche bien différente :

  • Plutôt que de faire représenter le processus type par des spécialistes et ensuite de le faire exécuter aux personnes sur le terrain, Kanban s’appuie sur ceux qui font le travail pour visualiser la situation actuelle.
  • L’accent est mis sur les choses entrant dans le flux du système et leur transformation, alors que les approches processus sont plutôt centrées sur les activités, en insistant sur les rôles des personnes censées les exécuter[1].
  • La simplicité est de mise pour présenter le processus, généralement sous forme de colonnes pour les activités et des post-it pour les éléments de travail. Cette simplicité est rendue possible par la focalisation vers le workflow de l'élément principal (quitte à avoir un réseau de systèmes kanban pour représenter les autres éléments). Elle est aussi le fruit de plusieurs années d’expérimentation des méthodes agiles.

à suivre, avec l'évolution vers la notion de flux, qui a émergé grâce aux méthodes agiles.

Note

[1] Ce n'est bien sûr pas nouveau de considérer le flux et la transformation successive d'éléments ayant de plus en plus de valeur. Mais dans les processus établis dans les organisations comme dans le processus unifié (ou RUP), il y avait tellement d'artefacts que cette notion de flux de valeur était complètement dissoute dans la complexité de la représentation ou du modèle.

Préface de Kanban pour l'IT, troisième partie

Kanban pour l'IT, le livre de Laurent Morisseau, deuxième édition, troisième partie de la préface.

En remontant le fleuve.


De l'Agilité vers le flux

Les méthodes agiles ont permis une évolution décisive vers la notion de flux.

  • D’abord, en regroupant toutes les entrées d'un processus de développement en un seul artefact, le fameux backlog. La première marche vers le flux est là, avec le backlog en entrée qui se transforme en produit partiel potentiellement livrable, comme dans le schéma Scrum si répandu.
  • La seconde apparaît sous la forme du post-it. En poussant son usage pour identifier une story et la faire évoluer jusqu’à sa réalisation dans le sprint, Scrum et l’agilité ont quelque sorte réifié l’élément de backlog. La story est devenue l’unité de travail naturelle d’un système kanban.
  • Enfin, les livraisons fréquentes, l'intégration continue et maintenant le déploiement continu, ouvrent à une prise en compte de la story jusqu'à ce qu'elle apporte de la valeur aux utilisateurs finaux, complétant l’évolution vers le flux.

Bien sûr, ce n'est pas si simple, chacun a sa façon de transformer une story, en fonction de son contexte.

Bien sûr, la notion de story n'est pas si facile à identifier.

Bien sûr, la story n'est pas toujours à la bonne granularité pour le flux de valeur le plus évident, et il faut s’intéresser aussi aux features (MMF).

C'est pourtant comme cela, avec des tableaux de post-it, que s'est développé Kanban dans le milieu de l'agilité.


à suivre…

Préface de Kanban pour l'IT, quatrième partie

Kanban pour l'IT, le livre de Laurent Morisseau, deuxième édition, suite de la préface (4/6).

Pionniers à Troie


Des pionniers du Kanban, vers la maturité

C'est pourtant comme cela, avec des tableaux de post-it, que s'est développé Kanban dans le milieu de l'agilité.

Les premiers retours d'expérience présentent souvent des énormes tableaux remplis de post-it. Cependant, grâce au travail d'évangélisation de Laurent depuis déjà 2-3 ans, la diffusion de Kanban progresse régulièrement, pas seulement comme tableau, mais comme méthode d'amélioration.

Obstiné comme un breton, opiniâtre et méthodique comme le navigateur de transat qu'il est, Laurent nous propose, avec cette deuxième édition, un Kanban qui a gagné en maturité et qui est prêt maintenant pour prendre toute sa place dans le mouvement agile.

Kanban portfolio comme porte d’entrée

En effet, pour les agilistes, Kanban est un bon point d'entrée, là où Scrum ne perce pas, au niveau du top management et de l'organisation des projets. Ce qu’on nomme le kanban portfolio va constituer à mon avis le cheval de Troie de l'agilité.

Car, si le changement radical imposé par Scrum est toléré pour des équipes projet, les managers et décideurs en restent généralement à une approche classique du projet : il passe par des phases, de durée variable, et doit franchir un jalon pour passer à la phase suivante. Kanban permet de partir de cette situation courante pour aller progressivement vers plus d'agilité.

Que ce soit pour les PME gérant plusieurs affaires de leurs clients (par exemple des agences Web) ou pour des DSI avec leurs nombreux projets dans le portefeuille, Kanban apporte une réponse pragmatique et évolutive qui part de la situation actuelle et cherche à l’améliorer progressivement.


à suivre…

Préface de Kanban pour l'IT, cinquième partie

J'ai écrit la préface de Kanban pour l'IT, le livre de Laurent Morisseau, deuxième édition.

Voici un nouvel extrait.

C'est le pénultième.


Mesures et estimations

En réponse à l’exigence de prédictibilité toujours exigée par le management, les méthodes agiles ont réussi, en quelques années, à populariser le planning poker, l'estimation en points et la vélocité.

Cependant les dérives liées aux habitudes du contrôle et du micro-management sont apparues de façon concomitante.

La mesure du temps de traversée du système kanban et son usage statistique apparaît comme une alternative aux techniques d'estimation utilisées pour prévoir de façon "agile".
Plutôt que de se baser sur des estimations de la taille ou l'effort des stories, qui viennent avec leur part d'incertitude et d'interprétation, Kanban suggère de s'appuyer sur des mesures moins discutables de temps de traversée. Cela est de nature à rassurer les parties prenantes, en particulier clients et managers.

Systèmes kanban

Cette mesure qui porte sur le temps que met le système kanban à produire de la valeur amène tôt ou tard à se poser la question de la mise à disposition de cette "valeur" à ceux à qui est elle est finalement destinée.

Ainsi les frontières du système kanban, côté sortie, sont naturellement étudiées en vue d'un élargissement à l'utilisateur final, ou bien pour mettre en place un autre système kanban, dédié au déploiement et connecté au premier.

Pour revenir à Scrum, son usage est souvent confiné à la phase de développement, ignoré avant, pendant les phases d'étude, et après, lors des phases consistant à déployer et à faire vivre la chose déployée. Ceux qui ont déjà choisi Scrum, mais restreint à la phase de développement, trouveront avec Kanban un moyen de repousser les limites d'un cycle en “Vrum”.

Ainsi, avec la création de réseaux de systèmes kanban, la méthode Kanban contribue à prendre une vue plus large, holistique, sur l'ensemble des activités de l'organisation.


à suivre…

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

Voici le dernier extrait de la préface que j'ai écrite pour la deuxième édition de Kanban pour l'IT, le livre de Laurent Morisseau.

This is the end


Kanban et opérations

Dans le domaine des opérations, de l'exploitation, du support, on utilise largement le terme de service. On parle de niveau de service, de garantie de SLA. En sortant du cadre du développement agile, la story n'est plus l'élément de travail naturel, on manipule plus volontiers des incidents, des problèmes, des tickets, des bugs, des évolutions.

Dans un système kanban, ce sont globalement des services, qui fournissent de la valeur ajoutée. On pourra d'ailleurs les organiser en classes de service afin d'adapter leur traitement à leur exigence de niveau de service.

Un service est rendu par une séquence d'activités permettant la découverte de l'information nécessaire. L'orientation services positionne clairement Kanban sur l'optimisation des activités (qui rendent ces services) plutôt que sur celles des personnes qui réalisent les activités. C’est bien un changement de paradigme du management, avec une recherche de l’efficacité qui fait passer la production de valeur avant le contrôle des coûts.

Kanban deuxième édition

Côté humain, Kanban se présente comme une rupture douce, qui s’appuie sur l’organisation et les rôles existants.

C’est ce Kanban là, nouveau et prometteur, que nous présente Laurent Morisseau dans cette deuxième édition. Dans son style direct et percutant, avec un discours fluide, il montre ce qu’est réellement Kanban :

  • pas une méthode agile de plus, mais une nouvelle méthode d'amélioration des processus orientée services,
  • en phase avec les valeurs et principes de l'agilité,
  • qui part de l'existant pour une transition progressive,
  • et qui s'attaque, au-delà des projets, aux organisations, même grandes et même au delà de l'IT.

Claude Aubry


Bonne lecture.

C'est publié chez Dunod, comme Scrum.

Préface de Kanban pour l'IT

Je publie à nouveau la préface de la deuxième édition du livre de Laurent Morisseau Kanban pour l'IT, en essayant de rendre sa lecture plus fluide (c'est du flux).

Ma préface de Kanban pour l'IT est publiée en 6 billets. Pour rendre la lecture de l'ensemble plus facile, j'ai fait un enchaînement séquentiel et créé une série (widget de droite). Dites-moi ce que vous en pensez.


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…