Using Systems Thinking when trouble-shooting

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Hussein Badakhchani's Blog | June 15, 2006  12:00 PM | Comments (0)

I expect most people reading this blog have at some point in their working lives become unwitting participants in the Blame Game. Let me describe a typical scenario, your project is approaching a deadline but there seem to be a number of stubborn defects that manage to evade resolution or are constantly being closed and re-opened. Upon closer inspection of these defects you notice that they are being re-assigned from one team to another. These defects have past resolutions like "re-deployed application" or "re-started server". This phenomia alone is not indicitive of the blame game, these are symptoms of two system archetypes namely, "Treating-the-symptom," archetype and "Solutions-that-fail," archetype.

Treating-the-symptom.

A treating-the-symptom archetype starts out with a problem. People become aware of the problem through the symptom that accompanies it. Pressure to resolve the problem to meet the deadline leads managers (and therefore developers) to direct the solution toward the symptom. Because the problem hasn't been solved, the symptom will resurface latter in the test cycle where the risk it poses to project delivery is increased. In addition, the solution applied to treat the symptom may produce side effects that actually make the original problem worse.

Solutions-that-fail.

The solutions-that-fail system archetype begins with a problem. Those responsible for addressing this problem choose a quick-fix solution to make the symptoms of the problem go away. They may or may not be aware at the time that this is not the best solution to the problem. Instead of solving the problem, the quick fix actually creates unintended consequences and other problems. This archetype is commonly seen in organizations under pressure. In this instance the solution is often some kind of operational workaround or change in procedure rather than a code fix.

To recap, these systems archetypes alone will not necessarily lead to a Blame game scenario. The missing ingredient is management culture. Defects do not necessarily fit into clearly defined categories that can be managed by a single team, for example the DBA team or application support. In fact the tougher long lived defects tend to be those that require resouces from multiple teams in order to be resolved in a satisfactory manner. This is a point that most managers would like to ignore especially if they feel their teams are already overstretched and under resourced, enter the Blame Game.

It works on my dev box, it must be your fault...

The primary purpose for a participant in the blame game is to displace responsiblity to others, the perceived benefits to the arbitrator are manifold, but in our case the beleaguered manager thinks he is protecting his resources from exploitation. The blame game is infectious. Other managers will join in and soon you find a huge amount of time and energy is spent passing the buck rather than resolving problems. In the worst case scenario those individuals that do not participate in the game and actually try to find good solutions are penalised as large numbers of defects are assigned to them and SLAs around defect resolution are breached.

What can you do about it?

I have found the best approach to the dealing with this scenario is to attempt to deal with the defect the best you can, don't just say it's someone elses problem and spend thirty minutes arguing with the person who raised the defect about not having enough information to fix it and then sculk off in a sulk (seriously I have seen this behaviour more than once). Instead create a bulletproof case as to why the problem does not lie "In the application". Check newsgroups for your stacktraces and error messages, even if you don't understand the answer this research could be useful to someone who does. Then when you claim the defect is not in your domain of responsibility you increase the chances of the defect going to the right team to fix and you make it a lot harder for the next person to own the defect to pass it on without addressing your work, in fact they may be able to fix the defect based on your efforts!

The initial cost of this approach will be high but it has it's benefits. Your analysis will be considered more credible than those that continue to participate in the Blame Game and by cooperating with others outside your immediate team your understanding of the organisations entire technology stack will improve considerably. The real benefit in my opinion though is knowing you are part of the solution and not part of the problem.

Comments