Does Quality Management, as depicted in Figure 1.0, 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”^[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:

• 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[2], 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.

• Planning
• 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 & 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 these should have the following characteristics³:

• Product Backlog[3]
  • The owner of the items in the backlog is known
  • The items in the product backlog have been prioritized by the product owner and have been assigned relative commercial or operational business value using story points.
• Sprint Backlog³
  • Items in the sprint backlog have been drawn from the product backlog, as depicted in Figure 4.0
  • The items in the sprint backlog have been prioritized by the sprint team and have been assigned an estimate to complete using story points, ideal days, or hours.
  • The items in the sprint backlog have been completed, based on the definition of done per story, and this cycle repeats until all points for the story are earned and/or the Sprint ends, as depicted in Figure 5.0
• Product Increment³
  • A fully tested demo-able or production ready build (product increment) has been delivered and all acceptance tested have been verified and validated by the Product Owner
    

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 a QC analyst verifies and validates:

1. The desired system-software is broken down into stories which are part of what it means to deliver the desired system-software.
2. For each named story, there are one or more automated acceptance tests which, when they work, will show that the story in question is implemented.
3. At every moment in the project it is known how many stories are passing all their acceptance tests.

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.

Comments (0)

Write comment

Show/hide comment form