Category Archives: Theory of Constraints

The Myth of the Genius Programmer

Nice talk on fear of looking foolish. The speakers discuss the idea that visibility is good. Don’t hide. Make everything visible and the benefit from many people’s ideas. The talk focuses on software development but is true for any work.

“criticism is not evil” – Very true. “At Google we are not allowed to submit code until there is code review.” At the bottom line they are repeating Deming’s ideas: improve the system – people are not the problem, bad systems are the problem. Iterate quickly.

Related: 10x Productivity Difference in Software Development – The Software Engineering Manager’s Lament – Respect for People, Understanding Psychology

Pragmatism and Management Knowledge

Is the Theory of Constraints (TOC) a Theory? [the broken link was removed]:

I suppose it’s a question of precision then. There are many things that you could argue are useful, if you argue backward from the end result. Yet they are not predictive, or repeatable to any degree of precision. In addition to “last things” there should also be the “next things” that a theory allows for or predicts. As a pragmatist, it’s hard to argue with results. As a Lean thinker, I have to argue for process and predictability.

There are strong ties between Deming’s ideas and the pragmatic philosophy; one paper offers a nice overview: Deming and Pragmatism [the broken link was removed].

I like George Box’s quote “All Models Are Wrong But Some Are Useful” This can also be dangerous when people don’t understand the limits of usefulness. A danger is that people believe the model is more true than it is (they don’t understand the limitations).

The pragmatists were concerned with the theory of knowledge – how we know what we know. They were very concerned with evaluating thought and beliefs. They believed in testing to determine whether theories were correct. This thinking underpins the Shewhart/Deming/PDSA cycle.

I believe the question raised in the original post is very similar to the struggle Shewhart went through in developing the control chart and Shewhart cycle. He wanted to address the exact issue of finding things that not only appear to be useful (which includes many instances of things that appear to be useful but in fact are not – we people are prone to this in many ways) but are predictably useful.

Related: The Illusion of Understanding – Illusions – Optical and Other – Management is Prediction – Experiment and Learn

Multi-Tasking: Why Projects Take so Long

From a new, interesting, Theory of Constraint blog by Kevin Fox – Multi-Tasking: Why projects take so long and still go late

In many companies the impact of multi-tasking is obscured by the fact that in spite of its prevalence most projects still finish on time. While this reliability is nice, it masks the even more significant opportunity to cut project durations substantially. If projects are being delivered on or close to schedule, and multi-tasking is occurring, it can only mean that the task estimates used in the plan are significantly inflated.
…
But understanding is not enough. The drivers of multi-tasking are built into the processes, measurements, and systems most companies manage their projects. We strive hard to keep people busy all of the time, to maximize the output of all of our resources and be efficient. Performance measures on project managers and executives motivate them to focus on delivering individual projects, without understanding of the impact of their actions on the rest of the pipeline. Conventional scheduling and pipelining tools pay no attention to these factors and routinely overload resources making multi-tasking nearly inevitable.

via: Silk and Spinach. Related: articles on Theory of Constraints – Multitasking is not Part of Standard Work – Flow – Fast Cycle Change in Knowledge-Based Organizations – single piece flow

Metrics and Software Development

Lean-based Metrics for Agile CM Environments [the broken link was removed] by Brad Appleton, Robert Cowham and Steve Berczuk:

Measure Up! Don’t use metrics to measure individuals in a way that compares their performance to others or isolates the value of their contributions from the rest of the team. The last of the seven principles of Lean software development tells us to “Optimize across the whole.” When measuring value or performance, it is often better to measure at the next level-up. Look at the big-picture because the integrated whole is greater than the sum of its decomposition into parts. Metrics on individuals and subparts often create suboptimization of the whole, unless the metric connects to the “big picture” in a way that emphasizes the success of the whole over any one part.

I agree that measuring individuals is normally not an effective way improve. And “measuring up” can often be valuable. Often a fixation on small process measures can result in improvements that don’t actually improve the end result. But rather than the measure up view, I find looking at outcome measures (to measure overall effectiveness) and process measures (for viewing specific parts of the system “big picture”) the most useful strategy.

The reason for process measures is not to improve those results alone. But those process measures can be selected to measure key processes within the system. Say finding 3 process measures that if we can improve these then this important outcome measure will improve (using PDSA to make sure your prediction is accurate – don’t fall into the trap of focusing on improving that measure even after the data shows it does not result in the desired improvement to the overall results that was predicted).

Also, process measures are helpful in serving as indicators that something is going wrong (or potentially going better than normal). Process measures will change quickly (good ones can be close to real time) thus facilitate immediate remedies and immediate examination of what lead to the problem to aid in avoiding that condition in the future.

Continue reading →

Common Cause Variation

Every system has variation. Common cause variation is the variation due to the current system. Dr. Deming increased his estimate of variation due to the system (common cause variation) to 97% (earlier in his life he cited figures around 80%). Special cause variation is that due to some special (not part of the system) cause.

