I just finished reading "The Phoenix Project" and really liked it. One of the things it talks about is "Hand Offs" between resources.
It says that "Wait times for a given resource is the percent it is busy divided by the percent it is idle". So an 80% busy resource has a wait time of 4 units. While a 90% busy resource is at 9 units of wait. And a 99% utilized resource is at 99 units of wait for a new item needing work at that resource..
We have serious wait time issues at my company when tasks transfer between teams. Basically each team is busy with their own work and the work from another team has to wait on that team's priorities. (Only in very extreme scenarios is something "expedited".) And I am planning to add more hand offs in our process in the future!
Reading this made me think that perhaps I had found a possible answer to our issues. So I wanted to find corroborating sources for this concept before I suggest it to our CIO.
But when I went to google I found very little literature related to this concept that is not connected to "the Phoenix Project" (or computer science queuing theory).
Is this a management concept that comes from "The Phoenix Project"? Does it have a name? Does it actually work? Are there any case studies to show success or failure?
I am also interested in how this can actually be done. (Do you really tell the teams to plan on watching YouTube for 20% of their time?)
My company has hundreds of internal product. As we move to a microservices environment, changes will be needed to those services that will not always align with the schedule of the team that knows how to make the change.
I plan to introduce a "pull request" system. Where the team that needs the change to the microservice, codes the change as a pull request. Then which ever team that the microservice belongs to can merge or reject the pull request.
But even pull requests take time. (They need reviewing, testing, releasing etc) So I am trying to find a way that I can reduce the wait times of the team that makes the pull request without also adding a lot of disruption to the core team of the microservice in question.