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.