What’s Deming Got To Do With Agile?

When I show the Kanban board, a tool that is borrowed from Lean,I hear,

“Well, software development is an artistic process – you can’t apply manufacturing principles to it.”  

Or, “I was involved in a Six Sigma (or TQM) project that was devastating – Lean doesn’t translate to software development.” 

Or, “Analysis, Development, Acceptance, Production – that looks like waterfall, haven’t we gotten past waterfall yet?”

So let me be clear up front – some amount of software development is creative, you can’t directly apply manufacturing principles to software development, applying Six Sigma and TQM to software development like it is a production line is destructive, and in most cases waterfall doesn’t make sense in software development.

Deming is About Culture – Not Manufacturing and Not Process

But Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work. As I discussed last week, Deming’s System of Profound Knowledge has four points: 1. Understand the System, 2. Understand Variation in the System, 3. Have a Theory of How to Act on The System, and 4. Understand Human Psychology. How does Kanban help us inform the context and culture of the team performing development to achieve the benefits associated with Deming’s System of Profound Knowledge?

What Does it Mean to Understand the System?

By understanding the system, participants can operate in a way that everyone (management, performers, customers, and suppliers) benefits. Understanding the system is difficult – typically everyone views the system from their own siloed perspective. Understanding the system requires that everyone rise above their siloed perspective to understand the system goal, what the organization does to achieve this goal, the boundaries and constraints, and the sensing and  feedback mechanisms.

Kanban helps participants understand the system by making the goals, capabilities, and boundaries explicit. The participatory nature of developing and interacting with the board changes everyone’s perspective from a siloed view to a focus on system level success. The board itself, metrics such as the CFD, the establishing of policies and tracking of.performance against those policies provides feedback on the system.

How do we understand the impact of variation?

Variation is inevitable. The size of work that needs to be done isn’t uniform. The complexity of work has high variability – not just between work items – even between the types of work to be performed on each work item. For example, one item may be hard to analyze but turn out to be easy to build and test. Another may be easy to design and build but very difficult to test. It is common on teams for there to be a significant gap between the most skilled developers on the team and the less skilled developers. So the work is of various sizes, with various levels of complexity, being worked on by various levels of performers.

Kanban helps with this in three ways. First, limiting WIP reduces the overall impact of variation on the system. Second, the Kanban board makes the impact of variation explicit. One a daily basis the team can work together to allocate themselves to adjust to variation in real time by swarming or influencing what they pull. Finally, by managing the average lead time – and not trying to manage exact lead times of every item – Kanban helps smooth the impact of variation on the promises (SLA’s) make to the business.

Theory of Knowledge or “What are you prepared to do about it“?

Using the information you gain from your understanding of the system and insight into variation on the system you apply PDSA. You will see this expressed as PDCA (Plan, Do, Check, Act) or PDSA (Plan, Do Study, Act). I like to use Plan, Do, Study, and Adjust. Plan-Do is typical management – this means take specific actions that you hope will achieve a specific result. An expectation of Study-Adjust allows the organization to learn rather than blame.  A culture of continuous improvement emerges where PDSA is practiced.

Kanban delivers a platform where the organization can practice PDSA. Through metrics, operations reviews, the Andon, and potentially retrospectives provides the ability to make a hypothesis about the system (Plan). Then they can make policy, process or organizational changes with the intention of achieving an improved outcome (Act). The system will expose whether the desired outcome is achieved (Study). Then the team can learn alter their theory of knowledge and adjust their actions. The transparency of Kanban helps develop our theory of knowledge and gives us courage to act on the system.

How does Kanban impact Human Psychology?

Employee engagement is a key to the successful performance in organizations. Organizations with high employee engagement have a much higher rate of employees who show a strong passion for their work and a commitment to their co-workers. Therefore it is not surprising that organization’s with higher levels of employee engagement also have higher levels of employee productivity. Employee engagement arises when employees believe they positively impact the quality of the organization’s products.

In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities. By breaking down silos and creating insight that results in employee engagement, Kanban leverages human psychology to help organizations transform and mature.

Kanban supports Deming’s System of Profound Knowledge

If you equate Kanban with manufacturing you won’t be successful. You need to understand what Deming has to say about knowledge work and how management is responsible for creating an environment for success. Kanban brings an easy to implement – low friction implementation of Deming’s philosophy.  Implementing Deming’s System of Profound Knowledge through Kanban is a proven method for achieving higher levels of maturity and improved performance.

