kanban

Kanban, l'approche en flux pour l'entreprise agile

Kanban, l'approche en flux pour l'entreprise agile

C’était en janvier 2016, pendant le 4e raid agile. Le jeudi après-midi, avec Pablo nous avions animé le puzzle Astérix (oui, de l’agilité à l’échelle !). À la demande de participants, nous avions prévu un créneau sur Kanban. Comme j’étais en train de ranger les pièces du puzzle et que j’avais beaucoup donné pour ce jeu, nous décidâmes que ce serait Pablo qui présenterait Kanban tout seul. Pablo s’était placé à gauche de la cheminée et commençait à placer des post-it sur un rectangle de fer noir qui servait de tableau.

Flux dans le sprint et engagement

Suite à la lecture de mon billet Scrum3.0, Eric se demande, à propos du sprint en flux continu : Le flux continu remet en cause le principe “pas de changement pendant un sprint”. Comment permettre à l’équipe de s’engager dans ce mode de fonctionnement ? Au jour le jour ? Ou est-ce que ce mode de fonctionnement est réservé à des équipes qui ont dépassé le stade de la nécessité de s’engager ?

Scrum 3.0

Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l’essence de la méthode. C’est pourquoi je porte une grande attention à l’article Scrum3.0 qu’ils viennent de publier. On y retrouve l’approfondissement de quelques sujets déjà abordés dans leur livre. Parmi leurs propositions :

Al tablèu

Version especiala per Occitània

Venètz aprener lo manejar visual en tornant bastir los sitis bèls de la region nòva. Mardi prochain au Klub de jeu d’Agile Toulouse nous expérimenterons une nouvelle version, chargée d’histoire, d’un jeu qui a déjà une longue histoire. À l’origine, c’est un jeu imaginé par Xavier Quasada Allue. Il a été adapté et traduit par Alexandre Boutin, c’est devenu Au tableau. En discutant récemment avec Laurent Morisseau, il m’a appris qu’il avait aussi largement participé à l’évolution du jeu.

Accompagnement Scrum

Il y a des coachs agiles qui sont à plein temps chez leur client. Parfois même, ce sont des armées de coachs à plein temps qui restent pendant une longue période au sein d’une organisation. Je suppose que c’est pour des transformations agiles aussi massives que délicates. Ce n’est pas la forme d’accompagnement que je pratique. En général, j’accompagne mes clients de façon discontinue et sur une période limitée. Un bon exemple de ce que je fais, bien que ce ne soit jamais pareil, a été montré dans le retour d’expérience d’Intel à Agile tour Toulouse (il avait aussi été présenté au ScrumDay à Paris en avril).

Arrêter Scrum pour le flux, un début d’expérience

Sophie de Sophia

Suite à ma présentation à Lean Kanban France, j’ai reçu un message de Sophie. Elle accompagne une équipe confrontée à des difficultés avec Scrum qu’elle a aiguillée vers Kanban. Son expérience est intéressante et elle la raconte bien, alors nous avons décidé de la publier. Il s’agit donc d’un billet invité, autrement dit de guest blogging. Voici le message de Sophie de Sophia : Bonjour Claude, Je viens de lire ta présentation “Appliquer Kanban sur Scrum”… j’aurais bien aimé y assister !

Les slides de ma prez à #LKFR15

Début septembre, suite à une discussion à propos de Scrum et Kanban, j’avais publiéce billet. Les organisateurs de Lean Kanban France, en particulier DImitri que je remercie chaleureusement, m’avaient alors dit que ce sujet pourrait être intéressant pour la conférence, qui a eu lieu hier et aujourd’hui. J’aime beaucoup cette conférence et j’ai eu plaisir à y participer. Voici les slides que j’ai présentés hier : Appliquer Kanban sur Scrum, LKFR nov.
Participation à Lean Kanban France

Participation à Lean Kanban France

Appliqué sur Scrum, Kanban permet d'éviter les débordements pendant un sprint

dessin de Patrice Courtiade Après avoir passé la journée du lundi avec mes camarades de la Fédération Agile pour notre conversation semestrielle, je participerai le mardi 3 novembre à Lean Kanban France. LKFR une conférence super intéressante avec des orateurs européens (et un américain) de grande qualité. Je présenterai une session à 17h “Appliquer Kanban sur Scrum”, qui reprend les idées évoquées ICI. Le sujet est développé dans le chapitre 20 de mon livre, qui se conclut ainsi :

Appliquer Kanban sur Scrum

C’est le titre d’un nouveau chapitre de mon livre, pour l’édition 4 qui sort dans un mois. Je rebondis sur le billet de Laurent Morisseau “Kanban contre le flux continu” pour dire, avec lui, que Scrum et Kanban peuvent cohabiter. C’est le sujet de ce nouveau chapitre. En introduction du chapitre, je donne les impacts souhaités sur les rôles Scrum, qui rencontrent des problèmes dans certaines situations : (cliquer pour agrandir)

Arrêter Scrum pour le flux, mmmmh !

Parmi les raisons évoquées par ceux qui disent “on arrête Scrum pour passer au flux”, certaines m’apparaissent très discutables : les réunions prennent trop de temps, le sprint est un carcan qui met la pression sur les équipes, on déploie à un rythme différent du sprint, alors pourquoi le garder ? En effet, on peut rétorquer que ce ne sont pas des réunions, que si on y regarde de plus près ce sont souvent les estimations qui prennent du temps et qu’on peut tout à fait les supprimer en continuant 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.

Quand faire l’affinage du backlog ?

When to refine the backlog? L’affinage du backlog (refinement backlog, previously backlog grooming) est une activité faite par l’équipe pendant un sprint, dans le but de préparer des stories pour les prochains sprints. Dans quel cadre est-il pratiqué ? Une grande partie de ce travail est constitué de discussions entre le Product Owner et le reste de l’équipe. On peut donner un caractère permanent, officiel, à ces rencontres en les plaçant dans la cadre d’une réunion d’équipe, le meeting d’affinage de backlog (le MAB).

Affinage de bac en bac

Des petits bacs plutôt qu’un gros backlog, l’idée a maintenant fait son chemin. C’est plus facile pour l’affinage. L’idée des bacs m’est venue quand j’étais encore Product Owner d’iceScrum, il y a 3 ans. Il y avait déjà le bac à sable, puis s’est ajouté le bac à glace. Pour iceScrum, ça s’est arrêté là, mais j’ai continué à expérimenter cette façon de présenter le backlog. C’est devenu “les bacs”.

Mes lectures de l'été

Quelques lectures en relation plus ou moins directe avec le sujet de ce blog. Manipulation J’ai commencé par le “Petit traité de manipulation à l’égard des honnêtes gens”. J’ai lu la 2ème édition qui vient de sortir. J’en avais eu connaissance par mes camarades du club de lecture d’Agile Toulouse. C’est un livre écrit par des chercheurs français qui a un écho important. A sa lecture, on ne manque pas de s’interroger quant aux potentialités manipulatrices des méthodes agiles.

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.

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.

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.

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.

8 ans de blog

En fait, j’ai lancé mon blog le mardi 4 avril 2006. A l’époque, j’étais encore prof à la fac et j’avais attendu que les étudiants partent en stage, début avril, pour m’occuper du lancement du blog[1]. C’était le début d’une belle aventure dont je ne pensais pas qu’elle me mènerait aussi loin. Au début, mes billets étaient bien plus fréquents, car Twitter n’existait pas encore. J’ai écrit pas mal de billets courts qui feraient maintenant l’objet d’un simple tweet[2].

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

Suite de la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition. 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 :