Does Quality Management have a place in agile product (system-software) development and delivery?
Does Quality Management have a place in agile product (system-software) development and delivery?

Figure 1.0 – Quality Management
My knee-jerk answer is yes, but what form and function Quality Management takes depends on many factors. Some of these factors are:
Let’s start by agreeing quality is everyone’s responsibility and should be second nature to business analysts, architects, developers, etc. and not just the sole responsibility of a quality assurance or a quality control analyst. Quality Management should be viewed a fully integrated management and system-software development philosophy and approach to be practiced throughout the organization from top to bottom and consistently applied and “kaizened”[1] day in and day out.
Dr. W. Edwards Deming, who is considered by many to be the father of modern Quality Management, simplified Quality Management into the iterative and incremental quality improvement cycle of Plan, Do, Check/Study, Act (PDCA), as depicted in Figure 2.0.
Fundamentally, PDCA increases the frequency of feedback loops, reduces waste and helps to maintain and advance quality.

Figure 2.0 – Deming’s Quality Improvement Cycle
Dr. Deming’s quality improvement cycle was based on the work of Walter A. Shewhart. Dr. Deming edited a series of lectures delivered by Shewhart at United States Department of Agriculture (USDA), Statistical Method from the Viewpoint of Quality Control, into a book published in 1939.
Looking first then at Quality Management in the world of Scrum, a popular agile product development framework and an agile value stream, as depicted in Figure 3.0, we see Scrum aligns very well with the PDCA cycle:

Figure 3.0 – Scrum and the Agile Value Stream
Now in the more traditional sense Quality Management is a set of three essential and interrelated parts, as depicted in Figure 1.0.
Delving into quality assurance we begin to see how it takes shape in an agile system-software development environment:
QA is accountable for helping the Product Owner (the business or customer representative) and development team identify how they know when a story or task is "done".
Now with an eye on quality control let’s look at the monitoring of specific Scrum artifacts and outcomes. Stating the obvious, at a minimum and integral to any agile system-software development project, there should a Product Backlog, Sprint Backlog, and the emergence of a Product (working and tested system-software).
Then each of these should have the following characteristics3:

Figure 4.0 – Sprint Planning
Figure 5.0 – Sprint Workflow
Additionally, Quality Management plays an integral role in the practices of Concurrent Testing, specifically Test Driven Development, as depicted in Figure 6.0, and Continuous Integration.

Figure 6.0 – Test Driven Development Cycle
A QC analyst helps define done by co-developing tests with the team, which anybody on the team can run, including the QC analyst. The QC analyst also helps determine how best to implement that test (manual or automated, which tools, etc.)
As a result of putting into practice Concurrent Testing and Continuous Integration aQC analyst verifies and validates:
Summary
When being agile Quality Management should be inherent or self-evident in self-directing and self-organizing agile teams, as the team iteratively and incrementally validates and verifies the team is doing the right things, doing those things right and adapting every step of the way; while delivering commercial or operational value incrementally.
[1] Kaizen (??, Japanese for "change for the better" or "improvement"; the common English usage is "continual improvement"). In the context of this article, kaizen refers to a workplace 'quality' strategy and is often associated with the Toyota Production System and related to various quality-control systems, including methods of W. Edwards Deming.
[2] The preceding items should not be interpreted as sequential in nature.
[3] This is not a complete list of characteristics.
My passion is to serve, in any way, to evolve this "shared" vision; helping folks apply system-thinking and deal with the emotional and creative tension of moving from the individual’s, team's or organization's current state to their "shared" vision of "being" agile.
Mantra:
"Do more listening and less talking while we iteratively and incrementally plan a little, develop and deliver, check/study our value-added and adapt"
Russell can be reached at [email protected]
Lets Hang!