How to apply "Theory of Constraints" to coach agile team?
Well, I don‘t have any great expertise in TOC. All I know about TOC is what I have heard from people and from Gold Ratt‘s books and articles.
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results By David Anderson is a good read. He talks about applying TOC to decrease the time to market and hence better business results.
I have used similar thinking process.
The way I used TOC is:
I started considering the whole team‘s activities as a set of workflows. I took each workflow and converted into a graph. This showed how much time and efforts were spent to transition from one state to another. This helped us identify the longest edge in the graph, which is a potential bottleneck in the system. Once you have the bottleneck, the plan is to minimize the amount of time it takes to move from one node [activity] to another by applying an agile practice that suits the best.
Example:
Activity: Fixing a bug
|No..|Node..|Acitvity…………………….|Date and Time…..|Time in Days|
|1…..|A……..|Bug reported……………..|June 10, 2006…..|0……………..|
|2…..|B……..|Reproduce the bug……..|June 18, 2006……|8…………….|
|3…..|C……..|Write a failing test……….|June 20, 2006……|2…………….|
|4…..|D……..|Fix the bug………………..|July 10, 2006…….|20…………..|
|5…..|E……..|Regression testing……….|July 14, 2006…….|4……………..|
|6…..|F……..|Make a release…………..|August 14, 2006..|31……………|
|7…..|G…….|Bug closed by customer..|August 16, 2006..|2…………….|
[Unfortunately I cannot paste the graph. But the table should be self-explanatory]
In this example, it took 31 days for the team to get a release out of door. That is really a bottleneck in the team‘s performance. So it was important to fix this. The practice that came to my mind was Continuous Integration [CI]. In our case, since we were the architecture team, we had to establish CI with our customer‘s build every night. By doing so, we cut short the release time to 1 day.
So now we had:
Activity: Fixing a bug
|No..|Node..|Acitvity…………………….|Date and Time…..|Time in Days|
|1…..|A……..|Bug reported……………..|June 10, 2006…..|0……………..|
|2…..|B……..|Reproduce the bug……..|June 18, 2006……|8…………….|
|3…..|C……..|Write a failing test……….|June 20, 2006……|2…………….|
|4…..|D……..|Fix the bug………………..|July 10, 2006…….|20…………..|
|5…..|E……..|Regression testing……….|July 14, 2006…….|4……………..|
|6…..|F……..|Make a release…………..|July 15, 2006…….|1……………..|
|7…..|G…….|Bug closed by customer..|July 17, 2006……|2…………….|
Once we fixed the release issue, now we had the next bottleneck of fixing the bug which was taking us 20 days.
On asking the team why it was it so difficult to fix a bug, they complained that they had to do 20 things before they could fix a bug. There was obviously duplicate code and complicated design issues.
Next practice that came to my mind was Refactoring and TDD. These are big practices, but after a few days we could see that the amount of time it was talking to fix a bug was reducing. So it was a positive feedback cycle and the team wanted to do more of it.
