10:00h-11:15h Root cause analysis by Squirrel
- Target a specific event: One specific bug at a time.
- Everyone affected attends: All people affected attend to the meeting
- No blame: The goal is to solve the problem, not to attack people.
- Poll to identify problems: Do not assume anything. Start by asking all different points of view about 'What was the real problem?'
- Write a lot: Write on a board, write in a tree map, from top to down. From effects to possible causes and final actions. First asks only 'What went wrong?' put a list on top of board as headers. Then for each header asks 'Why it happens?' write down all possible causes. Finally asks 'What actions can be done in a week?' Fins proposed solutions. Take immediate short actions. Compose long solutions from small one week doable actions.
- Move down then across: check and review all written board.
- If it doesn't hurt, then you aren't doing it right: Find danger, risk, discomfort. Move on if necessary but consider future actions.
- Proportionate tasks: Apply proportionate responses to the problems. If you are re-writing your entire app because of a 3 minutes of down time, then you are not doing the right thing
- All tasks done in a week: Every task agreed to:
1) Has to be do-able in one week
2) Has to actually be done in one week
2) Has to actually be done in one week
How does this compare to retrospectives? Retros are related to teams, the pain is more direct
Other techniques for NOT losing focus? Keep it short term The next root cause analysis might highlight the "next" step, but for now, "all we have to do now is take this first step"
Vote every day on actions from retrospectives to determine whether or not they are being actioned Smiley faces or sad faces depending on votes
Bickering can be a problem. Having a senior person present helps diffuse these types of arguments.
- Take a photo of the board: Keep it visible for future references, modifications, constructive discussions.
- During the week: One responsible goes across the team in the meeting and check the progress of each proposed actions for that week. After one week clean all the to do and in progress tasks. Then create new tasks with updates to the board. Annotate things like 'Why the action could not be done last week?'
Conclusions: With a professional environment with lots of respect and actual collaboration this looks like a very powerful methodology. If not, it could be required a good expert that masters all the underground skills necessary to drive the team. It looks to me a mater of learning how to deal efficiently with problems. Maybe companies should invest some money (do not expect to be able to calculate RoI here) to help their employees to learn about something else beyond the usual crafts.
Original Source: http://citconf.com/wiki/index.php?title=Root_Cause_Analysis
Posted by Marc Andreu Fernàndez.
Posted by Marc Andreu Fernàndez.
No comments:
Post a Comment