Dr W. Edwards Deming quote Quality begins with the intent, which is fixed by management.

Yes, you read that right.  Quality is management’s responsibility.  Most agilist’s reading that statement would spit out their coffee and then declare “But, quality is the Team’s responsibility!”.  While that statement has merit, it is far more important to have a system in place that ensures high quality, and systems building is a management responsibility.  This is one area where traditional agile thinking meets with traditional lean thinking to create the best outcome.

Wisdom from Dr. Deming

Tim Stevens of IndustryWeek magazine had the privilege to be the last to interview Dr W. Edwards Deming about management’s responsibility.  One of the first questions Mr Stevens asked Dr Deming was “What can you say to IndustryWeek’s readers that they might benefit from and apply to the way they are running their businesses?”  To which, Dr Deming replied “Management today does not know what its job is. In other words, [managers] don’t understand their responsibilities. They don’t know the potential of their positions. And if they did, they don’t have the required knowledge or abilities. There’s no substitute for knowledge.”  Dr Deming continued with this explanation “Quality is the responsibility of the top people. Its origin is in the boardroom. They are the ones who decide.”.  Dr Deming, with all his experience and knowledge, wanted to illustrate that management’s (leadership’s) main responsibility is to build a system that creates and ensures quality.

Taking a Systems View

As a manager or leader one of your key roles is to create an environment that encourages rapid delivery of the right solutions for the customer.  This requires stepping back from the traditional command and control (telling people what to do) and instead focusing on creating a system that allows people to innovate while ensuring the right level of quality and governance is applied at the right points.  This is a difficult transition for most managers and leaders that have grown up in the Tayloristic work break down structure approach.  But what really creates value is the focused system that good people thrive in, not a failing system that good people try to work around.  In short, managers need to move from managing people to managing systems

Figurine of a scrum master pointing at a release plan

Applying Systems Thinking to Ensure Quality

Taking this leap towards focusing on a system that ensures quality can be a daunting task.  I have found that starting with understanding the system is a critical first step.  To best understand a system, there is no substitute for a post-its-on-the-wall value stream mapping session.  (see my blog on the three reasons for value stream mapping in SAFe ® or some of Al Shalloway’s work on this subject).  For the sake of this article, let’s assume you have gone through this initial work (value stream mapping is an ongoing exercise), and have a decent understanding of how value flows through your system.  As a manager, your challenge is to begin to understand the bottlenecks at each state in the system, but also to understand how each state ensures Percent Complete and Accurate (%C&A)(1).  One of your key objectives in applying systems thinking is to increase this %c&a at each critical transition or hand-off.  Definition of Done is an important tool to assist in this critical task.

The Importance of DoD in Increasing %C&A

True quality comes from a system that encourages transparency along each step of the process and incorporates the Andon chord approach to determine when/if to halt production when an issue is found.  In many cases the Dev Team does not have visibility or ability to change these systemic issues, but management can and should.  Using a clear Definition of Done (DoD) at specific points is a critical part of the quality system.  DoD’s are not checklists that we mindlessly go through, they are living contracts between teams, PO’s, PM’s, and the rest of the ART and its stakeholders as to our quality and accuracy validation.  If you are working in a scaled environment, the SAFe® recommendations on Definition of Done are a great starting point to improving the system to achieve Built In Quality

DoD is Measured at each Increment

In SAFe®, DoD is purposely used at various granular levels.  The team meets the Team DoD to ensure that the value added is worth demonstrating and reviewing.  The System Increment DoD ensures that it is integrated into the system and is worthy of Release consideration.  And the Release DoD ensures we have met our customer readiness and impact standards and are ready to put it in front of the customer.  Each Definition of Done is essentially asking “Are we done enough to go to the next state?”, which is a key part of our quality control to ensure our %C&A.

It is hugely wasteful to meet Release DoD on a story that may never be in the customers hands.  As Peter Drucker said “The worst thing we can do is do something well that should not have been done at all”.  We increment towards a true state of ‘Done’ (in the customers hands and they are happy) through a set of ever expanding DoD increments.

The System needs to work even if a critical person is out.  Just because Dinesh is out sick today should not mean we have lesser quality that day.  The system should have its checkpoints that ensure that we are still following our agreed upon contract with the next step to consume the value.

Managements Role in DoD

As already stated, far too often teams are held accountable for quality when they have little to no ability to change the system that should be ensuring quality.  Agile teams are described as Self-Organizing and Self-Managing, but as described in another post, teams are not really self-managing.  We need management and leadership to provide teams with solid systems to work within, and these systems need to be built to deliver and ensure quality.  Built In Quality Is not just a phrase on the SAFe® Big Picture, it is a way of working and thinking that ensures quality at each step.

Iterative Growth on DoD

Building a DoD is not a one and done.  We need to start with a set of validations that we believe to be correct, measure the outcomes using this set of validations, and then iterate on the set.  We will almost certainly not get it right the first time, only through inspecting and adapting will we get to a solid set of DoD’s.  One good way to ensure that we are iterating on it is to capture any exceptions we deal with and determine if the DoD needs to be updated to prevent in the future.  E.g. If a system issue slips by our current DoD and into the customers hands, is there something missing from the DoD that would have caught this?  Whenever we are in crisis “it has to be fixed yesterday” mode we have to also capture the underlying data that allows us to improve the system once the crisis is over.

Footnotes

(1) Percent Complete and Accurate (%C&A).  A quality metric used to measure the degree to which work from an upstream supplier is determined by the downstream customer to be complete and accurate (or error free). https://www.ksmartin.com/lean-terminology/