ToC transition tree improved

Rami Goldratt (Eli’s son) has published a paper detailing his improvements to the form of the standard TOC Transition Tree. You can read it here (PDF file), courtesy of Clarke Ching. (By the way, nice bit of name-dropping there Clarke – “A few years ago Eli Goldratt told me…” !)

Lack of visibility can be the bottleneck

Making targets and their associated metrics more visible can be the most important factor in achieving those targets. That’s the message behind the agile notion of Information Radiators or Big Visible Charts: the visibility itself is a critical component of their success. Today Shawn Callahan tells an anecdote in which it seems the increased visibility of a target and its metric served to dramatically change employee behaviour. He relates a story from Pfeffer and Sutton in Hard Facts, Dangerous Half-Truths, and Total Nonsense in which a shipping company wished to save money by bundling small orders into bigger boxes. The policy wasn’t being followed, so:

“So the company announced a new program that provided rewards such as praise—not financial rewards—for improvement. On the first day, the proportion of packages placed in the larger containers increased to 95 percent in about 70 percent of the company’s offices. The speed of this overwhelming improvement suggests that a change in performance derived not just from the rewards that were offered, but also from the information provided that the current performance level was poor and this action—consolidating shipments—was important to the company.”

As Jack Vinson suggests, the relative invisibility of the target behaviour and its measures could well have been the constraint on that business at that time. The anecdote is from the 1970s, too early for the business to have used the ToC thinking tools to diagnose the situation, or for the metric’s increased visibility to have been the result of applying the five focusing steps (identify, exploit, subordinate, elevate, repeat).

For me, the lesson from this story is that the constraint is as likely to be in knowledge management or communication as anywhere…

people problems vs process problems

dunce 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.”

Pascal goes on to resolve the conflict by noting that it is a mirage: fix the “people problem” immediately, and then fix the “process problem” so that same class of problem can’t recur. Aside from dubious use of the term “people problem”, these are the classical elements of the jidoka method: detect, stop, fix, prevent.

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.”

Dave, though, brings the question around to organizational culture:

“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.”

thinking at SPA2006

This year my stay at SPA2006 is limited to only one and a half days. Nonetheless I plan to attend some interesting sessions, and in the next few posts I’ll describe my impressions of them. The first of these was Thinking for a Change:

In this 3-hour workshop Pascal van Cauwenberghe and Marc Evers led us through the construction of two of the five Theory of Constraints Thinking Tools. We divided into groups, such that each table comprised one “customer” – someone who had a problem to be solved – and a number of “consultants”. The objective was for each group to build a Current Reality Tree for their customer’s problem, and then to build a Future Reality Tree for a possible solution. The problem on our table was set by Emmanuel Gaillot, who wanted to understand some specific behaviour of the managers in an organisation he had worked with.

Now, I had already read the book Thinking for a Change, and frankly found it quite disorganised. Pascal and Marc had also found the same, so for this workshop they had picked through the book and defined a step-by-step process for building CRTs and FRTs. They took us through this process just-in-time, at each stage showing us the next step using their worked example, and then giving us 5 minutes to perform the step on our own problem. This made for an absorbing three hours, in which we actually got to try the whole process from end to end on a real-life situation.

Unfortunately our group got a little bogged down at various times, mostly due to our particular problem being way too large to solve in a dozen 5-minute chunks. Nevertheless we had fun, and we gained practical experience of building a CRT and a FRT.

multi-tasking in the news

Over a year ago I wrote about the muda of multi-tasking and the delays it will inevitably cause. I had been prompted by the planning approach used by my client at the time, and by a rush of articles in various blogs and magazines, and this week it’s happening all over again. Kathy Sierra discusses a recent cover story in Time magazine (and there’s lots to read in the comments on her blog, too). And a quick search on Technorati suggests the article has opened another flood of blogging on the subject.

multi For me, the best explanation of the problems caused by multi-tasking still come from the Theory of Constraints world. A good straightforward description of the theory can be found in Frank Patrick’s Multi-tasking Multiplies Lead Time. ToC shows that multi-tasking slows down every task we’re working on – and that’s in addition to the psychological effects reported above.

When I adopted David Allen’s Getting Things Done, one of the first changes I made was to fix my email so that it only updated twice each day. I was addicted to intermittent variable reinforcement, and to be truthful I probably still am. It’s an invidious form of multi-tasking, because it seems as if I’m only checking email, webstats, bloglines etc during “breaks”. Unfortunately, if there’s something interesting to read the break expands and delays whatever I was supposed to be doing. Time to find a cure and remove this one source of muda from my day…

Goldratt’s Theory of Constraints shows why multi-tasking delays everything we do and everyone who needs to work with us. Over a year later, I still haven’t learned that lesson.

the product owner must pull (revisited)

In the product owner must pull I described what can happen when there are not enough stories in the pile. Here I want to look at the same problem from a slightly different angle: in terms of the Theory of Constraints.

The development team’s throughput is low. TOC says that the organisation must therefore include a Constraint (a bottleneck). The Constraint is the major factor in causing that poor productivity, and our first step is to IDENTIFY it. In software development, one of the easiest ways to find bottlenecks is to look for stuff piling up. In this case we find that the constraint lies outside the team, in the person/process/team that creates the story pile. There are piles of visions, wishes and capabilities waiting to be analysed, but downstream there’s no work for the developers to do. The constraint is the analysis function.

Our second step must be to EXPLOIT the constraint – to get it functioning on full power. In iterative backlog management I adopted Scrum to help the analysts generate stories and incrementally build a pile of stories for the developers to work on.

Third, we must SUBORDINATE everything else to the constraint. In this case we decided to stop development for one iteration. In lean manufacturing terms the development has no customer pulling features. So instead the development team will carry out some maintenance work: refactoring the codebase (tidying gemba), improving test coverage, installing new tools etc. (As things turned out, analysis generated some high-value stories quite quickly, and so we were able to re-start development on those stories before the end of the current iteration.)

Fourth, we must ELEVATE the constraint. Which means we must look for ways to make the current constraint more productive, or else eliminate it from the production flow. In our example this probably won’t be an issue. As the analysis team settles into being proactively managed it looks to be capable of creating stories faster than they can be developed.

Which leads us to the final step: we must PREVENT INERTIA and re-start the process with step one. Now that analysis is creating a story pile and development is working on it, we need to IDENTIFY the system’s constraint all over again. This time it will be somewhere different, and again we’ll find it by looking where things seem to be piling up…