Team management by Scrum methodology has gained widespread use due to its simplicity and ability to be applied "out of the box". The situation is more complicated when several teams work on the same project. In this case, a hierarchical Scrum-on-Scrum model is used. But here’s what to do when there are multiple development teams and one team of testers.
I think any project manager who managed a project with more than 10 people faced this problem:
– Several teams are working on one project. The need to split the team into several teams occurs because the project is big and pure Scrum doesn’t work for teams of more than 9 people
– A team of testers is smaller than 9 people and can be formed into a single team.
The simplest solution would be to divide the testers into tiers and assign 1-2 testers to each programmer tier. But here’s what to do if it’s advantageous to use testers as one group. It may be useful if testers are heterogeneous in experience and competence. Which is usually always present.
The simplest solution, which does not require management, is the queue method – the testers start checking who posted the task earlier, migrating the tasks done (taking into account the priorities) from the common pool.
But herein lies the problem – the teams begin to conflict under the division – "Why aren’t we being tested? The testers themselves are also uncomfortable with this situation and feel that they are "torn. Testers begin to complain about the lack of resources and ask for more testers.
This task is actually of a general nature, As soon as you need to manage a team with a critical resource and multiple accesses to that resource, or when the process flow is not purely linear, there is a block accepting tasks from 2 or more blocks.
I will now describe the solution I applied to the project, of three developer timems and one tester timem. Tims start their sprints with a shift of 3 days. The size of the sprint is classic – 2 weeks. Testers take tasks of each individual team on the 4th day of their sprint and on the last 2 days of the sprint. The result is the following graph.
During one week testers team has one reserve day. The last 2 days developers team plan the next sprint and fix bugs from the backlog, of course not forgetting the bugs found in the current sprint. Such organization helped relieve testers from stress and increase developers’ responsibility. Difficult tasks are done at the beginning of the sprint, to be checked on the 4th day of the sprint. Developers also understand that it is desirable to hand in checked solutions at the end of the sprint, otherwise the bug found on the last day will have to be transferred to the next sprint without closing the task.