When running Five Whys in a team, how do you prevent the loudest voice from forcing a single "root cause" instead of surfacing multiple factors?
I might write up a story on this, but imagine this:
* pipelines started failing because npm rejected an originations credit card
* at this point, this org already had the packages they couldn't fetch from NPM in GitHub, so someone threw together a PR that moved to the new packages (GitHub)
* The PR didn't get merged, and was forgotten since, instead, they waited two days for someone to update the card information in NPM
One piece of advice that came to mind is to make sure they write down their answers first. It may prevent loud voices by pausing for a bit, and also generate more root causes.
When running Five Whys in a team, how do you prevent the loudest voice from forcing a single "root cause" instead of surfacing multiple factors?
I might write up a story on this, but imagine this:
* pipelines started failing because npm rejected an originations credit card
* at this point, this org already had the packages they couldn't fetch from NPM in GitHub, so someone threw together a PR that moved to the new packages (GitHub)
* The PR didn't get merged, and was forgotten since, instead, they waited two days for someone to update the card information in NPM
One piece of advice that came to mind is to make sure they write down their answers first. It may prevent loud voices by pausing for a bit, and also generate more root causes.
But of course, "it depends" :)
Thanks for your example, Akos!