Time Division Multiplexing (TDM) in Project Critical Resource Management

The management of the Scrum methodology team has gained widespread use due to its simplicity and the ability to apply “out of the box”. The situation is more complicated when several teams work within the framework of one project. In this case, the hierarchical Scrum-on-Scrum model is used. But here's what to do when there are several development teams and one tester team.

I think any project manager who has managed the project for more than 10 people has encountered the following problem:
• Several team work on one project. The need to divide the team into several tims arises from the fact that the project is large, and clean Scrum does not work for teams of more than 9 people
• A group of testers is less than 9 people and can be formed into one group.

The simplest solution would be to break the testers by team and give 1-2 testers to each team of programmers. But here's what to do if it is beneficial to use testers as one group. This may be useful if testers are heterogeneous in experience and competency. Which, as a rule, is always present.

The simplest solution that does not require management is the queue method - whoever posted the task before, the testers begin to check by extracting the task done (taking into account priorities) from the general pool.

But here lies the problem - tims begin to conflict under the division - “Why aren’t they testing us?” The testers themselves also experience discomfort from such a situation and the feeling that they are “torn apart”. Testers begin to complain about the lack of resources and ask to increase the number of testers.

This task, in fact, is of a general nature., As soon as it becomes necessary to manage a team with a critical resource and multiple access to this resource, or when the process flow is not purely linear, there is a block accepting tasks from 2 or more blocks.



Now I will describe the solution, the solution that was applied in the project, from three team developers and one team testers. Tims start their sprints with a shift of 3 days. Classic Sprint Size - 2 weeks. Testers take the tasks of each individual team on the 4th day from the beginning of his sprint and on the last 2 days of the sprint. As a result, we get such a schedule.



Within one week, Tim testers have one reserve day. The last 2 days, the team’s tims plan the next sprint and fix bugs from the backlog, of course, not forgetting about the bugs found in the current sprint. Such an organization has helped relieve stress from testers and increase the responsibility of developers. Complex tasks are done first in the sprint, to check on the 4th day of the sprint. Developers also understand that it is advisable to take tested 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.