In product development, we often encounter problems that first seem like complete mysteries. More than once or twice I have heard a developer utter the words \u201cBut that\u2019s not possible\u201d when I have reported a problem. Another common mistake is to rush to the favorite explanation without establishing the facts first.<\/span><\/p>\n The result of disbelief, bubblegum fixes, quick fixes, and favorite explanations is often that the problem is not solved and its actual cause remains unknown, while the problem still haunts in the background, causing difficulties for the team or the customer.<\/span><\/p>\n Product development staff should use the methods of systematic problem solving.<\/span><\/p>\n<\/blockquote>\n Product development staff should use the methods of systematic problem solving. This is quite similar to detective work, so the Sherlock Holmes comparison is appropriate! In literature on leadership, systematic problem solving was first introduced by Charles Kepner and Ben Tregoe in their book The Rational Manager<\/i><\/span><\/a> <\/i>in the 1960\u2019s.<\/i> The methods in themselves, however, are age-old since their basics are familiar to us from Arthur Conan Doyle\u2019s<\/span><\/a> Sherlock Holmes stories.<\/span><\/p>\n <\/p>\n \u201cIt is a capital mistake to theorize before you have all the evidence. It biases the judgment.\u201d<\/b><\/span><\/p>\n \u2013 Sherlock Holmes<\/i>, A Study in Scarlet<\/i><\/span><\/p>\n The process of systematic problem solving starts from accurately describing and investigating the problem. In this phase, it is essential to avoid jumping to any theories, favorite explanations, and other conclusions.<\/span><\/p>\n All energy should be focused on collecting data on the problem. It is easier to investigate the problem if its title describes it as accurately as possible. For example, the titles \u201cthe warehouse floor is slippery\u201d and \u201cthere is oil on the warehouse floor\u201d are not descriptive enough. A better title would be: \u201cThere is an oil leak under the air vent number 1.\u201d With today\u2019s electronic bug management tools, it is easy to update the title of the problem. Right from the beginning of investigating the bug, it would be useful to review the title description of the bug and change it until everyone is satisfied with it.<\/span><\/p>\n <\/p>\n \u201cAlways approach a case with an absolutely blank mind. It is always an advantage. Form no theories, just simply observe and draw inferences from your observations.\u201d \u00a0\u00a0\u00a0<\/b><\/span><\/p>\n \u2013 Sherlock Holmes<\/i>, The Adventure of the Cardboard Box\u00a0\u00a0<\/i><\/span><\/p>\n The next step is to give a more detailed description. These questions will help you:\u00a0WHAT, WHERE, WHEN, HOW MUCH.<\/b><\/span><\/p>\n Finding the answers to these questions improves your understanding of the problem. When was this bug first detected? How often does it occur? How severe is it? Where does it occur?<\/span><\/p>\n Even though it might be a little more difficult to remember, this next step provides a lot of additional information about the problem. The above-mentioned questions can be refined: where this problem COULD OCCUR<\/b>, where does it NOT OCCUR<\/b>. The purpose of this is to find data on where and when the problem occurs and where it does not occur. Does the problem only occur in large systems, never in smaller ones? Does it only occur at a certain time of the day, for example, every day at 4 a.m., but never at other times? Does it only occur when the user logs in? Does it only occur when several users log in simultaneously?<\/span><\/p>\n The purpose of all these questions and answers is to help the investigators understand the problem better. This phase should be continued until the investigators feel that they have enough information and are now able to move on to the next step.<\/span><\/p>\n <\/p>\n \u201cThere should be no combination of events for which the wit of man cannot conceive an explanation.\u201d <\/strong><\/p>\n \u2013 <\/span>Sherlock Holmes<\/span><\/i>, <\/span>The Valley of Fear<\/span><\/i><\/p>\n The next step is to find the possible culprits. This step is much like brainstorming, and the best way to carry it out is in pairs or in a small group. In this step, it is essential to remember to remain disciplined and not to prematurely move on to the next phase.<\/span><\/p>\n When enough potential causes have been found, you should consider their mechanisms. Which sequence of events is required so that this potential cause could explain the problem? How likely is that sequence of events? If there are three potential causes, one of which is much more likely to be the actual cause compared to the other suspects, the next step is quite obvious.<\/span><\/p>\n \u00a0<\/span><\/p>\n \u201cWhen you have eliminated the impossible, whatever remains, no matter how improbable, must be the truth.\u201d<\/b><\/span><\/p>\n \u2013 Sherlock Holmes<\/i>, The Sign of Four<\/i><\/span><\/p>\n Next, you need to consider what kind of test could establish which one of the suspects is the actual cause. Then you should simply begin testing, beginning from the most probable suspect, to find out which one of the potential causes explains the problem. The testing becomes less difficult if the bug can be easily repeated.<\/span><\/p>\n When the culprit has been found, the last step is to fix the bug and carry out other necessary actions, which is usually quite a lot easier than finding the cause.<\/span><\/p>\n \u00a0<\/span><\/p>\n Thanks to the methods of systematic problem solving, it is easier and faster to find a solution to mystery bugs.<\/span><\/p>\n<\/blockquote>\n Thanks to the methods of systematic problem solving, it is easier and faster to find a solution to mystery bugs. These methods should be understood by product development staff, project managers, Product Owners, developers, testers, and customer support staff. A shared understanding can help create good titles and descriptions for bugs right from the start. Finding the possible causes and determining their probabilities quickly leads to finding the root cause<\/i>.<\/span><\/p>\n The problem-solving methods should be learned and practiced. Contribyte\u2019s Systematic Problem Solving<\/span> course module can be organized as a two-hour module with of the normal Scrum or Agile training, or as a more comprehensive one-day or half-day module with practical exercises and case descriptions. Contact us<\/span><\/a> to improve the problem-solving skills of your team or organization!<\/span><\/p>\n \u00a0<\/span><\/p>\n\n
\u00a0<\/h3>\n
\u00a0<\/h3>\n
Elementary, My Dear Watson<\/b><\/span><\/h3>\n
Don\u2019t Jump to Conclusions<\/b><\/span><\/h3>\n
The Importance of Clarifying the Description<\/b><\/span><\/h3>\n
\u00a0
![\"\"](\"wp-content\/uploads\/2018\/03\/Fotolia_60623679_S-300x232.jpg\")
<\/h3>\n\u00a0<\/h3>\n
\u00a0<\/h3>\n
Round up the suspects!<\/b><\/h3>\n
Consider the Probabilities and Test the Most Probable Cause First<\/b><\/span><\/h3>\n
Systematic Problem Solving Can Be Learned<\/b><\/span><\/h3>\n
\n