Tuesday, October 23, 2012

"What is your problem?" - Part 1: Know your facts

“What you have is not [information], it is the precursor to a conclusion.”

For the Agile practitioners out there, I double as the scrum master for a scrum of scrums. At some point someone tried to declare me a “ Master of Scrum Masters”. With my organization designating my official role as “Chief Programmer”, it has become clear my titles have far surpassed my real scope or abilities. I am sure somewhere in the career planning circles someone is thinking of “The One”  or “Master Chief Programmer” as credible job titles.

I digress, I really want to write about the most critical aspects of these [daily] meetings, which is to understand the current commitments of the teams, what may be blocking their work, and whether a team (or person) is about to do something that could affect other teams.

For us, these are supposed to be 30-minute meetings, with each scrum master representing the results of the standup meetings they just held with their local teams. Whenever a problem is blocking work, it is the scrum master’s responsibility to help the person reporting the problem to figure out a solution. Sometimes the solution is to go pester the person causing the block, sometimes the solution is to go find someone who has the right skills to answer a seemingly impossible technical challenge.

Across all blockers, there is an urgent need to determine what is the problem before any help can be procured, which brings me to the point of this posting: what is your problem?

Beware of retired managers 
A few years ago, I had the pleasure of attending a seminar with the grumpiest of all former managers. Over the years I learned to appreciate grumpy people who happen to be knowledgeable, and this person made a living as a “critical thinking” coach. He was in his mid 60’s and followed retirement with what I think to be his true calling. He would coach people ranging from the neighbor running the parish’s raffle to VPs and CEOs planning their succession. Straddling the chasm of these situations, he helped people break down their problem descriptions into bits of information that led to decisions.

I had the opportunity to talk to him for a couple of days and here is the amazing part: he needed little to no initial skills in the problem domain to help people solve their problems. He acted as a mirror, continuously asking questions about the problem until the person slapped his own forehead in disbelief for not having thought of the final solution before.

The grumpy part meant he was obsessed with precision in communication. His problem-solving technique required a clear understanding of the facts and their context, which made him develop another valuable skill: the ability to interview his interlocutor in a methodical way, with strategies that ranged from a simple conversation to cross-examination of a hostile witness, all depending on the other party’s ability to surface and convey the facts relevant to the decision. It was not rare for him to interrupt people mid-sentence after a string of vague statements. Someone starting with “We had some issues with the parts we ordered a few days ago” would quickly be found under a mudslide of questions. “Which issues, which parts, who did you order it from, how many days ago, has it arrived, if not, when it is due…son, are you still conscious?”

There was considerable technique to his barrage of questions, which I try to represent here and map to my professional world of software development. There was more to his strategy, which is beside the point of this posting, on how to use the information acquired through this process to form a decision. One should look at the list below as the minimum set of questions and be prepared to adapt them to the domain at hand:

  • What is the expected behavior from the product?
  • What is the observed behavior in the product?
  • Does the reported problem happen to all units of the product?
  • Does the reported problem affect the entire product or just portions of it? If so, describe the portions?
  • Does the reported problem happen in all locations where the product is used? (this forces the problem owner to have actually sampled the problem in all locations where the product is used) ?
  • Does the reported problem happen in combination with other problems?
  • When did the problem start? If you don’t know, make it clear you don’t known and state when you first observed it?
  • What is the frequency? Continuous, cyclic, or random?
  • Is the problem specific to the phase in the product life-cycle?
  • Is the symptom stable or worsening?
Complete phrases, complete thoughts

In his method, there is always the expectation for complete phrases, with a clear subject executing an action against a noun and the purpose of that action. The point here is to establish what must happen, what is not happening, and when the deviation started. The consequences of behavior gaps are the subject of decision process discipline and not applicable to the strict discipline of problem reporting.

Any kind of report must be either fact-based or clearly stated as an assumption. For instance, when claiming that a problem only happens in parts manufactured in Japan, there is an expectation that the problem was checked with all other plants that manufacture that part.
Let’s pick one example apart:

“We had issues completing the  assembly of the last batch. Some parts were bent in the corners; they started last week, but we are confident we will have them solved in the next couple of days if we can have assistance from Chris and Markus”.

Though seemingly clear, this is a somewhat incomplete report that will require a number of clarifications to be transformed into a set of decisions. Not a complete list, but I’ll list some of the omissions:
  1. On “We had issues”, was the assembly of the batch actually completed despite the issues or is the assembly of the batch waiting on the problem being fixed? If not completed, the next line of questions will be around disruption to a delivery date and interim actions if the delay affects a customer.
  2. Were the resulting units different than normal? Were all units receiving bent parts defective?
  3. Were bent corners the complete extent of the issues in the batch assembly?
  4. What is the help needed from Chris and Markus? Are they being required to procure non defective parts, are they being required to configure the machinery to work with different tolerances?
  5. On being “confident”, the people being informed of the problem are usually being informed of it because they are stakeholders or process owners responsible for the final work, so *they* need to be confident. A loose report like the above tends to have the opposite effect on the recipient, by having the lack of dominion over the facts cast a shadow on the reporter’s ability to fully assess the situation and what is needed to resolve it.
Now here is a more collected version, with the bag of facts organized into a full picture:
“We could not complete the assembly of the last batch of micro 765 boards. Over 80% of the antenna connectors were bent on the corners and could not pass the sample pre-inspection phase of the assembly process. The defective antenna connectors were delivered to us on Tuesday and now we need an urgent supplementary shipment by Friday to complete our delivery to AeroCRT on time by next Wednesday.

Chris, in Markus department, was able to procure antenna connectors with a secondary supplier in a similar urgent situation two months ago, and tells me he needs someone to cover for him for a day while he works through our procurement process. As for the defective antenna connectors, we have already contacted the supplier and I can brief you on how we will handle the return of parts and reimbursement process.”
It, theirs, him…who are you talking about?

Problem reports and some pronouns are mortal enemies. Multiple actors and subjects are very common in a problem report, and the recipient is trying to piece these facts together at far higher levels of abstraction than grammar. The concentration required to create these abstractions while receiving a report is easily broken when you are trying to divine which of the multiple actors is being referenced by “it” or “him” in a sentence.

While repetition of names and subjects may be a sin if you are writing a novel that will last generations, it is completely forgivable in a report that will not live for longer than a few days or weeks before the problem is solved.

The power of context

The most common question I hear on the subject of this posting is “how much information is enough on a report? If I provide too much, I may be wasting time on information that is obvious. If I don’t dump everything from my brain, I may be perceived as negligent”.

The answer to that question is in the shared context between people, an essential foundation of effective communication. People who work in the same part of a project can communicate more quickly because they need to transfer less context in each exchange. They can use “that problem from last week” with far better results than someone with whom they did not spend time at all last week. Conversely, being able to realize the full extent of shared context before each information exchange is as important of a communication skill as it is conveying that context. In that skill lies the fine line between being trite and being vague.

Upcoming part 2

In the second part of this article I want to extend this first part into the software engineering discipline, using examples such as write ups of Agile stories, defect reports, and many others.

Featured Post

Crowds in the clouds, a brave old world