Je viens de finir le nouveau livre de Mary et Tom Poppendieck, une référence du Lean Software Development, après Implementing Lean Software Development.
A mon sens c'est plutôt un livre à destination des managers avec une vision du Lean SD du développement à l'organisation, pour creuser les concepts plutôt que pour découvrir le sujet.
Ce que j'ai réappris
La résolution de problème est le moteur de l'amélioration continue et d'apprentissage:
See problems, solve problems, and share the learning
Que l'effet de contraindre un système est de rendre visible ces problème (et donc d'apprendre).
Une organisation performante cherche à apprendre à faire plutôt que se focaliser sur la seule réalisation, ce qui fait une grande différence.
Et que pour faciliter l'apprentissage des gens, malgré les silos des organisations, techniques ou fonctionnels, on aligne tout le monde sur les clients (avec les outils tels que le value stream mapping). Un client n'est pas seulement celui qui paye mais également les interfaces de chaque entité dans une logique de processus : Chacun dans l'entreprise doit prendre conscience qu’il travaille non pas pour lui mais pour un tiers à satisfaire même au sein de l’entreprise grâce à cette logique de processus. Vu que l'on retrouve dans le livre
Le manager agile.
La liste d'obstacle et l'A3
Scrum nous propose un outil visuel pour rendre visible les problèmes : la liste d'obstacles (ou impediment list): Les obstacles sont identifiés lors des daily Scrum, mis sur des post-it. Ensuite le Scrummaster doit les résoudre au plus vite.
Le Lean nous propose le
template A3 de résolution de problème basé sur le
PDCA.
Orchestrer les deux
Mon processus pour résoudre les obstacles est maintenant le suivant: les obstacles sont identifiés et rendus visibles par l'approche Scrum décrite précédemment: Sur le post-it, on note le titre de l'obstacle, le porteur et un camembert PDCA. Après le Daily Scrum, le Scrummaster fait une réunion avec le porteur de l'obstacle et initialise le template A3, la partie Plan. Si possible le Scrummaster agit plus comme un mentor pour que le porteur de l'obstacle résolve le problème. Le Scrummaster suit l'avancement sa résolution et rend visible son avancement en coloriant les parts du camembert PDCA et en maintenant à jour la feuille A3.
Cette approche combine le meilleur des deux car évite de se focaliser sur le très court terme (Scrum: lever l'obstacle au plus tôt) tout en ayant un outil visuel très simple (post it avec camembert) et en participant à l'entreprise apprenante (le coach agile prend plus l'attitude d'un mentor auprès des membres de l'équipe, les aidant à résoudre les problèmes).
Le Scrummaster est un rôle difficile car il doit être un leader sans être manager. Au niveau organisation cela devient un principe de management par le leadership:
"To lead the organization as if I had no power"
Mr. Kan Higashi, président de Nummi
C'est à dire par l'exemple, le coaching, la compréhension et aider les autres à atteindre leurs objectifs.
La deuxième moitié du livre était plus inspirante que la première pour moi.
En attendant le livre, vous pouvez toujours patienter en regardant la
vidéo de Mary sur InfoQ.
Conforté également dans l'approche opérationnelle: Commencer là ou on en est, définir la cartographie de la chaine de valeur (Value Stream mapping) du processus existant avec l'équipe comme base pour construire le tableau Kanban: Il doit refléter la manière dont l'organisation ou l'équipe travaille car c'est un outil opérationnel. J'ai vu plusieurs équipes délaissées leur tableau Scrum car trop éloigné de leur manière de travailler, modélisant leur processus cible par exemple.
Avec le Kanban, on se concentre sur une pratique simple, un système avec des cartes et des limites aux états qui contraignent le système juste assez pour provoquer le prochain changement incrémental.
Messages
