Testing Issues with Scrum
I am a Scrum Master for a team consist of developers and testers. We are currently following 3 weeks Sprint. In my team testers don't want to any development and the developers don't want to involve in regression testing. Because of this situation below scenarios arise.
1. At the beginning of the Sprint, testers are creating test cases but they are releatively free
2. During the last week of the sprint, testers are busy with regression testing and developers are relatively free. Sometimes, the developers start to look into the US planned for next Sprint.
Please let me know your suggestions to resolve above issue.
Please let me know your suggestions to resolve above issue
If the team don't want the issue to be resolved, who does? Is there an incentive or sense of urgency for resolution, and if so where does it come from?
why don't they want to work together on this? Do they not understand the value of working together? Typically when testers and devs work together, test cases are higher quality and fewer bugs are found.
As the SM, are you coaching the team on the benefits of cross-training and working together?
To me, this seems a possible issue around team maturity. Is there a strong "us" versus "them" dynamic within the team? What progress have you made regarding full team ownership and responsibility for their sprint forecast?
Bottom line though (alluding to Ian's comment), if the team is consistently reaching their Sprint Goals and completing their Sprint Forecasts, who is bringing up the issue on how the team is self-managing around the work?
Remember that a team is self-organizing. If they choose to organize in this manner and work in miniature waterfalls (yes that is how I see it) but are still able to meet their Sprint Goals, then they are working according to Scrum. Does the Development Team see this as a problem? If not, who does and why? If it is someone outside the Development Team then as Scrum Master it is your job to help them understand the self-organization aspect of Scrum.
Sometimes, the developers start to look into the US planned for next Sprint.
That doesn't seem like a problem to me as long as they are not working on the stories. If this "look into" is for refinement purposes, then I would encourage it. I would also be encouraging the testers to be doing the same during their idle time periods.
As others have mentioned, as Scrum Master I would be delving into the reasons that the teams sees no need to work across boundaries. As a self-organizing, cross functional team they need to see the benefits of cross functionality.
1. At the beginning of the Sprint, testers are creating test cases but they are releatively free
2. During the last week of the sprint, testers are busy with regression testing and developers are relatively free. Sometimes, the developers start to look into the US planned for next Sprint.
Is it important to keep everyone busy at all times?
The Development Team should be accountable for the increment they are producing, but whether they have free time or not is arguably irrelevant.
Can the Development Team deliver more value or better quality if they organize themselves differently?
Can the Development Team deliver more value or better quality if they organize themselves differently?
And one related consideration: Could this also enable them to deliver "Done" items more quickly?
Maybe they are meeting their Sprint Goal and delivering a release quality Increment every Sprint, but a Scrum Master can always be a mirror to the team and help them get better to improve their quality practices.
Imagine what it might look like for this Development Team if they learned and started to put into practice modern engineering practices from XP, such as Test Driven Development, automated regression tests running with CI/CD, pairing and a collective code ownership mentality?
I agree with Chris !! As per me i think either team may not be aware or may be not comfortable in trying new approaches.
Though the team is meeting their well crafted Sprint Goal , but SM should create an environment for improvements.