Agile Mumbai 2010


Using Theory of Constraint and Just-In-Time Practice to coach Agile Teams


To share our experience coaching agile teams. We'd like to present:

1. How to apply Theory of Constraint [ToC] to identify the bottlenecks or issues the teams are facing during their agile adoption?
2. Once we identify the bottleneck, how we delivered knowledge and experience to the teams, just in time to apply that knowledge to eliminate the bottleneck, using the Just-In-Time practice concept?

Intended Audience

This paper is targeted at agile coaches and practitioners who help other teams adopt agile. Since this paper will present an approach to adopt agile practices, it can be helpful to teams who are in the process of or are planning to transition to agile.


90 mins talk



Over the last several years, We've helped enterprise architecture and application teams at various organizations to adopt agile practices. The management was sold that agile would help them improve their development process. We were assigned the task of making the teams more productive by using agile methods.


The big question was, where do we start? We could take the XP white book and slap all the 12 practices on them. But we knew that would certainly not work. Also, we did not know what were the real issues from the team's point of view? Different stakeholders had different things they wanted to improve. It was not clear what the real issue were?

So the question is where do we start?


Well, conducting a team retrospective felt like a decent option. So we started with a retrospective. During this we got an initial list of issues [which are really user stories for a coach] that the team wanted to resolve. At the end of the retrospective, we had our master story list or product backlog [list of issues faced by the team, which we would help them to resolve]. We took this list and asked our customers [the team] to prioritize the issues. They were asked to prioritize, based on what hurt them the most and fixing which issue, will deliver max relief to the team.

Though this was a good beginning, the issues were quite superficial or abstract. In some cases they looked more like symptoms than causes. We needed a better way to find out the real issues, a tool to do some form of root cause analysis and understand the big picture.

So we started considering the whole team's activities as a set of workflows. Typical examples of team's activities are Upgrade to new version of software X. Or. Fix a bug in one of the architectural modules developed by them. Thinking of the system as a graph [workflow] and using techniques like Value Stream Maps and others, gave us some insights into what could be their potential bottlenecks in terms of process and people.


Soon we found ourself applying ToC to find out process/people bottleneck in the system. Subsequently, we discussed this with the team to see what they think can fix the problem. We're consciously trying not to overload them with practices. We wanted the team to own those practices. We would help them figure out what works and what does not, what effect the practice has on the team dynamics, etc. We was trying to deliver the knowledge and experience to the teams, just in time for them to apply that knowledge. Once we figure out the problem at hand; the technique of picking up a practice that can address the problem in the simplest possible way is known as "Just-In-Time practice". One has to carefully craft out the version of the practice that would give them the fastest feedback. In other words, set up the practice so that if it fails, it fails fast.


We've successfully applied TOC to identify the issue teams face during their agile adoption phase. Using the Just-In-Time practice helped me facilitate this transition better.


J. B. Rainsberger & Naresh Jain


2005-2019 Copyright © Agile Software Community of India
Website designed and hosted by Xnsio