This post originated from an RSS feed registered with Agile Buzz by Kevin Rutherford. Original Post: people problems vs process problems Feed Title: silk and spinach Feed URL: http://silkandspinach.net/blog/index.xml Feed Description: kevin rutherford on agile software development and life in macclesfield Latest Agile Buzz Posts Latest Agile Buzz Posts by Kevin Rutherford Latest Posts From silk and spinach

A good deal has been written recently on the origin of problems that occur during software development. Pascal started the ball rolling by noticing an apparent conflict between Weinberg and Toyota:

"... Gerald Weinberg tells us that Whatever the problem is, it's always a people problem. [...] The Toyota Way states that Whatever the problem is, it's always a process problem."

Then Marc followed up by proposing that it's a false dichotomy:

"Processes (by which I mean the things and actions that actually happen in a system) are the manifestation of what the people involved have learned - of both their explicit and tacit knowledge. People and processes are two sides of the same coin. The way to improve your processes is to improve your people."

"IMO the key question is, How does the organization — which comprises people (who have a culture) — react reflexively when things are going badly? Is the tendency to fall back on adherence to formal processes, or to facilitate people's ability to find creative solutions?"

I've raised Pascal's original dilemma a number of times recently during my jidoka workshops. At some point I'll inevitably make a bald statement that I believe every problem is a process problem (and no problem is a "people problem"). But then I find the resulting discussion revolves around some participants' interpretation of the word "process" as being equivalent to "procedure". And my point is lost forever. So here I want to re-cast the debate, hopefully in terms that are unambiguous.

First, what do we mean by "problem". I take the term to refer to any reduction of productivity in a system or organisation. In TOC or lean terms this usually translates to a loss of throughput or flow - the problem boils down essentially to one of the seven types of muda - but it can also apply to an increase in operating costs without a corresponding increase in throughput. And I think we're using the word "problem" above to refer to two different things:

incidents

The bad things that happen and which trigger us to look hard at our system. TOC (the theory of constraints) calls these UDEs - Undesirable Effects. I prefer to call them incidents to reflect their uniqueness and their immediacy.

root causes

Those attributes of our system that lie at the heart of the observed incidents. Any given incident will have a single root cause, if we broaden the scope of our system far enough.

And by system I mean that collection of processes, procedures, situations, knowledge, structures that make up the environment in which the incident occurred. The system may be a single department and all its working, or it may be the broader organisation comprising the whole company.

So above, when I talked about "process problems", I intended to refer to any root cause that is ultimately responsible for causing an incident. This will be some attribute of the system we're operating within. It may be that the system didn't encourage two people to talk to each other, or didn't ensure adequate knowledge in its workers, or comprised an incorrect flow of materials, or failed to embody a quality check at some point, or whatever.

So, trying to be perfectly clear: I believe that the reductions in a system's productivity occur because of the structure and behaviours of that system. Randomly switching people around might cause different incidents to actually occur, but in every case it is the system that permitted those incidents, and the system's attributes that ultimately caused them. It seems to me that looking for people problems is about as smart as blaming the laser printer for a badly spelled document. People are not the problem. Ever.

I leave the final word to the Lean FAQ of the Northwest Lean Networks:

"If your '5 Why' exercise seems to be pointing to 'operator error' as the root cause, you are going down the wrong path. Operators only do what our production systems allow them to do, so the root cause is in our systems, not our workers."