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:
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.
1 commentaire:
Merci Laurent pour ce retour d'info. Est-ce que le livre donne des outils concrets pour résoudre les problèmes, pour devenir meilleur en résolution de problèmes ? Il me semble en effet crucial de développer nos compétences en résolution de problèmes, ce n'est pas inné !
Bruno
Enregistrer un commentaire