When quality issues arise, many teams look to testing and technical development practices to address the problem. However, what they often miss is that poor implementation of Scrum has directly contributed to their quality issues.
Organizations and teams typically tailor/customize Scrum to their specific context. Tailoring can relate, for example, to the roles, events and artifacts in Scrum. This works fine if your tailoring still maintains the integrity of the Scrum framework (for example the objectives of the ceremonies are achieved albeit in a modified manner).
Here are the seven ways I have seen poor Scrum implementation in organizations hurt quality—along with insights on how you can avoid them.
A key purpose of backlog refinement is to achieve a shared understanding of the product backlog items (PBIs) – typically requirements in the form of user stories. Building quality into the requirements through effective collaboration in refinement sessions prevents defects and will deliver a solution that is more likely to be fit for purpose.
User stories that meet the INVEST criteria are a good practice to use in refinement. They help you avoid a common issue whereby the team ends up focusing on horizontal technical discussions rather than valuable (vertical) user stories. Poor refinement sessions and issues such as partial team participation will mean shared understanding of the requirements will also not be achieved. Using practices such as the “Three amigos” (with a Product Owner, a Developer, and a Tester) for refinement but without subsequent full team refinement is one example of this.
Scrum advocates a cross-functional self-organizing development team. This means that code developers and QA/testers must collaborate effectively. Without effective collaboration, whole team ownership of quality will be missing, with obvious implications for software quality.
These people/cultural behaviours are an essential element of effective Scrum implementation. Agreeing team values and common goals (for example with a team charter), engaging in team building activities and using collaborative practices are some of the ways to engender desired behaviours.
The 2020 State of Agile Report stated that 36% of respondents lacked business/customer/product owner (PO) availability. Without sufficient customer representation on the team to help provide quality requirements and then validate the solution, quality will suffer.
To minimize this risk to quality, your team should work on getting the most out of any engagement that they have with a PO. Additionally, they should explore collaboration with other stakeholders and Subject Matter Experts (SMEs). Examples could include sales/marketing, product management, regulatory, UX, and so on. A team member could help drive this collaboration, acting effectively as a proxy PO, and developing the business domain expertise within the team. Testers are a natural fit for this role, given their focus on the external quality of software.
The Definition of Done (DoD) is key to transparency and consistency of quality in Scrum. It encapsulates, for example, your test approach. This helps ensure your artifacts (such as user stories and increments) are sufficiently ‘done’. I see issues with the DoD such as when the definition…
This results in rapid growth of technical debt, and quality suffers. Scrum would advocate starting with whatever good practices you currently have but improving continuously (inspect and adapt) to work towards achieving ‘good enough’ quality.
People often miss the fact that Scrum is a pull system. We don’t explicitly limit WIP (Work In Progress) , as Kanban does, to engender a pull-based flow approach. Instead we implicitly limit WIP – only the development team can decide what scope is realistically achievable to include in the sprint.
Missing this point results in too much work in progress in sprints. This increases cycle time, causes stress and demotivates the team when the sprint goals are jeopardized, and often results in teams not adhering to the DoD (examples include insufficient testing, no refactoring, and unresolved bugs).
This results in poor quality and an increase in the total cost of ownership of your software (due for example to high maintenance costs).
Although moving away from a push system can be a significant cultural shift for management, it is key to increasing your level of agility and delivering quality software.
Although you may implement the mechanics of Scrum you also need to understand the objectives and rationale in what you are doing.
Sprint planning, for example, involves identifying what PBIs you can pull into the sprint and how you will implement them. ‘How’ means planning the tasks you need to undertake. But trotting out the same standard list of generic design/code/test tasks misses the point. The objective is for the team to plan together what they need to do for these specific user stories/PBIs to meet their DoD.
For example, addressing quality risk is a fundamental principle of modern testing. Identification and analysis of quality risk typically happens informally in agile during our conversations. In Sprint planning you can incorporate this good practice by analysing quality risks for the user stories/PBIs. This helps you define the test approach and the associated testing tasks that the whole team can use to mitigate quality risks.
So reflect on your good practices and how they can fit naturally within Scrum activities.
All of the above Scrum related issues affecting quality are ultimately surmountable if you keep inspecting and adapting your way of working. Retrospectives help you focus on achieving this continuous improvement.
Unfortunately, even this element of Scrum often fails to achieve its objective. They can become repetitive, and eventually the team may lose its enthusiasm for them. If no real improvement actions or experiments are coming from retrospectives it becomes difficult to see the benefit. Bringing the actions and experiments into the sprint backlog for the next sprint emphasizes their importance and provides the justified visibility. They can be used not to just focus on the Scrum framework itself but any practice such as testing to help us achieve the required level of quality.
These seven challenges to successful Scrum implementation can significantly affect software quality. However, developing an understanding of the rationale behind the elements of the Scrum framework will help you avoid these issues when tailoring Scrum to your context. This, combined with a desire to continuously improve, will help you succeed in achieving increased agility with quality. Having someone in the role of Scrum Master is of course key to helping your team succeed at this.
Want to know more? Come to my tutorial session, ‘Scrum and Kanban – Addressing Real Life Agile Testing Challenges’ at the EuroSTAR testing conference, where I will focus on effective agile testing by following the points above. I’ll also invite participants to share their own challenges. The online conference runs from November 17-19.