How Accountable Is Your Team for Its Work?

It would seem obvious that quality assurance should be part of the Scrum team’s skillset. Cross-functional teams should have the required skills to create value and ensure a minimum quality level, at the very least. Otherwise, whenever you ship something, you run the risk of breaking everything else.

As with everything in life, you’ll face different attitudes towards this topic. Some people (like me) would advocate for fully functional teams, while others would see value in having teams with dedicated skills supporting Delivery Teams. The same would go for design, user experience, software architecture, etc. I’ve been on both sides of this argument, and I’d like to share what I’ve learned so far and the pros and cons of each scenario.

I will focus solely on combining quality assurance with Scrum during this post. I hope that by the end of this post, you’ll have the insights you need to help you with your scenario.

Cross-Functional Team

Accountability is the outcome of cross-functional teams because they are responsible for everything, from end to end. Either the team decides which quality standard they need to meet (Definitions of Done), or the company sets a global standard that all teams must follow. Then, team members work collaboratively to ensure their deliverables respect the established DoD. Cross-functional teams are the ideal case. Unsurprisingly, if you look at the Scrum Guide, that’s the definition you find for Scrum Teams.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

— The Scrum Guide

Despite the Scrum Guide’s clarity, people tend to think they know best how to organize their teams and opt for other approaches, which I will walk you through.

In a cross-functional team, quality assurance is part of the activities it takes to get the job done. Team members are self-managing, and it’s up to them to decide how to proceed with quality assurance; there’s no single person responsible for that. For example, after a release, the team encounters loads of problems – and it’s the team's responsibility to fix them and identify measures to avoid this in the future. But more often than not, nobody in the team will take the blame because it’s a shared responsibility within the team.

Another critical aspect of cross-functional teams is their skill-set distribution. You will find professionals who are more experienced in specific disciplines than others, but at the end of the day, everyone is accountable for the ultimate result.

Advantages

• No dependencies with teams or people
• High accountability level
• Quality assurance is treated as part of the team
• Team members grow together

Disadvantages

• Short term output decreases because the team is accountable from end to end
• No dedicated person for quality assurance
• In times of pressure, the team may decide to reduce quality assurance standards

Developers + Dedicated QA Engineer

Over the years I’ve noticed a typical structure with Scrum teams. It’s about having a dedicated person as a Quality Assurance engineer, someone who is responsible for doing most of the tasks related to QA. Depending on the team's size, two or three dedicated QA engineers might be on board.

I’ve experienced good and bad results with dedicated QAs inside the team. I’ve seen this approach work well when expectations are clear – for example, when you determine what Quality Assurance means to the team and which devices and operating systems you need to cover. However, when you leave some loose ends you may end up with a few surprises.

Let me share a quick experience with you. Once I had a QA engineer who wanted to block a new feature because it didn’t work on Kindle, even though we had no users on that device. Back then, I was the Product Owner, and I had a hard time explaining to the QA engineer that we didn’t care about Kindle. He lacked clarity and wanted to block the release because of an irrelevant scenario.

Advantages

• A dedicated QA engineer often brings advanced expertise to the table
• Quality assurance isn’t negotiable. Even under stress, it will happen
• Quality assurance happens during the Sprint as part of the work

Disadvantages

• The team cannot utilize its full capacity due to QA dependencies, or the Sprint cannot be completed
• It might create siloes as a side effect – Devs versus QAs – which will hinder collaboration
• QAs may be too idle at the beginning of the Sprint and too busy at the end. This can create a bottleneck effect and continuous carry-overs
• It creates a new role inside the team, which is against the agile manifesto principles
• No accountability from end to end: Software engineers build and QAs test, and if a release causes problems, QA engineers get the blame because they are accountable for it

Developers + QA Expert

A slight variation of the previous approach, this can happen when the team still doesn’t have enough quality assurance expertise but does get support from an expert. Instead of being accountable for everything related to quality assurance, the QA expert is responsible for helping the team develop their expertise and ensure a standard quality level.

This scenario can smoothly work once you’ve got an experienced Quality Assurance engineer. The outcome can be highly positive: the team will grow into quality assurance and be accountable from end to end. Eventually, this team becomes cross-functional.

From my experience, when you get a knowledgeable Quality Assurance engineer willing to mentor software engineers, so everyone benefits from it.

Advantages

• Accountability from end to end
• High collaboration level
• Quality output from the team
• Clear quality assurance standard
• The team eventually becomes cross-functional

Disadvantages

• The team’s output is decreased during the ramp-up phase
• QA experts may become a bottleneck as they may support several Scrum Teams at the same time
• Developers may skip quality assurance if they are pressured for more output. To avoid that, the QA expert requires support from leadership

Two Teams: Devs & QAs

The worst scenario I’ve ever seen is having separate teams responsible for quality assurance. This approach is counterproductive and easily creates conflict. It leads to a blame game; software engineers complain that QAs complicate everything and are picky about pointless problems, while QAs complain software engineers deliver poor output. As a result, the product suffers because nobody takes full ownership.

Unlike having a dedicated Quality Assurance expert inside the team, this approach requires a handover to another team, which adds complexity. Often, the external QAs don’t attend refinements, Sprint Plannings, and Daily Scrum; they lack contextual knowledge, and therefore misunderstandings become unavoidable.

Advantages

• A dedicated QA engineer often brings advanced expertise
• Quality assurance is non negotiable. Even under stress, it will happen

Disadvantages

• Lack of ownership
• Silo effect: Devs build, QAs test
• Blame game: Devs blame QAs for delays and vice versa
• Frequent misunderstandings due to lack of context knowledge
• Frequent delays due to confusion between teams
• Focus on process instead of creating value

From my experience, I recommend avoiding this approach in most cases. It might make sense when mistakes are a matter of life and death, e.g., healthcare, aviation, etc., but you may need a dedicated team of experts to cover all test requirements in such situations.

Another example of why having a dedicated QA person and/or team can cause more harm than good can be seen in the image below. It shows the Pull Request cycle time breakdown of a team with a dedicated QA engineer. The developers finish their task and want to merge the PRs into the master branch, but the QA person blocks them from pushing it because she is in the middle of testing a previous version. As you can see, PRs wait an average of 93 hours (!!) to be merged (after they are reviewed). This causes much work to stand in line without being merged, creates conflicts and bottlenecks, and makes the team less efficient.

Endnote

I wouldn’t dare claim there’s a perfect solution for every situation. It’s up to you to understand your scenario and identify what fits better.

Understand which challenges you’re facing, meet your team one step ahead and help them figure out what works for them. Don’t try teaching or preaching approaches. Encourage them to try out and learn from their experiments.

No matter which approach you choose, ensure you have sound quality assurance expertise within your team. The cost of not having it can be devastating