How I use a combination of Flow, Lean, the Theory of Constraints to identify the root cause of a problem and fix it.
I do not believe that any one approach, no matter how powerful, is always the best one to use.
I have seen that a combination of concepts and practices from Flow, Lean, and the Theory of Constraints works well.
Each of these provides useful insights:
Theory of constraints.
- emphasizes the importance of identifying, and alleviating, the limiting factor (e.g., constraint) of the system producing value.
- inherent simplicity – the idea is that reality, any part of reality, is governed by very few elements, and that any existing conflict can be eliminated. And that if we dive deep enough we’ll find that there are very few elements at the base - the root causes - which through cause and effect connections are governing the whole system. (from Eli Goldratt’s The Choice).
Lean, which is partly based on Deming, tells us to distinguish between common cause (caused by the system) and special cause (caused by some special event).? It’s principles of value, value stream, flow, pull, and perfection (Womack and Jones Lean Thinking) provide us with insights from the value stream – that we must take a holistic view and that where the problem is, is not necessarily where the cause of it is.
Flow tells us that working on too much work creates delays in the workflow, delays feedback, and creates waste. Multitasking is a common symptom of this. It also tells us that we a lack of visibility causes similar problems because a lack of visibility also causes delays in the workflow.
Attempting to find the system constraint takes a global perspective.
Systems often have many blockages in them. If they appear to be of a common cause it’s likely that these blockages are a symptom of something elsewhere in the system.
For example, if I were to go into a community and see multiple flooded houses I wouldn’t ask “what was going on inside the houses?” I’d be asking “what caused all of the houses to flood.”
In knowledge work, it is usually possible to look at a handful of principles and the factors for effective value streams (Eli Goldratt’s inherent simplicity applied to knowledge work) to discern what the root causes for challenges are.
A few of these are:
- work on small items (Flow, Lean, and Goldratt)
- remove delays in the workflow
- create visibility across the organization
See the attachment for a more complete (not full) list.
Here are some examples of what clients I’ve worked with have done. While not shown here, each of the case studies have been repeated many times.
Case study 1. A group of teams was spending an inordinate amount of time doing final testing when more than one team was involved in a piece of function.
Suspected constraint - teams were not testing together. This was causing a significant amount of extra work consistent with what would be expected.
Solution was to have teams work on multi-team functionality together, deferring the individual team pieces to fill in the gaps. This was known to speed up testing and eliminate extra work to complete testing.
Savings: 63% increase in throughput, 42% decrease in defects, greater than 22% savings* ($1.73M) [Thought to be higher, but underreported for political reasons]. Investment cost? 2-3 days consulting, 4 days coaching. Less than $20,000
See a writeup of this case study: Dynamic Feature Teams: Creating Small Mobs Within a Large Group (Case Study).
领英推荐
Case study 2. Problem: effective Scrum teams working on the same product were having difficulty integrating their work.
Suspected cause: teams were working independently on their part of the product. This was causing integration errors since it often couldn’t be done until each team had completed their part of the product. That is, incremental integration was not possible.
Solution: when splitting up the requirements to the teams, order the work to be done to be in the same sequence across the teams by having a shared backlog. This enables the teams to create a small amount of functionality and integrate it immediately.
Savings: Prior to these changes integration was taking 25-50% of the time that development was taking. The time for integration dropped significantly with the shared backlog. Investment cost? Less than $10,000.
See a writeup of the case study - Coordinating Teams with Backlog Management.
Case study 3. Problem: After 5% of the installations of custom-built websites, the sites would have problems and the team lead would have to stop what they were working on and fix it.
Suspected cause – the original constraint was identified as poor-quality code. After doing a high-level value stream map and doing Lean’s “Five whys” on the problem, it was discovered that customers were not properly configuring their systems due to a failure in the sales process to notify them of this need.
Solution: Change the sales process so that customers properly configured their servers.
Savings: 20% of the cost of their 100-person development group. Investment cost: $5,000 for two people to come to a Lean-Agile Software Development workshop.
See a write up of this: Using Value Stream Mapping and ‘Five Whys’ to Get to Actionable Cause.
Case study 4. Problem: teams were working independently of each other, and no one had an overall view of the work in the company. This was creating delays in the workflow, severe multitasking, and no one knew when things would get done.
Suspected cause: no intake process existed.
Solution: Create an intake process where management could see what was being done and could prioritize the work to avoid overloading teams.? This also enabled the teams to see what was coming their way which further lowered delays in the workflow.
Savings: No metrics had been in place prior to the change but management reported that there was a significant improvement in projects being completed and the mood in the company had greatly improved. Investment cost: About $6,000.
More insights
Of course, after solving one constraint, others will show themselves.
Sometimes there are multiple causes to a constraint. Therefore, I believe that while working on the constraint, it is often a good practice to do general improvement as well. This sets up the organization to be more efficient overall which allows for moving capacity to the constraints as new ones show up.
An example of this is reflected in Eli Goldratt’s statement “sometimes working on small batches are all it takes to bring a system back into control.”
Want to learn how to see more cause and effect in your work and what to do about it? Success Engineering offers several learning journeys. In particular, the Amplio Consultant Educator and Amplio Business Agility journeys should be of great interest.
Contact Al Shalloway for more information.
?
Just a few notes: 1. Inherent Simplicity, and Every Conflict can be Removed, are two separate independent "Pillars" or principles of Theory of Constraints (ToC). 2. The only way to distinguish common and special causes, is with statistical analysis -- which can be done simply, using a control chart (and the "individuals" chart, of x and mr, is simple enough that 5th graders can use it. And yes, I tested it with 5th graders... And, of course, statistical analysis requires data -- you have have to measure things, to have data to then analyze. And note that a particular cause can be common for one team, and special for another team in the same department. Which I've seen in actual practice... 3. In ToC, there is a clear difference between the "biggest problem you have now" and the "constraint of the system". ToC works on the latter, not the former. There is nothing wrong with doing a Pareto analysis, identifying the biggest problem, and then working on that -- but that's not ToC (which focuses on system improvement). That's process improvement, which Lean and Six Sigma excel at. They "solve" the problem, and it drops off the list. A constraint is exploited, subordinated to, and elevated -- but generally stays on the list.
I was asked offline "When you get the time, and the interest, I’d love to understand in detail just how you apply “Inherent Simplicity” in Amplio… This Pillar of ToC is beloved in the abstract, but finding actual applications of it, that hold up to rigorous logic, is… difficult. Do you have an Amplio example?" Since 2006 I have been looking for principles of knowledge work. I had gleamed a lot of these from books like Principles of Product Development but also via interviews with people. I read "The Choice" in 2018 and realized what I was looking for was inherent simplicity: "If we dive deep enough, we’ll find that there are very few elements at the base - the root causes - which through cause-and-effect connections are governing the whole system.” “Inherent Simplicity. In a nutshell, it is at the foundation of all modern science as put by Newton: ‘nature is exceedingly simple and harmonious with itself.’ I attached what I have distilled as these few things controlling knowledge work. Then I created the factors for effective value streams. See attachment.
As a general comment, I love hybrid approaches that combine methods (such as Theory of Constraints) into new approaches, that tackle new challenges, in new situations. Like Amplio…
Business consultant dedicated to fostering sustainable growth and optimizing profitability for SMBs and startup founders.
1 年Eduardo Alejandro Hurtado Flores
Business consultant dedicated to fostering sustainable growth and optimizing profitability for SMBs and startup founders.
1 年It is useful for you Dario Andres Palminio Choy