News / Starting with Data

Does your team understand the difference between an incident and a problem? Have you identified the root cause of recurring issues or is your team selecting improvement efforts based on hunches and personal bugaboos? Deciding which parts of a system to rework is a real challenge for any development team.

At worst these decisions devolve into an aesthetic debate, drifting into the realm of rhetoric and reaction-driven appeals to consensus. If you want to make a rational case, a little bit of data goes a long way.

I like this lo-fi technique as a starter for more productive conversations:

  1. Open your work item tracking system (VersionOne, Jira, GitHub Issues).
  2. Export the titles and descriptions of defects to a text/CSV file.
  3. Generate a tag cloud in Wordle with the text from the exported file.
  4. Take it to your team, asking about the standout words.

In the example above, problems involving UI components and JavaScript jump right out. This insight comes cheaply — we don’t have to ask talent to classify bug reports according to a taxonomy. It’s just text.

I use this tool when coaching teams who are attempting to manage or pay back technical debt. It regularly prompts more focused investigations yielding higher fidelity data and occasionally there’s a group insight.

Give it a try, and let me know how it goes!

Looking for a proactive, rigorous and systemic approach to incident and problem management? I recommend the book “The Art of Scalability” by Marty Abbott and Michael Fisher. In chapter eight, they apply the formalisms from ITSM incident and problem management to some sound, real world advice for service teams.

Updated: