I’m on a Scrum team as QA Lead and the QA’s should work alongside the dev writing test cases and testing as areas are complete. Then PR and a final pass through QA before a user story moves to done.
Ideally the devs would communicate implementation decisions, bonus functionality (dev initiated scope creep), UI plan, etc to us during development and even show us screenshots of UI or demo locally to shift testing left, but they do none of that.
They code, code, code without a word and then toss stories into testing after the PR is complete. As a team, QA isn’t viewed as part of the development process. We’re viewed as a gate to Done. As Lead, I want to change the dynamics of the team and promote earlier collaboration with QA so we have less churn at the end - things like not knowing details for test cases til a story is in testing, not knowing extraneous areas have been refactored, not seeing implementation decisions that don’t meet quality standards until the very end. This is causing multiple returns to dev an dmultiple cycles testing. Better collaboration early could prevent this.
The devs prefer to work in silent silos, not really communicating with each other or with the QAs. I want to increase communication and foster a team mentality to prevent all this churn. Any suggestions on how to do that? Have you experienced the same? Any thoughts or suggestions?
That’s a red flag. In my team we do refinement sessions and the dev team do not start working until a use cases document with designs is prepared. This stuff is generally known to everyone since we do our sprint meetings regularly.
I did experience what you’re talking about but that was a project based company with messy project managers. I suggest you start by tracing where the idea for any work originate from. If the dev team just do it themselves then you need to refer to some person higher and ask for a single person to fulfil the product owner or equivalent role.
It seems that your team lacks the engineering and teamwork culture, doesn’t care about product quality and efficiency, and lacks an understanding of QA and testing, its goals, and value. I mean the situation you have is understandable and it might even work (in some organizations it’s a standard process - testing is a stage of development, and there is no QA just QC or testing). You need to talk with the management, stakeholders, devs, product owners, etc, state your position and suggestions, and explain how it’ll improve the process, efficiency, quality, etc. You need to try to convince them but maybe you won’t be able to do so you need some people, particularly one who can enforce some processes who would support your ideas
Overcoming exactly these types of situations should be the focus of retrospectives and the scrum master. Build the use case without pointing blame and have the discussion. The team should hold each other accountable and the scrum master should facilitate teamwork and overcoming these obstacles. It is hard to get into specifics without knowing more about the team members but a few approaches could include:
Setting sprint goals based on the retrospective
Team building exercises
Getting the QA to be more involved in refinement meetings
Sounds like you need to change the culture of the team, which is challenging, but very rewarding when you start seeing the progress.
And if all else fails, raise the concerns to managment. Good luck to you!
I’ve been in similar situations where QA was treated as an afterthought rather than an integral part of the development process. Here are a few strategies that worked for me to foster collaboration and shift testing left:
Embed QA in Planning Sessions: Advocate for QA involvement in sprint planning or backlog grooming. This allows QA to understand user stories deeply, ask questions early, and identify potential testing needs upfront.
Define a “Ready for Development” Checklist: Collaborate with the team to create a checklist for user stories that includes clear acceptance criteria, testable requirements, and UI expectations. This sets a standard that all stories must meet before development begins.
Introduce Peer Reviews for Test Cases: Propose that developers review test cases before coding begins. This often triggers discussions about edge cases and implementation details, fostering early collaboration.
Promote Cross-functional Demos: Suggest brief “Show and Tell” sessions where developers demonstrate progress during the sprint. This gives QA visibility into ongoing work and a chance to provide early feedback.
Leverage Retrospectives: Use sprint retrospectives to highlight the impact of communication gaps. Frame it constructively by showing how early collaboration could have reduced rework and saved time.
Celebrate Collaborative Wins: When early QA involvement catches a major issue or improves workflow, make it a point to celebrate as a team. This helps reinforce the value of working together.
Ultimately, breaking silos requires consistent effort and a shift in team culture, which doesn’t happen overnight. However, when developers see that early QA collaboration saves them time and improves the overall quality, it often changes their mindset.
Have you tried proposing smaller incremental changes like peer test case reviews or shared demos? Sometimes starting with smaller steps can make the shift feel more approachable for everyone.
Siloing and a lack of communication takes a long time to fix, this is full team transformation and may take months or years to manage. However, along with the ideas above, I have some things that I’ve seen work.
Let them fail. If the team won’t communicate and just code, test what you can in an exploratory style after it’s thrown over then raise all the bugs. Team velocity will slow down and then you can offer ideas such as pushing left to support things (just don’t let anyone get away with saying that test is the bottleneck).
Work with Engineering Managers. Sometimes we have to get things like collaboration into people’s performance reviews. Work directly with the EMs to have a plan for collaboration and why that’ll help team velocity and quality, then make that the EM job to manage.
Do risk analysis of tickets. Devs want to work with you when they know it’s useful, so do the shift left on tickets in isolation, attach the risk analysis to the tickets and let the team know they exist and you’re happy to talk about them (also say how knowing tests early will help prevent bugs).
Meet them half way. We always want engagement for our work, what have we done to engage with developer work? Are we helping to debug, being a part of PRs, attending architectural meetings? Collaboration goes both ways, if you show that you’re interested in development the maybe they’ll return the favour.
Dealing with the wider issue of communication with your team:
Make communication and collaboration part of people’s job profiles and score them accordingly. You’ll need management buy in, but if people refuse to collaborate then this needs managing (maybe people need managing out of the team).
Bring in a senior / staff / principal engineer to show the other devs how it’s done. You need somebody to show by doing and build the culture of comms, having a good dev who’s a communicator will help.
Review your testing comms. Could the rest of the team say you work in a silo, do they understand what and why and how you want to test? Do you explain the theory of testing in the team and things like shift left well. Or does testing happen quietly and then just bugs are thrown out?
Accept it and go waterfall. If the team can’t work in an agile way together, maybe you need tighter processes that allow for coding in a vacuum: stronger documents, quality gates, etc…
Hi @teamofone - all of the answers above are great and very good hints.
It is mostly the team spirit, so maybe also show the devs the test strategy and how you do want to work or include within the project, make them part of testing - like in whole team testing.
you need some people, particularly one who can enforce some processes who would support your ideas
I agree. It sounds like you have quite a challenge on your hands, and that support from “higher ups” may be necessary. I’m sorry to say it, but with this kind of culture, the team may not take your position and / or expertise seriously enough to listen to what you have to say, without someone with more “official authority” backing you up. It’s not nice to have to enforce stuff, but if people are so unwilling to work together - even with other devs - then it may be the only way to start changing things.
Another suggestion would be to do a kind of “proof of concept” or “case study” with a team who is more willing, or already doing some of the things you’re advocating for. You can try to gather some data and or / sentiments from that team which show the benefits of what they’re doing, and translate that into solutions for the pains your team is currently facing.
And on that note - try to drill down on what they see as pain points, both for the team and as an individual. It will help a lot if you can get them to care somehow, and the idea of making their lives easier could help with that. At the same time, find out why they’re so resistant to the things you want to introduce. Maybe they’ve had some bad experiences and need some reassurance that it won’t go the same way, or perhaps they even want to do these things, but they’re tired and jaded from past failed attempts and don’t see why / how this time should be different.
you need some people, particularly one who can enforce some processes who would support your ideas 
