In hypnosis, the term "Apex Problem" refers to a situation where the client is cured so effectively that they don't remember ever having had that problem.
Imagine a client coming in with a fear of flying. We use hypnosis on this client and the session is so effective that he forgets that he ever had this fear. This may not seem like much of a problem until it's time to get paid for our work. Now we invoice the client for fixing a problem that he honestly believes he's never experienced. Why would he pay that invoice?
To address this problem, hypnotists usually insert "convincers" into the process to prove to the client that a change did actually happen. Although not as obvious as with hypnosis, we can see the apex problem in agile work as well.
The best coaches and scrummasters are more like catalysts than managers. They subtly change the evironment around them, often without taking any obvious credit. Work starts to flow more smoothly and teams become more effective, almost effortlessly.
People like this are vulnerable to the apex problem, just as hypnotists are. It's easy for teams to think they've always been this good, forgetting where they've come from.
This is fine if we don't care who gets the credit and sometimes we don't. Getting promotions, raises or contract renewals, however, does require that we can justify the money being spent on us. If the people spending the money don't think they're getting any value then they'll cut off that money. This is where we need our own convincers - to demonstrate that change really is happening and the team really is getting better.
We need some kind of a measurable change. Acknowledging that no two teams are exactly alike, there is no single set of metrics that we can use everywhere. There are, however, certain metrics with wide appeal; metrics that quite often give us useful information.
- Work in progress
- Average lead time on work items
- Time for the standup meeting
- Number of escaped defects
- Throughput: Number of work items completed in a fixed time period - often a week.
The convincer isn't any single number; it's the trend of either improving or not. Are defects increasing or decreasing?
Note that "velocity" and "code coverage" are both particularly bad convincers as changes in either of these will not prove anything about actual improvement. Avoid using both of those.
A good convincer would be: "We're completing twice as many items per week than we were three months ago" or "Defect counts are a third of what we had six weeks ago".
So while you may not care who gets the credit in most situations, when it comes time to justify why people continue to pay for your services, you need a convincer. Make it part of your process to prepare those.