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?
Top comments (3)
I have never seen this format of development and testing before. I've always worked in teams where code is tested in the same sprint as this is the most obvious / sensible solution.
Not sure what card system you're using in your team but the majority of card management systems such as Jira or Azure DevOps, allow for developers to add comments. So simply get your team members to add code on what has been done / tested.
If the code hasn't been tested it will sit in the testing column, until it has been simple as. Once it's been tested it can be signed off, or returned to "to do" its a very simple concept of Agile, I'm not sure why your team hasn't been testing in the same sprint (deliberately). Usually the only time the code wouldn't be tested in the same sprint ,is if it was committed towards the end of sprint.
If you have strict deadlines on code deployment, e.g every 2 sprints you deploy signed off code, it just means any un-tested code doesn't make it into that release. If it needs to be in that release, you prioritise development, and testing on that card (even if requires late nights)
Thanks for the reply Grant. Yeah, what you describe is what I see on an agile project, but I have seen more than one of these wagile situations. I know it's not what we want, and I'm just trying to figure out what I might do to help make changes when I see these situations in the future.
And when I say "how to make changes" I don't mean "what process should we really be following". I think I know the answer to that, and you had a good recap. It's really how can I help a large team, with all the existing pressures and deadlines, make those changes while not completely blowing up our cadence.