Identify, Exploit, Subordinate, Elevate

One of the concepts of ToC is to IDENTIFY the bottleneck, figure out how to EXPLOIT it (how to use it), SUBORDINATE other processes to support it (realign processes) and figure out how to ELEVATE it, so that its less of a bottleneck.

We recently had a problem where the constraint (bottleneck) within our team is a particular senior developer. This is not to say that the developer was not good, but rather the opposite. He was *too* good. This person has a lot of experience compared to the rest of us, as it is a relatively new team. This developer knows the history of the current application, and the one that came before it and has the contacts within our organization (a large enterprise). This developer would also frequently play the role of a business analyst and generate requirements.

From the outside, it looks like this guy's a star (he's very valuable), but think of the team. If he is the constraint, then wouldn't all the shifting between tasks lead to other resources idling?

This was the case in our team. He felt that he was stretch and working 50-60 hour weeks and some of the rest were idling and on facebook for significant parts of the day.

From the ToC perspective, we should determine how to exploit the bottleneck. The most valuable function for him was to generate requirements. Not just any requirements, but QUALITY requirements.

The first step is to IDENTIFY the constraint. This meant identifying which of his functions and responsibilities carried out by others. This involved work that did not require much undocumented knowledge, like building new features or fixing defects. What remained is the core constraint. Once we freed up some of his time, hence capacity, we identified his most important function - a business analyst. Generating requirements will allow the developers to be able to do just that - developer software.

Secondly, we have to EXPLOIT the constraint. He was made a business analyst and generate requirements. To minimize the level of rework for both requirements and code, generated requirements are vetted and reviewed prior to start of work, thus SUBORDINATING the process. This usually leads to higher quality requirements as gaps are identified and the review process would lead to better understanding of the requirements and allow the developers to generate better estimates.

Lastly, we attached junior business analysts to him. The junior BAs would follow up on communications (relationship building) and to write the first draft of the requirements (to gain knowledge and experience). This ELEVATES the constraint.

The results were good, but other challenges would arise such as personal interests and perceptions of the individual's career progression, but that's a story for another day.