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.

Performance Model Calibration – What are your production users doing?

September 13th, 2011 by Leave a comment

Capacity Planning, Modelling and Management can be seen as a daunting process as each systems yield their own unique challenges in measuring and reacting to customers usage patterns.  Most of my customer are concerned and interested in one thing;… Read more

Performance Testing is not necessarily Performance Engineering

June 22nd, 2011 by 4 Comments

I’ve been in Performance Testing for almost 10 years and consider myself an experienced Performance Testing consultant. As a Performance Testing consultant I have worked for a variety of organisations over this time and of late have noticed an… Read more

The Performance Architect

March 22nd, 2010 by Leave a comment

Business Requirements, Solution Architecture, Infrastructure Architecture, Application Architecture, Detailed Designs and followed by code. A common pattern and sequence of artefacts which are delivered in the Software Development Life Cycle that… Read more

Unit of Scalability

July 27th, 2008 by 1 Comment

Recently, some of our clients had asked us to determine an early performance view of an application that they are either considering to purchase or have recently purchased. Considering all things that make up a J2EE application, this can be… 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