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:
- Are you in the business of making and selling heart monitoring instruments or basketballs?
- Is your business highly regulated by State, Local and Federal government?
- Does your business employ 6 or 60,000 people?
- Are your employees co-located or spread out all over the world?
- Are there in place stringent corporate policies and procedures to ensure compliance with the Sarbanes-Oxley Act ?
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”  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:
- Plan – Release and Sprint Planning
- Do - Team and customer collaboration by elaborating on requirements, doing some design, doing some coding, creating builds and doing some integration, and doing some testing , in one time-boxed pass through a product development lifecycle.
- Check - Concurrent testing, continuous integration, daily stand-ups, sprint review and end of a sprint retrospective.
- Act– Adapt the way the team works based on what was learned from the retrospective.
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.
- Quality Assurance (QA)
- Quality Control (QC)
Delving into quality assurance we begin to see how it takes shape in an agile system-software development environment:
- QA integrated into every team – A member of the QA team is now an active participant in a sprint/iteration.
- QA amp; Team Adaptation - QA leads retrospectives at the end of sprints/iterations and releases. They will ensure that there is just enough process for the team to ensure quality but not too much that the team doesn't see value in the process. They also ensure all action items from the retrospective get reflected in the work in future sprints/iterations and releases.
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