Laurent Morisseau's Blog, page 14

Lancement du Mastère en Excellence opérationnelle à l’INSA

Nouveau Mastere en Excellence Opérationnelle pour l’INSA

Pour la rentrée 2013 – 2014, l’INSA lance un nouveau Mastère en Excellence opérationnelle.

Il s’adresse aux ingénieurs et cadres managers souhaitant faire évoluer leur carrière en consolidant leur expertise par de nouvelles compétences en excellence opérationnelle.

L’objectif est d’apporter une réponse aux besoins de performance organisationnelle des entreprises, quelle que soit leur taille ou leur secteur d’activité.

J’ai le plaisir d’intervenir dans ce Mastere sur la partie Agile / Kanban.

 

Un conférence pour le lancement du Mastere

 

Pour son lancement, L’INSA organise une conférence le Mardi 4 Juin à partir de 14 h. Cette conférence est animée par Sens&Co, partenaire avec qui je fais en ce moment des missions Kanban dans des contextes industriels.

Le thème de ce colloque est la «Liberté et responsabilités, le chemin pour atteindre l’excellence opérationnelle».

Lors de cette conférence, introduite par Issac Getz auteur du best-seller « Liberté&Cie » et José Gramdi, inventeur du concept de Performance Interactionnelle Globale, des entrepreneurs locaux partageront leurs expériences de transformation de leur culture.

 

 
La participation à ce colloque est gratuite mais l’inscription obligatoire par mail à l’adresse mastere-eo@insa-rennes.fr.

 

Les ressources

La plaquette du Mastere
La présentation de la conférence
Le lien vers la page du Mastere de l’INSA

Kanban Digest #20

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@maukoquiroga I still find amazing that #Kanban is all about a journey and how to help others follow their own one.


@rodrigoy Agile is a consequence, not a goal. If Agile is right, proper evolution of the process (Kanban) will drive to Agile values and principles.


@jmluengo Scheduling regular prioritization meetings reduces coordination costs and is particularly useful in lower-maturity organizations #Kanban


@LeanVoices Essence of Kanban?:The secret is not to prioritize what’s on your schedule, but to schedule your priorities



Lu sur les blogs

A lire sur le blog d’Ayeba, un article intéressant sur la mise en place d’un Kanban au contrôle de gestion.

Motivation : le fait de voir les tâches réalisées, le travail accompli, la mise en évidence du flux de création de valeur, entraine une dynamique positive.

Next Move : Kanbanzine à Agile Rennes

Atelier Kanbanzine, découvrir le Kanban de manière ludique

La prochaine session Grafotech Agile, qui accueille les soirées Agile Rennes, a lieu le 6 Juin à Rennes à 18h30,

Nous vous proposons un atelier Kanbanzine pour découvrir le Kanban d’une autre façon !

Vivez la collaboration d’une équipe de journalistes !

Kanbanzine est un nouveau magazine hebdomadaire lancé tout récemment. A vous d’augmenter l’audience de ce magazine…

Pour s’inscrire, c’est ici (Attention, il n’y a que 14 places !)

Kanban Digest #19

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@hakanforss

ad-hoc swarming will help you create short term result but will likely make it harder to improve over time


@hakanforss

Follow @DReinertsen advise when setting WIP Limits. Start with 2x avg WIP. Then reduce WIP by 20-30% on a regular cadance e.g. Once a month


@hakanforss

What is the right WIP limit in an kanban system? When you can start finding what is blocking your flow.


@ourfounder

Interruptions create waste. What pulls your team away from planned work? How much value is lost? #lean #pkflow #kanban #management #pmot


@ourfounder

When a team has its work visually exposed for the 1st time, there is great relief and immediate improvements. #Understanding #pkflow #kanban


@asplake

my version of this one is « embrace variety, design for resilience » – positive & avoids the « variation » trigger word #lkna13


@reverentgeek

Kanban is not a methodology. Use it to improve whatever it is that you’re currently doing; observe and measure the flow of work

Lu sur les blogs

A lire sur le blog de Zsolt un système kanban avec des colonnes sans limite (ou des limites infinies).

Cela arrive lorsque l’on merge les flux de sous systèmes.

Mais avant cela, un de ses points de vue est de privilégier le principe des règles explicites aux limites kanban, quelques fois difficiles à suivre tant que l’on n’est pas sur un flux régulé, par exemple telle colonne doit être vide toutes les deux semaines. C’est un peu plus souple que de commencer par des limites.

Je rajouterais que les colonnes sans limite sont nécessaires dans les tableaux à deux niveaux de granularité (par exemple mélangeant des MMF et des user stories) :

 

Car on ne maîtrise pas en combien d’éléments une feature peut être découpée. Ce sera également le cas, plus en aval du système, lorsque l’on va attendre que la feature soit reformée de tous ses éléments avant de repartir dans le flux.

Lu sur les groupes de discussion

Une discussion très intéressante sur le groupe kanbandevfr sur la planification et la tenue des engagements avec du Kanban.

Au programme:

Burndown or not burndown ?
CFD, un faux ami ?
Simulation de monte carlo, quoi ça ?

