Five Whys, Socratic Method, and Dependent Arising

Root cause analysis—jargon for managers in lean startups and Agile dev shops. In plain language, isn’t it “Well, I hear what you’re saying, but what’s really going on?”

I feel a rambling, messy first draft coming on.

Why in the world do we need jargon for such a common line of reasoning? This is every day stuff, isn’t it?

  • Parents ask each other in whispers at night: “But why is she acting out like this all of a sudden? Is it those kids at school again?”
  • A doctor sees the symptoms and begins to diagnose the cause.
  • Marriage counselors around the country today coached couples to understand their partners a little better.

Yes, and an Agile team somewhere held a 5 whys session to figure out how that persnickety bug made it through testing, so that they could address the root cause.

Oh, pardon my cynicism, I have trouble writing that line with a straight face; if the team didn’t actually discern the root cause (there’s always just one, right?), they will have at least changed something to avoid one of the causes. How else to get better, really?

I’m being too jaded. Of course root cause analysis, the 5 whys method is one tactic for such analysis, is important. I just cringe at the assumption of a single cause for problems. And those technical problems that are found with lean and agile work often end up (or is that start off as) being human problems, and those are rarely so singular.

In design work, I really don’t know that I’ve asked the question, “So, what is the root cause of this problem?” Though I have most often sought to understand and clarify the problem space, the context, the people involved, their desires and motivations, the corporate interests, et cetera—you know, the basic stuff a designer needs to know in order to actually do good work [PDF].

I simply cannot right out of the gate assume I know what I don’t yet know so well that I would presume it, if it is indeed an it, is a singular problem. The result of that kind of simplistic framing would tend towards imprecise assumptions and lack of multiple perspectives. A lack of understanding. And don’t those sound like further problems that could result in errors? Garbage-in, garbage-out.

So, if I can kick the feet out from under Agile’s dumbed down root cause analysis and just stick with something more like defining the problem, or semantics (as Vignelli has used it), I’ll relax on this point.

Can I assume that this better understanding is what we’re all actually after?

I was in a meeting once, asking deeper questions, and a person I was talking with was frustrated and said something like, “I know all about five whys, I know what you’re doing!” The person was asking me to back off, because he wasn’t prepared to answer questions. While that does make the point to me that I was pushing too hard, I wasn’t expecting the five whys remark.

I was actually patterning the discussion more off of Socrates and his dialogues. I’ve heard the term Socratic Method being described as continuing to question, to ask why. Well, yeah, that sounds like a 5 whys, but I’ve read Plato enough that I understand that those dialogues are far more nuanced than a series of whys.

Wasn’t the philosophical discourse of Socrates and his learned colleagues some sort of root cause analysis too? Is a discourse into the nature of the soul and idealized Forms an analysis? Of course, and there is an aspect of Phaedo that suggests that these Forms are in fact causal forces. I’d call that root cause analysis.

So, this type of “what’s really going on here?” question isn’t just for work any more, it’s for philosophy and an understanding of the world itself (yeah, even though we all believe Socrates had it wrong).

And this question of the underlying problem is common too in religion, isn’t it? What’s wrong with the world? With us humans?! I call a five whys for the fallen world!

I joke, but Buddhists might associate this notion of root cause analysis with another bit of jargon: dependent arising.

As I’ve learned, when Gautama sat in profound ascetic meditation under the Bodhi-tree, nourished by an offering of rice milk, and under the gazes of the gods of many world-systems, he finally received enlightenment. In his awakening under that auspicious tree, he knew what are called the four noble truths (knowledge of suffering, cause of suffering, cessation of suffering, and the path that leads to that cessation).

And yes one of those truths, central to a major world religion, is the root cause of suffering! (Oh, if only an Agile 5 whys was so profound!) The cause of suffering is actually described as a nested layering of causes, which finally reach that singular kernel that causes suffering (duhkha). This is the notion of dependent arising, that suffering arises dependent upon all these other links in the chain. When I read the series of links, I still don’t think it comes down to a simple answer, but the answer itself isn’t the single cause, but the whole chain of dependent arising is part of it. You don’t disassemble it so much as sidestep the whole chain. And yes, that’s quite an oversimplification. Here’s a bit of that root cause analysis as dependent arising (there are 12 links/nidana).

