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.
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).
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.
(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/
No comments:
Post a Comment