In the latest episode of my blog series on Anti-Patterns that doom a Product Owner to Fail, I tackle the topic of quality. So, who owns quality on a Scrum Team? I personally think the whole team owns it collectively, but if you want to know who is ultimately responsible for a quality product, it’s the Product Owner. Join me to learn about some anti-patterns to avoid when it comes to quality.
No Governance
Governance might be a dirty word in Scrum (harkening back to more traditional Project Management concepts), but it’s still a good idea even if it’s not prescribed anywhere.
Problem
There’s no governance in place to manage and control the quality of the work products the Scrum Team develops. This means the team has no safety mechanisms or guardrails to keep the train on the tracks should something go wrong.
Solution
While a formal governance process might not be necessary when using Scrum, some quality controls must be in place – somewhere, somehow. Ideally, this is in the form of a good “Definition of Done.” This definition will guide the Scrum Team to ensure that all the necessary quality attributes are accounted for and met in the product.
Quality attributes can also be included in the Acceptance Criteria. The Definition of Done tends to span the whole project, whereas individual User Stories may have additional quality attributes that must be satisfied. Including these as part of your Acceptance Criteria will ensure that they are testable to provide a high-quality product.
No User Testing until the end of a Sprint
Wait… isn’t this a Waterfall problem? Well, it is, but it can also creep in on Scrum Teams.
Problem
The Scrum Team works during the Sprint but doesn’t provide anything testable until the tail end of the Sprint, leading us right back to the problems of Waterfall. And when nothing is ready to test, stories that aren’t finished can’t be marked as “done” according to the team’s Definition of Done. This is demoralizing to the team and looks terrible to the stakeholders.
Solution
Don’t wait to release completed work items! Unless there are compelling reasons, such as extensive overhead costs or length of time to do a release, immediately release work that’s ready for testing. This allows time for thorough testing and resolution of any defects discovered. Keep continuous delivery on your mind, and as soon as something is ready, get it out for testing as soon as possible.
Quality is overlooked in exchange for speed
Agile is all about delivering work quickly, right? Well… sort of.
Problem
The goal of each iteration is to deliver a working product, which means that, well, it works. Quality should be baked into Agile, not left as an afterthought. Unfortunately, teams can be judged on inappropriate measurements such as average velocity, which may cause them to care more about that number and throughput than they do about quality.
Solution
Don’t ever satisfy speed of delivery over building a quality product. Quality assurance should happen throughout the lifecycle of a User Story. Having a clear understanding of what is necessary to complete a User Story should act as a quality check, including:
- Having a clear Definition of Ready for the User Story
- Making sure the Acceptance Criteria are clear, complete, and testable
- Developer testing happens before the work gets handed off to someone else
- Having defined test cases with pass/fail criteria
- Ensuring that each story meets the team’s Definition of Done
Keep this little checklist in mind when considering whether to move the User Story to the next step in the process, thereby ensuring you are confident it’s of high quality by the time you’re ready to release an item.
Not everyone feels responsible for quality
The question of who is responsible for quality on Scrum Teams is a common one. It sometimes seems like everyone on the team wants to pass the quality buck off to someone else.
Problem
Some teams are lucky enough to have someone with specialized Quality Assurance skills. If so, you might feel like you’re off the hook for worrying about whether you’re building a high-quality product. Even if you don’t have someone with these specific skills, it’s still common to think that creating a quality product is not your job. However, that’s not the case.
Solution
No one on a Scrum Team should think that quality is someone else’s job – on a team, quality is everyone’s job (even though the Product Owner is ultimately accountable). When you first form your team, perform a “Roles & Responsibilities” activity that clearly defines individual and group responsibilities. It should be made clear, and the expectation set, that the team (as a collective) commits to developing and delivering a quality product.
Wrapping Up
Unfortunately, quality is often intentionally skipped or overlooked when developing products using an Agile approach. Not paying attention to quality leads to bad user experiences, angry stakeholders, and unsuccessful outcomes. For Scrum Teams to succeed, they must build quality checks into their development approach, which will result in a high-quality product the whole Scrum Team can be proud of.
So, have you experienced any of these quality issues in your work on an Agile team? Are there any other ideas you have about ensuring that quality is intentionally built into a product? I always like to know what other people think, so drop me a line in the comments section!