7 Ways Doing Scrum Wrong Hurts Software Quality

When quality issues arise, many Scrum teams look to testing and technical development practices to address the problems. What they often miss is that poor implementation of Scrum has directly contributed to their quality issues.

Organisations and teams typically tailor 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, if the objectives of the ceremonies are achieved, albeit in a modified manner.

But there are plenty of other ways that efforts to tailor Scrum to your needs can affect software quality. Here are the seven ways that poor Scrum implementation can hurt quality—along with advice about how you can avoid them.

1. Failure to refine your product backlog

A key purpose of backlog refinement is to achieve a shared understanding of the product backlog items. These are typically requirements in the form of user stories. Building quality into the requirements through effective collaboration in refinement sessions prevents defects; it will also 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 where 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 means that there won’t be a shared understanding of the requirements. Using practices such as “the three amigos” (referring to a product owner, a developer, and a tester) for refinement, but without subsequent full team involvement, is one example of this.

2. Failure to collaborate

Scrum advocates a cross-functional self-organising 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 essential elements of effective Scrum implementation. Some ways to create the desired behaviours include agreeing on team values and common goals—for example, with a team charter—engaging in team-building activities, and using collaborative practices.

3. Lack of a dedicated product owner

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 minimise this risk to quality, your team should work on getting the most out of any engagement that it has with a PO. Additionally, it 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.

4. Inadequate definition of done

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 that your artifacts (such as user stories and increments) are sufficiently “done.” Issues with the DoD happen when the definition:

• Is weak, for example, if it contains vague statements such as “all tests passing” without referencing what type of tests or coverage targets you have. Good practices such as code reviews, test automation balanced with exploratory testing, code refactoring, etc. are largely absent.
• Is not followed under pressure.
• Is not seen as something the team needs to work on to improve.

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 toward achieving “good enough” quality.

5. Failure to realise that Scrum is a pull system

People often miss this fact. Scrum doesn’t explicitly limit WIP (work in progress), as Kanban does, to create a pull-based flow approach. Instead, participants 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 WIP in sprints. This increases cycle time, causes stress, and demotivates the team when the sprint goals are jeopardised. It often results in teams not adhering to the DoD; examples include insufficient testing, lack of 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.

6. Failure to integrate your good practices into Scrum events

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 which product backlog items (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 it needs to do for these specific user stories/PBIs to meet the team’s 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 your conversations. In sprint planning, you can incorporate this good practice by analyzing 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.

Reflect on your good practices and how they can fit naturally within scrum activities.

7. Retrospectives that fail to achieve their objectives

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. Retrospectives can become repetitive, and eventually the team may lose its enthusiasm for them. If no real improvement actions or experiments come out of retrospectives, it becomes difficult to see the benefit.

Bringing the actions and experiments into the sprint backlog for the next sprint emphasises their importance and provides the justified visibility. You can use them not to focus just on the Scrum framework itself but on any practice, such as testing, to help you achieve the required level of quality.

Avoid these quality issues

These seven challenges to successful Scrum implementation can significantly affect software quality. 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. Finally, having someone in the role of Scrum master is key to helping your team succeed.