Sherlock Holmes, Kanban and the Art of Performance Remediation

November 9th, 2011 by Leave a comment

I have recently completed reading the collected stories of Sherlock Holmes by Sir Arthur Conan Doyle, and was struck by the resonance between three memorable quotes, and the processes I have used during performance remediation activities in the last couple of years. These processes are based on agile principles and Kanban and have help to keep the team’s energy and concentration focused on high priority activities.

It is a capital mistake to theorize before you have all the evidence. It biases the judgment.” – Sherlock Holmes, A Study in Scarlet

Using agile methods, Odecee will commonly run a workshop where we review the existing performance problems and then ask our stakeholders for their theories regarding the recent poor performance. We then add these as cards to the “To Do” list on our Kanban board. Based on our prior experience we also add theories as cards of our own.

At this point we make sure not to discuss these theories in any detail and emphasise that none of these theories have been proven or investigated in any way. We treat them as “hearsay” until further information is collected so as not to influence the direction of our investigation.

We balance probabilities and choose the most likely. It is the scientific use of the imagination.” – Sherlock Holmes, Hound of the Baskervilles

The next stage is to apply a methodical, analytical approach to prioritising the most likely causes of poor performance. At Odecee we would commonly have a second round to our first workshop where we ask the participants to consider the current symptoms of poor performance and to consider their past experiences. Then, using agile voting cards, we quickly build a consensus view of the likelihood of the presented theories contributing to poor performance.

This priority is then recorded on the cards on our Kanban board. This defines the order in which we should tackle our investigation, and also builds a single view on approach for our stakeholders at the same time.

Eliminate all other factors, and the one which remains must be the truth” – Sherlock Holmes, The Sign of the Four

We typically move our Kanban board and place it in a public area for all to see. As we investigate a new theory we move the associated card from left to right on the board, and add comments on the card regarding the evidence that supports or disproves it.

As our investigations identify new theories, we add them to our board in the ‘To Do’ column. We don’t immediately change tack to investigate the new theory – we just rate it according to likelihood and impact and get round to it as its priority suggests. After all investigation has completed for a hypothesis it is moved to the “proven” or “disproven” column and actions to remediate proven hypothesis can begin.

At the end of the agreed cycle period, typically a week, we review the status of our theories and decide whether to continue with further investigation.

In closing, I’m sure that if you keep these 3 quotes in mind, and use a Kanban board to track our activities you will find that it helps attain swift agreement on your teams activities,  and makes the process, progress, and  outcomes more transparent and easily understood to your stakeholders.

Build Pipeline – Software quality through repeatability

August 16th, 2009 by 3 Comments

What are the hallmarks of a quality software development team?  What attributes stand out from software which gives it the feeling of quality?  These questions and many more, lead to the seemingly elusive quality answer.  Certainly, answers to… Read more

Performance Unit Test; a development concern

March 17th, 2008 by 3 Comments

As a developer, I feel performance is too often neglected by the development team. I’ve been on a few projects that have been really compromised by the performance aspects of a JEE system, specifically because of the lack of performance testing… Read more

When to avoid the Container during Unit Testing

January 30th, 2008 by 1 Comment

Over the course of my career, I have been eagerly reading, interviewing colleagues and experimenting with my own unit testing methodologies. It was only recently, that a fellow odecee colleague and I sat in a room and attempted to map out what we… Read more

Is Dependency Injection only useful for Unit Testing?

January 7th, 2008 by 8 Comments

The rise in popularity of Dependency Injection over the last three years has been an interesting observation. “Lightweight containers” like Spring and Pico have really intrigued and excited the masses of Java Developers, so much so, that Spring… Read more

Unit testing; how far do you push the envelope?

December 4th, 2007 by 23 Comments

Over the years, l’ve read lots of commentary, white papers, best practice papers, books on the topic of TDD. I’ve heard the rant of many TDD evangelists who preach about how total code coverage brings you closer to code quality perfection and how… Read more