La semaine prochaine, Scrum Inc. diffusera son webinaire mensuel sur certains des pièges les plus coûteux Les équipes s'égarent lors de la mise en œuvre de Scrum. En préparant les diapositives de la présentation, le chef du Scrum Inc., Alex Brown, a demandé à certains membres du personnel d'analyser les problèmes les plus fréquents à l'aide du processus A3. Ce fut un excellent exercice et un rappel de l'utilité de l'analyse des causes profondes lorsqu'il s'agit de surmonter un obstacle tenace.
Pour ceux qui ne sont pas familiers avec le processus A3, Il s'agit d'un outil permettant d'identifier les causes profondes des problèmes difficiles et de parvenir à un consensus sur la manière d'y remédier. Le processus a été lancé par Toyota pour documenter les problèmes liés à son processus de production. N'importe qui chez Toyota peut lancer le processus et ils le font pour presque tous les problèmes qu'ils rencontrent. Pour saisir leur analyse, ils utilisent la plus grande feuille de papier qui puisse entrer dans une photocopieuse, le format A3 ou Tabloïd (deux feuilles de 8,5 x 11 côte à côte).
Ci-dessus, un exemple d'A3 que nous avons réalisé pour un client. OpenView Venture Partners de l'entreprise. Le processus est basé sur Planifier, faire Vérifier, agir ou le cycle PDCA. Sur le côté droit, nous avons décomposé le problème et commencé à planifier. Les parties prenantes se sont réunies pour définir le contexte, les conditions actuelles et les conditions cibles, et ont procédé à une analyse élémentaire des causes profondes. L'analyse des causes profondes ressemble à un cours sophistiqué que l'on suit à l'école de commerce, mais il s'agit essentiellement de canaliser l'enfant de cinq ans qui sommeille en vous.
Dans l'exemple ci-dessus, l'équipe ne parvenait pas à effectuer les tests pendant le sprint et les sprints échouaient régulièrement. Cela coûtait à l'entreprise partenaire environ 2 millions d'euros par an. Nous avons demandé aux parties prenantes de nous expliquer pourquoi elles pensaient que les sprints échouaient. Ils trouvaient une réponse et nous leur posions à nouveau la question : Pourquoi ? Cela s'est poursuivi jusqu'à ce que les parties prenantes aient atteint quelques niveaux de profondeur et que tout le monde pense avoir découvert la cause première. Les ingénieurs ne travaillaient pas bien ensemble et tout le monde pensait qu'il était évident que si le Scrum Master faisait son travail, les ingénieurs formeraient une équipe fonctionnelle.
Une cause première est comme une petite hypothèse scientifique qui doit être testée. C'est pourquoi il est important de disposer d'un certain nombre de possibilités. Sur le formulaire A3, utilisez la partie droite pour esquisser la manière dont chaque cause première peut être testée. Commencez par la cause première la plus probable. Décrivez ce qu'il faudrait faire pour atteindre les conditions cibles sur lesquelles l'équipe s'est mise d'accord plus tôt. Il est conseillé de disposer de quelques mesures solides pour les conditions cibles afin que le groupe dispose d'un moyen objectif de déterminer si l'amélioration du processus a fonctionné. (Mettez en œuvre le changement proposé et vérifiez s'il produit le résultat escompté. Souvent, quelque chose changera, mais ce sera inattendu. Le changement peut aider à clarifier le problème. Il peut aussi le résoudre. Si ce n'est pas le cas, descendez dans la liste des causes profondes. Souvent, les équipes pensent qu'elles ont résolu le problème, mais une autre force entraînera le même problème et les parties prenantes devront se réunir à nouveau. L'A3 est un document vivant qui doit être mis à jour au fur et à mesure que le problème évolue.
Dans l'exemple ci-dessus, toutes les personnes concernées pensaient que le Scrum Master ne parvenait pas à faire travailler l'équipe ensemble et la direction a donc décidé de prendre des mesures disciplinaires à son encontre. Cependant, quelques semaines plus tard, le problème a refait surface. Les parties prenantes sont retournées à l'A3 et ont creusé un peu plus. Il s'est avéré que le Product Owner était tellement concentré sur l'ajout de nouvelles fonctionnalités que l'équipe n'avait pas eu le temps de mettre en œuvre l'intégration continue qui lui aurait permis de tester son code au cours du sprint. Comme le Product Owner était également le PDG de l'entreprise, l'équipe n'a pas eu l'impression de pouvoir faire pression efficacement sur ce problème.
L'utilisation de l'A3 a toutefois rendu cette cause fondamentale transparente pour tout le monde, y compris pour les investisseurs qui siégeaient au conseil d'administration de l'entreprise. Ils ont pourrait Nous avons fait pression sur le PDG et l'avons amené à s'engager à mettre en œuvre l'intégration continue avant que toute nouvelle fonctionnalité ne soit autorisée à entrer dans le Backlog. Cela a résolu le problème et, quelques sprints plus tard, l'équipe a augmenté sa vélocité de 50% et de OpenView se sont épargnés, ainsi qu'à l'entreprise, 2 millions d'euros. Si vous êtes intéressé par un examen plus approfondi du processus A3, vous pouvez obtenir une analyse complète à l'adresse suivante http://scrumlab.scruminc.com/index.html.
Le 26 juinth Le webinaire traitera d'un certain nombre d'obstacles que les équipes rencontrent fréquemment. Chaque obstacle sera présenté dans un format de type A3. Cependant, le secret pour éliminer les obstacles tenaces réside dans l'utilisation des techniques intégrées dans le processus A3. Votre équipe constatera une amélioration significative de la vélocité si, comme les ouvriers de Toyota, elle l'utilise pour presque tous les problèmes.
-- Joel Riddle
French 
English 
Spanish