Skip to main content

The Periodontal Probe: A Cautionary Metrics Case Study for Coaches

Did you visit your dentist today?  If not, perhaps it is because in modern dentist offices (at least in the US), a routine dental checkup consists of four key steps:
  1. A hygienist grimly and repeatedly stabs your gums with a pointy stick called a periodontal probe (6 stabs per tooth!), and loudly calls out numbers from 1 to 15 with each stab, where anything over 3 means "tooth about to fall out." These numbers, they assure you, go on your permanent record.
  2. The same hygienist scrapes some stuff off of the teeth along your gum line, a painful process appropriately known as "scaling."
  3. The hygienist gives you a choice of grape, watermelon, or mint toothpaste, and uses that little round tooth cleaning widget to clean the remaining surfaces of your teeth.  They don't say it, but you know and they know that the widget is actually a disguised drill.
  4.  The dentist comes in, looks things over, and gives you some summary advice and follow-up requests, like "come back in six months" (that's good) or "let's make an appointment for you for a new filling/root canal/major gum surgery/denture fitting" (that's bad).
Amazingly, this sequence of events is considered a "best practice."  One dental blogger writes:  "Next time you visit your dentist, if you don’t hear them calling out your numbers ... find another dentist!"
Sir Lawrence Olivier as Dr. Christian Szell, in "Marathon Man," http://www.aveleyman.com/ActorCredit.aspx?ActorID=13188
He continues:
[If] the screening occurs in silence, the patient does not have the advantage of listening to their own pocket depths and correlating what they are hearing with the health, or lack of, inside their own mouth.  What a missed opportunity!  Listening to the numbers could directly impact patient “ownership” of an infection that generally has no symptoms. Patients should be given an opportunity to hear their own numbers as the data is collected, as well as see evidence of active infection by looking in the mirror to see tissue that bleeds readily during measurements.
Nice.  It is no wonder that RDHMag.com, the Registered Dental Hygienist site states that:
...over half of the American population suffers from "dental phobia or related anxieties."2 Some have a fear of dentists and what they might say or do, while others are terrified of dental procedures, some to the point that they do not want to think about or be aware of even minor interventions. Others have specific problems, such as a bad gag reflex, a fear of needles, or a prohibitive embarrassment about seeing a dentist.3
"So what," you say.  So, even if you scoff at the need for shiny teeth and not-bad breath, gum disease is actually quite a serious health risk.  As MayoClinic.com points out succinctly, "Periodontitis can cause tooth loss or worse, an increased risk of heart attack or stroke and other serious health problems."  Also, gum disease has been correlated with Alzheimers.  I'm not even kidding.

"Yes," you say, perhaps grinding your teeth, "But what does this have to do with the use of metrics for coaching, particularly in large-scale agile transformations?"  Here's the point.  You can't help people if you are scaring them to death. 

Your dreams, as an agile coach, are akin to those of the dental hygienist, who (presumably) dreams each night of rows and rows of shiny teeth embedded in plump, light pink tissue.  You envision your enterprise, line of business, large program, or team, having big, automated, visible charts out the ying yang, telling the (firewall protected) world on a minute-by-minute basis how healthy things are, so that someone can jump in and fix the little problems as they occur.

Your patients, pardon me, your clients, are in a bad way.  That is why they have asked you for help.  In fact, you can be sure they are in a VERY bad way, because they are executives, and by nature, executives don't ever want to give the perception that they need help, even if they do.  In fact, maybe someone forced them to retain you.

This is not an EDUCATIONAL OPPORTUNITY, dear reader, where the first thing your hiring sponsor wants you to do is an instant, detailed, and gruesome metrical depiction of what is wrong.  If this is where you start, especially in writing, then you have now escalated the executive's situation from "I don't want people to perceive weakness" to "my coach has now broadcast my weakness to the world."  You have if you will pardon the expression, taken the most efficient route to biting the hand that feeds you.  You can't coach an organization effectively if they have fired you.

And it's not just about you.  It's about them.  Do you really want to help?  Then you need to be encouraging, not judgmental and demeaning.  And let me help you make this leap.  Anything that smells like "I'm the expert, and you're the failing executive" comes across to an executive as judgmental and demeaning.  You are the dental hygienist who holds the screaming child down to prevent them from escaping while you do the cleaning.  You have just created a life-long agile phobia.

Here are some lessons for agile transformation I have taken directly from the world of dentistry.  Please allow Registered Dental Hygienist Carol A Jahn, MS walk you through it as a sort of guest blogger.  I've taken the liberty of swapping in software delivery words for dental terms of art,  but virtually all the rest of the advice works intact!  Check it out.
  • Promote self direction.  Rather than identifying for [clients] areas that need improvement, begin by asking them how they feel they are doing. Good trigger questions to ask might be:  Where do you think you could improve?  Are you satisfied with your [SDLC]?  What are you most concerned about? [Quality]? [Speed to market]? [Transparency]?  Encourage [clients] to be honest and realistic. It's still OK to point out to [clients] areas you feel are of the greatest concern. However, if you encourage [clients] to identify their own [software delivery]-health status and needs, not only will their [technological] awareness be enhanced, but so will your understanding of what [software delivery] issues are important to them.
  • Focus on the [highest priority] problem or goal: Most [transformation coaches] are adept at focusing on [any prioritized] problem or goal, such as reducing [cycle time] or [defects which escape to production]. However, the tendency to "scare" the [client] by discussing "worst-case scenario outcomes" should be avoided. This is not to say that [clients] should not be informed of the consequences of their lack of compliance, but be realistic. Try to focus on the positive outcomes of improving their self-care habits or treatment, such as a better [relationship with business partners], better [transparency], or [talent] retention. Enhance your credibility by providing your [clients] with appropriate resources that support your information and instruction.
  • Let the [client] explore and choose. This is the pinnacle of customization. Keep in mind, though, that the first choice that [clients] make may be that they are "not ready" or they don't see the need. [Clients] also may choose a [tool or process] that they think they will use. Help guide [them] to [solutions] that may be beneficial for their particular situation, but be sure to give them a choice so that they ultimately make the decision and the accountability resides with them.
  • Identify all possible [automated tools they can use to make this more fun], including [virtualization packages], [code quality dashboards], and [virtual card walls] that have research to support their efficacy. At this point it becomes clear that Carol A. is a representative of WaterPik, and she goes on and on about putting up a nice display in your practice, and having working demos for patients to try, and so on.  I will spare you these tips and tricks, but I think this might, ironically, be the best advice she has for us.  Change your approach from "your project is a death march, and I can prove it" to "hey, want to try some great new tools that will make you look great?"  I hadn't identified this pattern for transformation explicitly until I read this RDH blog post in a fit of rage after my last dental appointment, but think about it, who doesn't like new, fun tools?  Especially complicated ones that require new certifications that you can put on your resume?!
I believe I have quoted my wise old aunt on this point before, but it bears repeating.  "The truth is something to be very careful with."  Think of your client interactions as respectful conversations where your client always comes out feeling better about herself, but still happy to have been equipped with a new strategy.  There is no need to shout out the numbers.  And face it, most of us don't have the option to sweeten the deal by offering an hour of nitrous oxide.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …