In today’s digital society, organizations face new challenges, which place high demands on innovation capacity, flexibility, and speed. Technology advances rapidly and the level of complexity increases. Products and services evolve – cars are now being designed to drive us, rather than the other way around. In our view, quality is more important than before. Many organizations adopt agile methods to meet these challenges. But do agile work methods necessarily lead to improved quality?
According to the latest State of Agile Report, “Enhancing software quality” is one of the top five reasons for adopting agile and “Quality” is the fourth most important success measure of an agile initiative. When it comes to success in DevOps initiatives, quality comes in second place. Despite the importance attached to quality goals and measures, we have observed that in agile contexts, discussions about the new work method leave little space for more practical, hands-on questions regarding quality and compliance. Ownership of quality in agile, built-in quality, definition of done, compliance, and supplier management are some of the aspects that are usually overlooked and rarely explained in detail. Questions like “Who owns quality in agile?”, “What is meant by built-in quality?”, and “How do agile projects work with suppliers that still work in the traditional way?” are frequently left unanswered and create knowledge gaps that need to be filled.
To address the type of issues mentioned above, we provide solutions to our customers by introducing the new concept of Agile Quality Management (AQM). Within AQM, we have identified pressure points in three distinct areas: Operational Excellence, Assurance and Compliance, and Supplier Management (see the figure below). Each of these areas has challenges that are specific to that area and that need to be addressed individually, such as building a quality culture by gaining in-depth understanding of the values of Scrum or SAFe and their implications on quality work. We are also aware that complex scale agile projects and agile transformation often present quality issues in each of the three areas, which then need to be addressed jointly.
An example is continuous improvement, a part of our offering in Operational Excellence. A scrum team can have issues implementing improvements that are discussed and agreed upon in a Sprint Retrospective. When performing a root cause analysis of the problem, it may be discovered that the difficulty in implementing better work methods lies in the way the team deals with external suppliers that do not work in an agile way or in the inability to fulfil the requirements of new national legislation. This is only one example where Knowit can contribute to improved agile quality. If you have any questions or reflections regarding this article, or if you simply want to share your views on agile quality or the agile quality challenges in your organization, do not hesitate to contact us.
12th Annual State of Agile Report, available at https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report