Time Division Multiplexing (TDM) in the management of a critical project resource

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

I think any project manager who led the project for more than 10 people encountered such a problem:
• Several tims working on the same project. The need to divide the team into several teams arises due to the fact that the project is large and the pure 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 easiest solution would be to split testers by tim and add 1-2 testers to each programmer. But what to do if it is advantageous to use testers as one group. This can be useful if testers are heterogeneous in experience and competencies. That, as a rule, is always present.
')
The simplest solution that does not require management is the queue method - someone who has previously posted a task, and testers begin to check it out by making the tasks that were made (taking into account priorities) from the common pool.

But here lies the problem - the tims start to clash under the division - “Why don't they test us?” The testers themselves also experience discomfort from such a situation and the feeling that they are being “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 that accepts tasks from 2 or more blocks.



Now I will describe the solution of the solution that I applied in the project, out of three developers and one testers. The Tima begin their sprints with a 3 day shift. Sprint classic 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.



For one week, testers have one reserve day. The last 2 days of the developer team plan the next sprint and fix bugs from the backlog, of course, not forgetting about the found bugs of the current sprint. Such an organization helped relieve stress from testers and increase developer responsibility. Difficult tasks are done first sprint, to check on the 4th day of the sprint. The developers also understand that it is desirable to turn in proven 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.