Agile Constraints

This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”.  TOC’s approaches constraints from an overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system.  So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck.  This requires you to focus on five steps to remove your bottlenecks:

If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up.  Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.

 

And sure enough, others in the Agile community have made use of the manufacturing technique known as Kanban.  This technique sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently.  This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack.  At some point the “flow” would resume.

 

This is a very interesting integration of various techniques to remove bottlenecks in your projects.  How are you dealing with constraints in your projects?

But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently.  This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack.  At some point the “flow” would resume.Projects whether they are done Agile, waterfall, extreme, or whatever [insert favorite practice here], boil down to a series of interconnected tasks that require you to manage and reduce the variations between them to make sure they are done on time and within budget.  Often times what prevents you from reducing the variations are constraints.  In other words, some 

bottleneck is constraining you from reaching your optimal throughput.

 

This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”.  TOC’s approach is from a overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system.  So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck.  This requires you to focus on five steps to remove your bottleneck:

 

Locate the bottleneck

Maximally exploit the bottleneck

Subordinate everything else to exploiting the bottleneck

Elevate the bottleneck (add capacity some other way)

Avoid inertia and keep checking your bottleneck hasn't moved

 

If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up.  Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.

 

But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently.  This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack.  At some point the “flow” would resume.