Agile Compliance: How to combine QMS Compliance (ISO9001) with Agile Development

Its a prevalent misconception among software developers and managers that process standards such as ISO9001 are relevant for development methods such as the Waterfall model and not as much for Agile. Some articles suggest that the divergence between these approaches is big, but there are others that also point that ISO9001 clauses and PDCA concepts can be complementary we can gain much higher efficiency when using both approaches. In the remaining part of this article, I would discuss my perspective on the usage of the PDCA (Plan Do Check Act) application of ISO9001:2008 to a typical Agile (Scrum) model. 

ISO 9001:2008 International Standard promotes the adoption of a process approach and PDCA cycle when developing, implementing and improving the effectiveness of a quality management system, to enhance customer satisfaction by meeting customer requirements. The methodology known as “Plan-Do-Check-Act/Adjust” (PDCA) can be applied to all processes across different software development methodologies. A quality management system is an attempt to align all of a business’s operations around achieving high quality which is also one of the key objectives of Agile.

The PDCA cycle can be applied to all processes and to the quality management system as a whole. Above figure illustrates how Clauses 4 to 10 can be grouped in relation to the PDCA cycle, and the same can be applied to an agile framework.

ISO9001 recommends all QMS to be planned (Plan), implemented (Do), measured (Check) and improved (Act). Scrum also works on similar lines – sprint plan, sprint execution, sprint review and sprint retrospective.

Sprint Planning

Sprint planning is the first step “Plan” of the PDCA cycle. It aligns the scrum team to the objectives and to the outcome to be demonstrated during the sprint review phase of the scrum cycle. During the sprint planning phase, all scrum team members collaborate to determine how much of the Product Backlog they can commit to delivering during the upcoming sprint cycle, and this is established using available team capacity. The team further defines the resources needed to deliver the sprint goals in accordance with customer requirements and the organization policies and identify and addresses any known risks.

Sprint Execution

Sprint execution is the work the Scrum team performs during a sprint to meet the sprint goal as defined in the sprint planning phase. During the iteration, the team completes the ‘Do‘ phase of the PDCA cycle by developing and testing the functionality that was built. The Scrum teams deliver the user stories incrementally, demonstrating their work to the Product Owner as soon as they are achieved.

The daily stand-up itself symbolizes a mini PDCA cycle within the sprint. Every day, scrum team members meet for a short stand-up meeting to coordinate their assigned tasks, share information with each other about the progress toward the sprint goals and raise blocking issues, dependencies and risks. Often during this phase, the scrum teams also spend some time refining and re-prioritizing the backlogs ahead of the next Sprint planning phase.

Sprint Review

The Sprint Review is the ‘Check‘ step in the PDCA cycle. The scrum teams demonstrate a tested increment of value to the Product Owner and receive feedback on the developed product. The sprint review provides the opportunity to assess progress as well as make any adjustments ahead of the next sprint. Some stories (developed product) are approved for deployment while others are queued for further refinement in the upcoming sprint. The final backlog refinement for the upcoming iteration planning is also taken up during the sprint.

Sprint Retrospective

The sprint retrospective is the ‘Adjust‘ step for the overall iteration. The Scrum team evaluates its process and reviews any improvement stories it had from the previously completed sprint. New problems and their causes are identified, lesson learned during the phase is documented and the stories that require further refinement is logged in the team backlog for the next sprint. This regular reflection at the end of each sprint is one of the ways to ensure continuous improvement and align with the quality management system principles.

The table below maps some of the required ISO9001: 2008 clauses for agile software development to the corresponding scrum practice.

To summarize ISO9001 doesn't insist on masses of processes, but there are many that can be used in an Agile development method. It’s just that you have enough and that those you have are followed well in agile.

References: The ISO clauses and some reference material used here are from the ISO9001:2008 handbook.

Disclaimer: This disclaimer informs readers that the views, thoughts, and opinions expressed in this article belong solely to the author, and not necessarily to the author's employer, organization, committee or other group or individual.