Et surtout des retours qui viennent du terrain.

 

 

 

Conference #OMG, mon équipe fait son haka en Kanban Style !?!

Lors du dernier ScrumDay et de Mix IT, je présentais la session ScrumBan :

J’ai eu de bons retours sur cette session à Paris et à Lyon.

Lors du ScrumDay, j’avais amené ma caméra. Merci à Jean-Luc  Maze, de Conseil & moi, d’avoir filmé la session, en essayant de me suivre pendant une heure.

Je vous propose la vidéo de cette session pour ceux qui n’ont pu y assister.

Et puis, cadeau pour AgileFrance, conférence à laquelle je devais participer avec cette même session sélectionnée, malheureusement un impératif professionnel m’empêche d’être présent.

Cette session a fait l’objet en début d’année d’une série de podcast vidéo et audio :

Episode #1 : une story = 1 developpeur (ouch!)
Episode #2 : gérer des tâches émergentes
Episode #3 : travailler avec des bgoulets (d’étranglement)
Episode #4 : un PO dépassé par son Product Backlog
Episode #5 : gérer les dépendances externes
Episode #6 : faire la course à la feature
Episode #7: les bénéfices du ScrumBan

Le point de vue est ici d’utiliser Kanban dans un contexte Scrum pour le faire évoluer et répondre à certains dysfonctionnements classiques.

Sortez Scrum de sa zone de confort

Et faites du Kanban avec style !

Kanban Digest #18

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@hsutton Your job is not to do #Scrum/#Kanban/.

It is to learn, reduce risk, seek and deliver valuable software/service regularly


If you focus on averages you lose improvement opportunity. Customers experience a range. Explore it. @LeanVoices #lkna


@asplake nice dependencies board, but remember that less WIP means fewer dependencies #lkna13


@PeggyDrew3 Typical15% of cycle time is active dev, rest is time blocked or in queues. what value on perfect active dev estimate? @t_magennis #lkna13


@hakanforss Focus your process improvement efforts on reducing lead time by reducing the waiting time. Reduce WIP, reduce batch size #LKNA13


@hakanforss as we estimate effort(touch time) we only estimate the 15% part of the lead time. Very low impact on lead time


@pawelbrodzinski Instead prioritizing features ask how they help to achieve the business goal. Many of them don’t.

Scrum

Maîtriser la méthode Agile, le 13 Mai à Rennes

Agile

Conférence Agile Nantes, 7 Mai

Conférence Lean Kanban France 2013

Réservez tout de suite les 3/4 Octobre 2013 pour participer à la seule conférence Française sur le Kanban pour

AMPLIFIER L’APPRENTISSAGE – POURSUIVRE LA PERFECTION – VOIR L’ENSEMBLE

Devenez orateur et partagez votre expérience et vos idées avec un public de managers, leaders, entrepreneurs, responsables produit et de personnes qui transforment leur manière de travailler au quotidien.

Regardez quelques vidéos pour découvrir la conférence Lean Kanban France 2012

 

 

ou simplement découvrir le Kanban

 

L’agilité, même pas mal ~ épisode #5

Je vous ai déjà parlé du livre Rupture Douce, que j’ai eu le plaisir de co-écrire avec d’autres coachs Agiles. La saison 2 du livre étant maintenant en préparation  (lire le teaser de la prochaine saison), je vous livre maintenant mon histoire  »l’agilité, même pas mal ! » sans illustration mais avec une version podcast audio (à la fin du post).

Dans ce livre, je vous propose de découvrir le récit d’une transition silencieuse d’une équipe vers l’agilité. Et de découvrir comment l’approche Kanban a permis ce changement en douceur.

Episode #1 : Lancement du prototype opérationnel

Episode #2 : Le pilote opérationnel & la phase industrielle du projet Kanban

Episode #3 : L’épilogue et le debreif du projet

Episode #4 : Le debreif du projet pour l’équipe et le management

Episode #5

 

Et pour le coach ?

En tant que coach, j’avais un backlog de features (les pratiques agile/Kanban) pour ce projet. L’équipe ne pouvait pas les implémenter toutes en même temps. Il fallait donc prioriser, implémenter quelques pratiques, quelques changements et voir leurs effets.

Il faut accepter que toutes les pratiques ne soient pas mises en œuvre et constater que certaines n’apportent pas autant de valeur que l’on aurait supposé. Prioriser au fur et à mesure de ce que l’on apprend du projet et de la valeur que les pratiques apportent. Le backlog n’est pas qu’un outil du Product Owner. Il est aussi celui du coach lorsque le système à améliorer est complexe. C’est peut être frustrant pour le coach. Et cela ne remet nullement en cause la valeur des méthodes. Le problème n’est pas de savoir si l’on est « full » telle ou telle méthode, mais de mettre en place les bonnes pratiques dans le contexte avec la bonne profondeur.

L’approche empirique, à la base de ces méthodes, prend alors tout son sens. On a tendance à l’oublier lorsque les méthodes deviennent trop formelles. Là aussi, il faut expérimenter, adapter et laisser émerger les choses. Il faut prendre le temps de voir les effets à plus long terme, les cycles longs de remaniements de processus.