Conditioned by (1) ignorance are (2) formations, conditioned by formations is (3) consciousness, conditioned by consciousness is (4) mind-and-body, conditioned by mind-and-body are (5) the six senses, conditioned by the six-senses is (6) sense-contact, conditioned by sense-contact is (7) feeling, conditioned by feeling is (8) craving, conditioned by craving is (9) grasping, conditioned by grasping is (10) becoming, conditioned by becoming is (11) birth, conditioned by birth is (12) old-age and death—grief, lamentation, pain, sorrow, and despair come into being. Thus is the arising of this whole mass of suffering.
(Gethin, The Foundations of Buddhism, 141-142)

This doesn’t strike me as mono-causal, even though it sounds like it at the end of the chain: death results in a whole mass of suffering. Well, how do you get rid of death, then? Will you get rid of birth?

Right, and so the whole tangled up ball of yarn gets pulled along. There are many causes, and there are many results. This strikes me not just as dependent arising, but interdependent arising. Duhkha, I shake my fist at you!

So, again, this root cause analysis thing is all over the place: work, family life, health, philosophy, religion. But doesn’t it tend to not be simply understood as singular causes? (Christianity seems easier to me, until I try to put a finger on where exactly original sin came in: fruit, gullible Adam, Eve, serpent, why was the tree there to begin with? It gets messy too.)

Let me end this rant, I mean blog post, by saying simply, using terms that suggest we think of single causes to complex problems is foolishness and it bugs me.

(Oh, and the 5 whys method looks a lot more like dependent arising to me than the Socratic method.)

UX and Project Mangement cross-over article from Interactions magazine

A Taxonomy of Models Used in the Design Process by Joanne Mendel in the Jan + Feb 2012 edition of Interactions magazine is pretty interesting.

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

Does Kanban hurt Agile teams by decreasing iterative development?

Workers welding on an automobile assembly line.
Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Let’s stop playing Frankenstein

Consider the monster from Mary Shelley’s Frankenstein:

The creature is described as being about eight feet (244 centimeters) in height, with translucent yellowish skin that “barely disguised the workings of the vessels and muscles underneath”, watery, glowing eyes, flowing black hair, black lips, and white teeth. (http://en.wikipedia.org/wiki/Frankenstein%27s_monster#Appearance)

I read that phrase describing the skin of the monster, that it “barely disguised the workings of the vessels and muscles underneath.”

My hands have worked on Web pages that were little more than that yellowish skin.

It’s no wonder customers fled in terror.

By now, most of my nameless monsters have died off, thanks to the hyper-life-cycle of the Web, but recently I gained a new perspective of how ungainly, ill-proportioned Web sites are created.

HOW TO MAKE A MONSTER OF A WEB PAGE

If you want to create a monster of a Web page, the trick is quite simple: Work, work, work at it, one page at a time. Write the code, make it work, make sure the forms submit. Whip up some error text, insert some confirmation screens. Check the boxes on your to-do list of functional requirements. Light it up, and let it out onto the world.

But wait…isn’t that how most of us get our jobs done? These days, we like to call this kind of heads down, busy-work “Agile.”

HOW TO STOP PLAYING DR. FRANKENSTEIN

Step away from the keyboard, Doctor.

Pick up a pencil. Draw out the whole process from the point of view of each actor, be it a person or some agent like a search engine robot. Draw pictures using easy graphics, like Garrett’s visual vocabulary palette, and be sure to include every point of contact with an actor.

Having done this recently, it became clear immediately that there was a series of email messages interspersed amongst Web pages, and that those emails were as important as any single Web page.

Also, the timing of those emails was important. For instance, Jim uses a Web page to send an email message to his friend Bob. Jim then sends an instant message to Bob asking if he signed up yet, assuming that Bob did in fact receive that email message and was able to decipher it. Those are two tough assumptions.

Each piece of a larger process overlaps with its adjacent pieces in a series of feedback and feedforward communications. Once we have these communications, these pages, emails and so forth, laid out with balance, proportion, and clear purpose, a more beautiful creation can take hold.

Nurturing and shaping this flow of interactions between people using a system is a great step in putting an end to the monsters we’ve become so good at creating.

Once we’re into this process, we invariably realize there are many more questions to ask, but the point is this: Design processes, not pages.