Using Deming to Define Standard Work in Programming

August 29, 2007 — Posted by Al Shalloway

I have been wondering for a few years now how to make the compelling argument that there are certain practices that just must be followed. In our design patterns courses we talk about code qualities, practices to get them, principles to guide the practices, and more:

Code qualities:

  • readability
  • strong cohesion
  • loose coupling
  • no redundancy
  • encapsulation
  • testability
  • focus


  • Design to interfaces
  • Programming by intention
  • encapsulate construction
  • ...


  • Open-Closed Principle
  • Single Responsibility Principle
  • Shalloway's Law and Shalloway's Principle
  • ...

This is just a sampling of what we consider the minimum for a programmer to know before we'd consider him/her competent. In other words, we feel there are a basic set of competencies everyone should have and practices/principles they should follow. But how do you compete with - "well I like putting everything in one class because it is easier to understand?" Especially in the Agile world where the individual and team are supposedly king without question.

More recently, I've been trying to put this in Lean terms and thinking that these practices would be the standard work of the teams in an enterprise. They'd be things everyone should do. Or, perhaps better said, skills everyone would know and respect and then implement them in the best way possible in their own teams. Unfortunately, people take this to mean - "apply it when I want to". Not quite strong enough - sorry.

Well, I think I have it now. I've been reading Scholtes' The Leader's Handbook because Mary Poppendieck quoted some things from it and it sounded very valuable and thought provoking. My favorite was “All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, re-engineered and reinvented people you can muster cannot compensate for a dysfunctional system.”In the book he talks about some necessary competencies of leaders in the new world.

Competency 1 is the ability to think in terms of systems and knowing how to lead systems.
Competency 2 is the ability to understand the variability of work in planning and problem solving.

In this one he discusses common cause and special cause. "Deming taught us that there are two types of variation. Common cause variation is built into the system and is the net result of multiple influences, many of which will never be known. Most variation - the problems, defects, errors, accidents, mistakes, waste, scrap and rework that we suffer on a daily basis - is common cause variation, built right into the system. Deming calls the other type of variation special cause variation, a unique event that is attributable to some knowable influence." (It's amazing how you can forget things you knew once. Laughing )

I would claim that not following established good practices (what I listed above is just the beginning, and definitely includes most XP coding practices as well) will add to the common cause variation. That is, not following these will result in errors because the system will have more variation in it and people will not work well enough to prevent the errors (e.g., coupling two classes may not cause a problem if someone happens to notice it but it'd be better not to force people to attend to the coupling). Expecting people to compensate for errors the system is causing is not a wise thing to do.

OK, I guess I can't prove the above practices fall into this category, but it gives us a good distinction on which practices should be followed by everyone. These are those practices that will reduce common cause errors. For example, will following the practice of encapsulating by convention, revealing only when you need to, reduce errors throughout the system? I (and a host of technical trainers and coaches worldwide) would agree that it will. What if your style doesn't like this? Sorry, doesn't matter. You should apply these practices with the intention of reducing common errors.

Anyway, more to go here, but I think I'm getting closer to making the compelling argument that we can define a subset, at least, of the standard work of software development and the distinctions we'll use to say whether they are part of this standard work or not.

If you have questions or comments re this blog, please comment on either our LeanProgramming user group or our LeanAgile user group.

Alan Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban