This is the output of the second group. The “bottleneck” of this system is easy to spot: everything has to go through 2 people. The stacks of work in front of each person indicates how much work in progress accumulates in front of each resource.
Click to enlarge the image
(picture courtesy of Marc Evers)
Some remarks
The goal of the system is to “add functionality” to an existing system. This functionality creates value only when it’s delivered to the customer. But that seems to take an inordinately long time, as the snoozing customer would indicate.
The bottleneck is the Development Manager (DM), with the Project Manager (PM) as bottleneck-in-waiting. All the work has to go through these two people. In the case of the Development Manager, all work goes through them several times: the DM carefully prepares and assigns the work to the developers, helps them design and develop and then the work has to come back for review(s).
How can we improve this situation?
- Currently, the PM explains the required functionalities to the DM. The DM then explains the functionalities to the developers. We could exploit the DM by having the PM explain the functionalities to the DM and developers at the same time. This could help break the “barrier” which now exists between business and development.
- If a few developers have more experience, they could subordinate to the DM by helping other developers and reviewing their code.
- We could elevate the constraint by hiring someone else to take on some of the duties of the DM or by training the most experienced developer(s) to take on some of the DM work.
However, these interventions might not be easy. It’s a stressful, difficult job, being the bottleneck. But it also make one very important. Having to delegate some of the work might be seen as “not being up to my job” or reduce the bottleneck’s importance.
The “barrier” in the system could be caused by the DM wanting to “shield” the team from the rest of the organisation. This way, the DM controls everything that goes in and out of the team. Some of the TOC interventions might reduce the amount of control the DM has. This too might be a touchy subject.
I do have a question about this diagram. How does the software get from the developers to the end user? We saw that the code goes back to the DM, for review. What happens next? Is there a Q/A procedure? Does the software get packaged, distributed or installed?
