The first AgileNorth of the new year was kicked off by an active session on the “Theory of Constraints” run by Kevin Rutherford and David Draper.
It was a re-run of a session from the Agile North conference - I'm not a Bottleneck, I'm a free man!
The Theory of Constraints (TOC) is a management philosophy that aims to continually achieve more of the goal of a system. Every system or process must have at least one constraint, which prevents the system from achieving a better result relative to it's goal. In order to increase the performance, these constraints must be identified and removed one by one.
There is a five-stage process to go through to follow TOC once you have clearly identify what the goal of the process is, e.g. better quality, more widgets, less wastage:
The focus is always on one constraint at any one time – never attempt to address more than one problem area.
The main part of the evening was spent doing a practical exercise that demonstrated the Theory of Constraints quite clearly. The goal was to maximise the number of paper hats and boats pairs made in a short period of time. There were 6 of us attending so we formed a circle and were given different roles perform:
The first round started and we immediately noticed that all the paper was stocking up by the developer who was starting to rush and make mistakes, most of the rest of us were sat around doing nothing. Therefore the 'constraint' was the developer. We struggled to see how we could 'exploit' the developer so we 'subordinated' some tasks: we decided to ensure that it was clear whether the item was to be a hat or a boat (this had caused confusing during the first round) and would pass the paper to the developer in order, hat – boat – hat -boat to ensure enough 'product' was released.
On the second round we noticed that the bottleneck was still with the developer, the boats were taking nearly twice as much time to make as the hats. We decided to 'elevate' the constraint by 'training' the UI guy to take over the creation of the hats so that the developer could concentrate on the more complex boats. This time most of us were sat doing nothing for longer and yet we were able to get more products out the door – we were more productive whilst doing less work!
With the 'training' complete ;) we performed the third and final round and this time came out with some very positive results. This time the constraint had moved to the designer who was having to reject certain paper sizes due to it being too hard to make the hats and boats. This showed that if we had given the 'supplier' a template for the source paper we could have removed this bottleneck and sped up even further.
Here are the results of the three rounds:
It was a very interesting session and I think we all had some fun as well. It would have been good if we had more some spare time at the end to discuss possible ways in which you could spot the bottlenecks in a software environment. I enjoyed the active format and Kevin and David ran the session very well.
Technorati Tags: AgileNorth, Theory Of Constraints, Andrew Beacock
It was a re-run of a session from the Agile North conference - I'm not a Bottleneck, I'm a free man!
The Theory of Constraints (TOC) is a management philosophy that aims to continually achieve more of the goal of a system. Every system or process must have at least one constraint, which prevents the system from achieving a better result relative to it's goal. In order to increase the performance, these constraints must be identified and removed one by one.
There is a five-stage process to go through to follow TOC once you have clearly identify what the goal of the process is, e.g. better quality, more widgets, less wastage:
- Constraint
Find the largest constraint that is holding you back from achieving that goal. Note: you are not trying to fix any and all problems or possible optimisations that you find, just the largest key bottleneck. - Exploit
Try to optimise the bottleneck to get maximum performance, e.g. remove any unnecessary tasks (timesheets, walking across the factory floor, etc.) from a worker who's duty has been highlighted as the bottleneck. - Subordinate
Move some of the constrained worker's tasks to other people/processes to free up the key worker to allow the bottleneck to be removed. - Elevate
If the above “free changes” (exploit and subordinate) don't help remove the constraint then introduce a “costly change” e.g. training, additional staff, etc. - Repeat
If the constraint has now moved, go back to step one and repeat the process.
The focus is always on one constraint at any one time – never attempt to address more than one problem area.
The main part of the evening was spent doing a practical exercise that demonstrated the Theory of Constraints quite clearly. The goal was to maximise the number of paper hats and boats pairs made in a short period of time. There were 6 of us attending so we formed a circle and were given different roles perform:
- Analyst – received paper of differing sizes from the supplier and was told whether it would be a hat or a boat
- Designer – would perform some of the critical early folds
- Developer – did most of the folding of the paper
- UI – added pictures to the sides
- Tester – ensured that the made objects stood up, had the correct design, was neat and tidy, etc.
- Production – checked quality and released 'product' - hat/boat pairs.
The first round started and we immediately noticed that all the paper was stocking up by the developer who was starting to rush and make mistakes, most of the rest of us were sat around doing nothing. Therefore the 'constraint' was the developer. We struggled to see how we could 'exploit' the developer so we 'subordinated' some tasks: we decided to ensure that it was clear whether the item was to be a hat or a boat (this had caused confusing during the first round) and would pass the paper to the developer in order, hat – boat – hat -boat to ensure enough 'product' was released.
On the second round we noticed that the bottleneck was still with the developer, the boats were taking nearly twice as much time to make as the hats. We decided to 'elevate' the constraint by 'training' the UI guy to take over the creation of the hats so that the developer could concentrate on the more complex boats. This time most of us were sat doing nothing for longer and yet we were able to get more products out the door – we were more productive whilst doing less work!
With the 'training' complete ;) we performed the third and final round and this time came out with some very positive results. This time the constraint had moved to the designer who was having to reject certain paper sizes due to it being too hard to make the hats and boats. This showed that if we had given the 'supplier' a template for the source paper we could have removed this bottleneck and sped up even further.
Here are the results of the three rounds:
| Round | 1 | 2 | 3 |
|---|---|---|---|
| source paper | 12 | 10 | 12 |
| completed products | 1 | 2 | 3 |
| wastage/work in progress | 10 | 6 | 2 |
It was a very interesting session and I think we all had some fun as well. It would have been good if we had more some spare time at the end to discuss possible ways in which you could spot the bottlenecks in a software environment. I enjoyed the active format and Kevin and David ran the session very well.
Technorati Tags: AgileNorth, Theory Of Constraints, Andrew Beacock
Comments