Recently I was asked, "Does quality assurance have a place in agile software development?"
My knee-jerk answer was 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 (the team's) responsibility and should be second nature to business analysts, architects, developers, etc. and not just the sole responsibility of a quality analyst. Quality Management (QM) should be viewed a fully integrated management and 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 an iterative four-step problem-solving process; Plan, Do, Check, Act (PDCA) as depicted in Figure 1.0.
Looking first then at quality management in the world of Scrum, a popular agile product development lifecycle, we see it 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, showcase and end of a sprint retrospective.
- Act - Adapt the way the team works based on what was learned from the retrospective.
Now in the more traditional sense Quality Management is a set of three essential and interrelated parts as depicted in Figure 2.0.
- Planning
- Quality Assurance
- Quality Control
Delving into quality assurance, let's take a look at how practicing quality assurance might take shape in an agile software development effort:
- QA integrated into every team - A member of the QM team is now an active participant in a sprint planning and a sprint.
- QA testing role - If the role of Quality Assurance Analyst exists in your organization the Quality Assurance Analyst is accountable for helping the development team identify how they know when a story or task is "done". They help define done by co-developing tests with the team that anybody can run including the QM person. They also help determine how best to implement that test (manual or automated, which tools, etc.)
- QA team adaptation - If the role of Quality Assurance Analyst exists in your organization the Quality Assurance Analyst could lead your sprint retrospectives. The Quality Assurance Analyst will be the ambassador for the team doing the right things to ensure an eye on quality is built into the teams' way of working. The Quality Assurance Analyst will also ensure that all action items from the retrospective get reflected in the work in future iterations and releases and monitor the progress as action items are addressed.
Now with an eye on quality control let's look at the monitoring of specific Scrum artifacts and outcomes, as depicted in Figure 3.0.
Figure 3.0 - Iteration Lifecycle in Scrum
Stating the obvious, at a minimum and integral to any agile software development project, there should be evidence of a product backlog, sprint backlog, and the emergence of a product.
The supposition here is not to imply your approach to agile development and applying the Scrum framework is artifact centric. What is important is you leverage the use of the product backlog, sprint backlog and each product increment to check if you are doing things right.
Keeping this in mind the product backlog, sprint backlog and product increment should have the following minimal set of characteristics3:
- 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 backlog3
- Items in the sprint backlog have been drawn from the product backlog.
- 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.
- Product increment3
- A fully tested demo-able or production ready build (product increment) has been delivered
Though quality control should be inherent in self-directing and self-organizing agile teams the integrity of the product backlog, sprint backlog and product increment serve as an excellent barometers used to check if the team is doing the right things and doing those things right.
In conclusion, studies have shown that about 50 percent of time is spent on avoidable rework rather than on value-added work, which is basically work that's done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.
Agile development and using the Scrum framework, with an eye on quality management, works to solve these problems by:
- An emphasis on individual, team and enterprise-wide collaboration
- effectively dealing with uncertainty by the amount and significance of learning and new knowledge gained by working through each sprint and delivering an increment of the product
- testing component dependencies earlier in the development lifecycle
- finding "missed" requirements more easily and sooner by surfacing misunderstandings in deliverables and scope
[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.
About the Author
Russell Pannone is the Founder of We Be Agile and the Agile Lean Phoenix User Group, as well as the Agile-Lean Adoption Lead. With almost 30 years of system-software development and delivery experience, my focus is on working side-by-side with folks on real projects helping them deliver valuable system-software to production early and often, giving those I collaborate with the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve.