Tags: , ,

6 Responses to “What’s Deming Got To Do With Agile?”

  1. Daryl Kulak says on :


    I disagree very much.

    Six Sigma, TQM and Lean stake their claim to Deming, but Deming always kept his distance from these (although several appeared after his death). I’m convinced Deming would have thoroughly hated Lean.

    Deming applied his systems approach to Toyota, who needed to produce cars at the rate of demand. Taiichi Ohno then created the Toyota Production System, using Deming’s approach. If you are not trying to produce cars at the rate of demand, you should be solving other problems, probably with other tools. Applying tools like kanban, takt time, value stream mapping, etc. is exactly the opposite of what Deming is telling us.

    Deming says “study your system THEN find tools to fix the problems you see.” With the entirety of Lean Software Development, we are trying to find places to apply tools. Even the Lean gurus like James Womack admit that. Tools that came from a company trying to produce cars at the rate of demand.

    So if we try to apply Toyota’s Production System to an Agile team room, a car becomes a requirement/story? Isn’t that kind of far-fetched? Wouldn’t a car requirement become a software requirement? If you start to do that, you see that there is more connection between designing a car and designing software. And Toyota does not use the Toyota Production System to do that. They use the Toyota Product Development System instead.

    It’s okay to use metaphors to try to explain things, but all I see with Lean, in manufacturing or software development, is a set of tools taken from a successful car company and applied “as is” without thinking about problems and systems first.

    Dennis, I’m sorry to come off so combative. I’ve found so much usefulness from applying Deming’s ideas to software teams, but have found so little in the Lean movement. I will stop here before I completely embarrass myself…

  2. Dennis Stevens says on :


    No problem. This is great conversation. You heard things I don’t think I intended.

    Just to be clear. You are stating the prescribing Kanban as a method to apply Deming’s System of Profound Knowledge is faulty. I believe this is because you feel that I am suggesting you should wantonly apply all the other Lean tools or blindly apply TPS or TQM.

    I understand Deming distanced himself from TQM and Six Sigma – “applying Six Sigma and TQM to software development like it is a production line is destructive”. Also, I started my previous post stating that TQM claimed Deming but that Deming didn’t claim TQM. I agree entirely that you can’t translate the seven wastes of Lean directly (or even squint and make it fit). I agree that you can’t explicitly apply Value Stream mapping or takt time to software development because there is too much variation in each work item. I am not suggesting we try to balance the system or produce code at the rate of demand – won’t work. The goal is not to eliminate variation – your system has to operate well in the face of inevitable variability.

    I am suggesting applying kanban to visualize the system and the work items in the system. This is the method of studying the system. Team learns about the system and makes the adjustments they need (whether you call it inspect and adapt or PDSA). I have had success in multiple cases over the last decade with this approach.

    Certainly, I am not suggesting you apply TPS or TQM to an Agile team room in any way. I believe there is value in Deming that the visual nature of the kanban board helps establish a learning environment for the entire team.

    So I don’t think I am suggesting most of what I assum you imply I am suggesting. Am I still missing your point?


  3. Daryl Kulak says on :

    Nope, you didn’t miss my point at all.

    I get what you are describing in the article now. A Kanban board could be a tool for studying the system. True. A normal Agile board could also be a tool for studying the system.

    I understand what you were saying. You’re right. I don’t think we are that far apart after all. Thanks for the dialogue.

  4. Dennis Stevens and Associates » Blog Archive » How is the Kanban board different then a normal Agile board? says on :

    [...] comments on my recent post, What’s Deming Go To Do With Agile, I proposed that Kanban brings an easy to implement – low friction implementation of Deming’s [...]

  5. Curious Cat Management Improvement Blog » Management Improvement Carnival #100 says on :

    [...] What’s Deming Got To Do With Agile? by Dennis Stevens – “If you equate Kanban with manufacturing you won’t be successful. You need to understand what Deming has to say about knowledge work and how management is responsible for creating an environment for success. Kanban brings an easy to implement – low friction implementation of Deming’s philosophy.” [...]

  6. Peter Alfvin says on :

    Hi Dennis,

    Can you provide a reference supporting the view that Deming did not think highly of TQM?


    P.S. If you could send me a copy of your reply by email, I’d appreciate it.

Leave a Reply