The control chart (in addition to other things) helps managers to avoid tampering (taking action on common cause variation as though it were a special cause). In order to take action against the results of common cause variation the performance of the system the system itself must be changed. A systemic improvement approach is needed.

To take action against a special cause, that isolated special cause can be examined. Unfortunately that approach (the one we tend to use almost all the time) is the wrong approach for systemic problems (which Deming estimated at 97% of the problems).

That doesn’t mean it is not possible to improve results by treating all problems as some special event. Examining each failure in isolation is just is not as effective. Instead examine the system that produced those results is the best method. The control chart provides a measurement of the system. The chart will show what the process is capable of producing and how much variation is in the system now.

If you would like to reduce the variation picking the highest data values (within the control limits) and trying to study them to figure out why they are so high is not effective. Instead you should study the whole system and figure out what systemic changes to make. One method to encourage this type of thinking is asking why 5 times. It seeks to find the systemic reasons for individual results.

Related: SPC – History – Understanding Variation by Tom Nolan and Lloyd Provost (highly recommended) – Deming on Management

Fun Camping Drum-Buffer-Rope Example

Shmula Goes Camping: Drum-Buffer-Rope

Managing the Constraint is mostly about managing the non-bottleneck systems and making them “aware” how fast they should work — when they should slow down, when they should stop, or when they should increase pace and by how much. The Drum-Buffer-Rope system allows for a systems-wide awareness.

The Drum

The Bottleneck or Constraint, acts as a Drum — it sets the rhythm that the whole system should follow. In Lean Manufacturing, this is also called “Takt Time.”

Lean and Theory of Constraints

David Anderson’s post, Lean vs. TOC – No Conflict [the broken link was removed], is an excellent addition to the previous post here: Lean Thinking and Management.

I demonstrated these ideas recently by taking an updated version of my XIT Sustained Engineering paper from the TOCICO in Barcelona [the broken link was removed] to the Lean Design and Development conference and recasting all the exploitation and subordination steps as waste reduction instead.

David refers to a post, looking for a conflict, that is definitely worth reading:

This is the dilemma: “Optimize everything” conflicts with “Only optimize the bottleneck”. I like both approaches and have used them both successfully. How is it possible that two of my favourite techniques disagree?

I like the way the post looks at this question. I must admit, my personally view is that the conflict is not as stark as it may appear. I tend to believe the theory of constraints view is helpful but can be misleading since often the interdependencies within the system mean that it is not true that “optimizing non-bottlenecks will introduce waste” (that may be true but is not necessarily true – that is how I see it anyway).

These are good ideas to be discussing.

Related:

ToC Conference Recap

Thoughts on TOCICO [the broken link was removed] by David Anderson:

“Subordination happens first!” In the 5 focusing steps, the third step is to subordinate the rest of the system to the decision made in step 2 to fully exploit the capacity constrained resource. I had observed in my work with the XIT Sustained Engineering group (the subject of my paper for the conference), that the subordination actions always had to happen first before the constraint could be fully exploited. However, this is counter-intuitive given the order of the steps. As Eli reminded the audience, step 2 is “Decide what (and how) to exploit.” This then leads to a set of subordination decisions which make exploitation possible. Subordination always happens first.

Related Posts:

Management Science for Software Engineering

Management Science for Software Engineering [the broken link was removed]:

using the Theory of Constraints 5 focusing steps and the drum-buffer-rope solution for production flow problems, it was possible to increase the productivity of a sustained engineering department by more than 200%. In the final, quarter of the study period, a 25% increase (elevation) of the capacity constrained resource, produces a 25% increase in overall system throughput – just as the theory and model would predict.

Read the full paper by David Anderson, Microsoft, From Worst to Best in 9 Months – Implementing Drum-Buffer-Rope in Microsoft’s IT Department: [the broken link was removed]

Continue reading →

Critical Chain, TOC Email List

Email lists have been going out of style, but they can be a useful way to interact with a shared community (when moderated properly). The Theory of Constraints (TOC) email list (Yahoo group) CriticalChain, is useful for those interested in TOC concepts.

This list is for those who are interested in project management via Critical Chain Scheduling and Buffer Management, as well as the application of other aspects of the Theory of Constraints to project management.

The target audience for this discussion list is broad, consisting of:

Those who are experienced with Critical Chain (either by living with it or by helping others implement it),

Those who are attempting to implement Critical Chain in their project(s),

Those who are curious about Critical Chain and the implications it could have for their project environment

and . . .

Those who have heard about Critical Chain and think that it is either misguided or that there is nothing really new about it, but are willing to discuss it with an open mind. It’s this last target group that can add real spice to the discussion. (After all, as Eli Goldratt has said, “The strongest force FOR improvement is resistance to change.”)

Another good email list is the Deming Electronic Network list.