Can DEV and QA work together as one team?

Dennis Whalen - Aug 22 '21 - - Dev Community

This post is a little different from my typical post. It's really just a question.

I'd love to get some feedback, suggestions, and discussion based on YOUR experience working with DEV and QA on agile projects.

So what is the question?

I've been involved with my fair share of both waterfall and agile projects. I've also been involved with a lot of "wagile" projects, a combination of waterfall and agile.

On these wagile projects the team is working in sprints, is agile-ish, but DEV and QA teams are siloed, working on different goals within the same sprint. For example, DEVs complete coding and (hopefully) unit testing for a user story in sprint 1, and QA does manual testing and and builds automated tests for that user story in sprint 2.

Some drawbacks I see here are:

No fast feedback

By the time QA finds a defect it could be 2 weeks old. Does the developer remember all the detail about a task they worked on 2 weeks ago? Maybe not. Quick feedback allows the developer to keep focus on the task at hand.

No communication between DEV and QA

Well, there's some communication, but it's mostly bad news, such as "it appears your code is broken and I have formally documented it for you". Ideally DEV and QA would be working as one TEAM, with the same goals, in the same sprint.

Finger pointing

Because DEV and QA really don't communicate until there's a defect, I usually see finger pointing, blame, and a general salty attitude between the 2 teams. QA doesn't understand how the broken code could have ever been considered "done", and DEV is moving on to new work that they've committed to for the sprint. The 2 teams have different goals within the same sprint.

Story pointing and sprint planning becomes weird

For these types of projects, the DEV and QA tasks usually end up getting sized and planned separately. Ideally the stories would be sized by the TEAM, but with 2 teams working on different goals in the same sprint, sizing usually gets split also.

QA is always "behind"

With this strategy, QA is always playing catch-up, and is usually considered a bottleneck to moving more quickly. DEVs really have no incentive to help QA with issues or testing, as they have moved on to new user stories for the sprint.

The codebase is not ready to deploy

Because you have code in your codebase that has not been thoroughly tested, you have code in your codebase that is not ready to deploy.

What's the solution?

So those are a few things I've seen in the past. IMHO the solution to most of this is to completely get rid of the concept of a DEV team and a QA team. The agile team needs to be ONE TEAM that works together to complete development and testing of the user stories in the same sprint.

Some folks may have specialties within the team, but the whole team has the same goal: meet sprint commitments by completing development and testing of user stories within the same sprint. Everyone on the team pitches in to ensure the TEAM meets their commitments.

What are YOUR thoughts?

I'd love to hear some feedback from you. Do you see similar challenges with your projects? How do your teams deal with them? How can we help move a team from wagile to agile?


Smart EDJE Image

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .