In part 1 of this series of posts, I have looked at the origins of both Agile and TOC, and established that both talk about mindset and ways of solving problems, and not necessarily about specific, maybe contradicting, actions that need to be taken.
In this part, I will share with you an experience I had while being an agile project leader and thinking the TOC way. I think this is a nice example of how TOC and Agile can work together.
As an agile project leader, I was helping 3 scrum teams to work on their projects. I was mentoring the Scrum Masters, the Product Owners (sometimes acting as one myself) and the relevant team leaders. One of them was the QA team leader, and she was bringing to my attention that usually, when a project starts, there is not a lot to do QA wise, but always, when the project is about to finish, the amount of work left for QA is much more than they can handle. Not that I didn’t notice this before, but it came to be very apparent and visual once we started using Scrum and agile techniques.
TOC was not something that was officially considered where I worked, nor did we even discuss it, but it is always with me, ever since I participated in the Jonah program in 1997. So when the TL approached me, concerned about this problem, it immediately struck me that QA is our Herbie. The last milestone of almost every task is its testing, and there is always not enough testers to do the work right at the end, though they are almost idle right in the beginning. This is our current constraint/bottleneck!
So we started to come up with ideas on how to exploit this constraint, again without really mentioning the TOC steps or anything similar. First we looked at all the tasks that the QA team members are doing and started to find tasks that can either be postponed to post-release (which is best, considering they are usually less busy at this point of time), or can be done by someone else. This was a start. We then came up with the idea to plan the project in such a way that the testers can either start testing right from the start, or can participate in some other tasks in the early stages of the project, that originally were done by coders. This changed a bit our prioritization of the project’s User Stories, but all in all we saw that the throughput of the team has increased.
A project or two later, it became obvious that QA was no longer our bottleneck, which was a very good sign that we exploited it well, but we now had to deal with a much more complicated problem. Knowing TOC, I knew this is coming and was prepared to shift my attention to other areas, which now needed help. More on this in a future post.
So, to summarize, while working in Scrum, and thinking TOC, we were able to find our constraint and exploit it so that the throughput – the amount of work that the team was able to do in a time period – was getting higher noticeably. Agility and Scrum gave us the visibility and the collaboration of the whole team to solve the “QA” problem, and though probably we could have come up with the same solution without using TOC, for me it was very clear that the 5 steps and the notion of finding the bottleneck and exploiting it was the thing that helped me to increase our velocity in this case.