During our Sprints it is not uncommon for some problem event to occur. Such events could be anything from a story taking considerably longer to complete than it was estimated to take, to a production bug being injected into a Sprint. As a team we would usually acknowledge these events in our retrospective and make a few brief comments about how to eliminate similar occurrences in the future. It seemed however as though we would promptly forget about the problem…until it happened again.
After seeing these problem events continue to occur, my team started throwing around the idea of doing root cause analysis. The hope was to get to the bottom of why these things were happening in the first place.
At first we were not quite sure how to conduct a formal root cause analysis, but after a little research we got ourselves pointed in the right direction. Our first analysis was a great exercise in drilling down into the heart of something the team saw as a problem. By focusing on one specific problem we were able to:
- identify a plethora of individual areas that led to the problem in question.
- isolate causes that could immediately be acted upon.
- identify causes that we as a team could not solve alone.
- bring causes into the foreground spurring discussion, and setting the team up to be mindful of them in the future.
As a team we have seen the benefit of analyzing our problem events and have integrated root cause analysis into our Sprint cycle. Just like we have a retrospective at the end of the Sprint we also have a root cause analysis session. One team member is responsible for presenting a problem event to the team and leading the analysis. To date we’ve done this three times and have used two different methods of analysis (Ishikawa Diagram, Cause Mapping). The way the analysis is run is completely at the session leader’s discretion.
We’ve already started to deal with areas that were immediately actionable, and have at least started to get the ball rolling in some areas that require a little more thought and organization. It is no doubt in my mind that as my team continues to identify and eliminate the root cause of our most crippling problems we will reach that hyper-productive state that so many Scrum teams strive for.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