Cette approche m’a permis de formaliser la démarche Kanban telle que vous pouvez maintenant la lire dans le livre Kanban pour l’IT.

La posture du coach peut être celle d’un Sherpa, dans le bon sens du terme, pour continuer la métaphore de l’ascension. C’est un guide de montagne cherchant la bonne route pour l’équipe : une direction claire mais adaptative, un porteur pour aider l’équipe à se hisser et surtout un compagnon de route qui engage un dialogue permanent avec l’équipe, le management et le client.

La vision est importante. Savoir dans quelle voie on emmène l’équipe pour générer de la confiance malgré un contexte incertain. Je pense que c’est une part importante du succès de cette approche.

Le management doit laisser place au leadership et toucher la motivation profonde des individus, donner une signification au changement par des objectifs ambitieux mais réalistes, s’occuper d’abord des problématiques à résoudre avec méthode avant de s’occuper de la méthodologie.

Ce point fondamental fait d’ailleurs partie de la nouvelle définition du kanban, à juste titre pour faciliter l’adoption et la diffusion virale du Kanban dans l’organisation.

Car c’est bien l’équipe qui porte la transition. Le coach n’est qu’un guide et un témoin de ce doux changement. Le management donne les moyens d’y parvenir.

 

Le rythme du changement

Lors de mes premiers retours d’expérience de Scrum au Kanban en conférence, je faisais part de mon constat opérationnel que le Kanban minimise l’impact du changement et réduit la résistance à l’adoption de l’agilité.

 

Et finalement, est-ce une bonne chose?

Un changement de paradigme comme l’apporte Scrum permet de bousculer les choses, de redynamiser une équipe qui s’essouffle, des prises de conscience plus radicales, plus rapides mais plus perturbantes peut être dans certains contextes. Ce sont tous les freins à l’adoption de l’agilité que l’on rencontre régulièrement. L’accompagnement au changement devrait être plus présent dans ce cas. Dans la réalité, elle se résume à une formation, et plus rarement à du coaching. Bien heureusement, je constate avec satisfaction que ces missions de coaching se développent de plus en plus.

Avec Scrum et le Kanban, on a deux stratégies d’amélioration différentes:

L’amélioration par rupture avec Scrum vs les approches traditionnelles.
Le changement évolutif avec Kanban en instillant une culture Kaizen.

Ce qui peut être perturbant avec Scrum, c’est que cette amélioration par rupture lors de son adoption est en décalage avec le cadre d’amélioration qu’elle propose :

Une amélioration au quotidien par tous les mécanismes de feed-back qu’elle met en œuvre et par son modèle d’Inspection et d’Adaptation, proche de la roue de Deming de l’amélioration.

Pour parvenir à cela, les trois piliers du Kanban sont :

 

Commencer par ce que vous faîtes maintenant.

Trop de changements rapides provoquent du stress et de la résistance. Ne pas changer l’existant au démarrage d’une démarche d’amélioration est moins perturbant pour les membres de l’équipe. En contrepartie, la démarche peut être moins porteuse d’innovation immédiate.

 

Respecter le processus actuel, les rôles et responsabilités.

La méthode ne se suffit pas à elle-même et s’applique à un processus existant. Et surtout elle s’applique dans un contexte existant.

 

S’engager à changer de manière incrémentale et évolutive.

Dans une démarche évolutive, if faut trouver le rythme du changement et avoir de la patience. Sur ce projet, je souhaitais faire le troisième remaniement à mi-projet, en décembre. Mais l’atelier Kanban n’eu lieu que début février avec les chefs d’équipe, pour une mise en place début mars avec l’équipe. Il nous aura fallu près de trois mois pour passer de l’idée d’une amélioration à sa réalisation. Pourtant, il s’agissait d’une étape majeure dans l’amélioration visant à se rapprocher du flux tiré et permettant de passer de trois équipes spécialisées à une équipe plus intégrée. C’est évidement long, mais c’était le bon rythme à ce moment là du projet.

Il y a eu quatre remaniements majeurs du système Kanban. Ces remaniements traduisaient le début d’un nouveau cycle d’amélioration. Chaque cycle durait entre trois et quatre mois.

Il faut avancer au rythme des individus, de l’équipe et de l’organisation qui l’encadre.

Chaque cycle apporte de la valeur en améliorant à la fois le système et l’équipe. Le temps pour parcourir un cycle représente la capacité propre à l’équipe d’assimiler le changement. Le management et le coach doivent accepter cela.

Il n’y a pas de jugement autour de l’une ou l’autre de ces stratégies d’amélioration, puisque les deux sont nécessaires pour innover. Là encore, une mise en contexte est à faire. Le Kanban permet une approche Kaizen facilitant l’adoption de l’agilité et l’innovation disruptive de Scrum permet de relancer l’intérêt, la dynamique de changement rapidement dans une équipe ou une organisation.

Vous pouvez également écouter la version audio de ce podcast ci dessous ou sur iTunes