Developer and QA friction
Need suggestion .
My developer and QA have friction. Apparently my QA might have been on leaves when a story would have gotten discussed. The story was never assigned to him and now there is a bug on the same that he needs to retest which is assigned to him. There is no other QA left so he has to retest it.
He reached out to the developer with questions. The developer escalated that he is asking basic questions and should have at least taken a basic understanding of the story before taking his so much time.
He is a senior QA and been with the project for 2 years so I do agree that ppl should do some ground work so that we can value everybody’s time. However, I also believe that the developer should have been more co-operative. The developer said he can’t explain same thing to everyone and ppl should take responsibility as well.
How at a SM level should tackle this situation. The QA is indeed a little slow and takes time which can be frustrating.
Apparently my QA might have been on leaves when a story would have gotten discussed.
Where was he during Sprint Planning? If he wasn't there, why was the team planning to complete that work at all that Sprint? Achieving the Definition of Done each and every Sprint is a commitment.
The story was never assigned to him and now there is a bug on the same that he needs to retest which is assigned to him
Why is work being assigned to people at all? What sort of commitment is likely to result from a practice like that, and might it explain the trouble you are having? Remember that in Scrum, the commitments people make for themselves are more likely to be achieved than commitments made by others for them.
Generally, it seems like there's tension between the developer and the QA. I'm not sure if this is real or if I'm reading too much into your wording, but it doesn't seem like there's a cohesive team of Developers who have all of the skills and expertise to create the usable Increment. Instead, it seems like there is a silo between developers and testers. I think it's natural, and perhaps even good, to have specialists in the different areas on the team, but they should be a cohesive unit that collaborates to get the work done and deliver one or more Increments by the end of the Sprint.
The organizational issues aside, the fact that a key participant in the work may not have been present for the discussion of the work indicates that there may be issues around Product Backlog Refinement and/or Sprint Planning. There shouldn't be much, if any, confusion about the work selected for the Sprint. The whole team should generally understand the Sprint Goal, the Product Backlog Items that were selected for the Sprint, and how the selected Product Backlog Items relate to the Sprint Goal. This knowledge helps the team plan and organize themselves around delivering the most valuable work by the end of the Sprint, with an emphasis on the outcomes that the Increment enables.
Unfortunately, I think there may be some missing context here that prevents me from giving any kind of specific advice. Is the developer not aware that the QA may not have been present during the refinement or planning of this piece of work? Who else has the developer been explaining things to and why weren't the key people from across the team present in one session? Why is the QA slow and is anything being done to help speed things up, especially if this is an ongoing or recurring frustration from the team?
This is an organizational issue. With one of my clients who was building a new team, I advised them to have 360 degree developers who could do everything (code, test, deploy, etc.). The developers respected each other, unit tested each other's work, and things ran well. I've yet to see the benefits of having an entire QA organization as a separate entity. I think that "testers" are remnants of the legacy SDLC.