Can TOC and Agile work together? (part 2)

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!

A businessman trapped inside a bottle trying to crawl out through the neck with his partner pulling on the cork from the outside

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.


[Reblog] Star Wars day Retrospective

This time I am sharing with you an idea by Lisa Fineberg regarding having a retrospective in a Star Wars style, taking some nice quotes from the movies as inspiration for situations that happened during the sprint.

Here is the link: Star Wars day Retrospective


Can TOC and Agile work together? (part 1)

A little background, before we dive into my answers on this question: (oh, and by the way, for all you Star Wars fans, this post (and the other parts to follow) are not Star Wars related in any way. Sorry).


When I first came to know TOC, back in 1997, its applications were primarily around production lines,  floor manufacturing, distributions, even sales, but very little around project management and software development. Actually, in 1997 Goldratt’s Critical Chain was published and the project management application started to take off. You could argue that Software development had started around year 2000 when Necessary but not sufficient was published. Anyway, back then, using TOC for software development was not very common.

Back then, Agile was not invented yet.

Thinking about it, both TOC and Agile were developed while inspired by Lean. TOC was invented while working on the Drum-Buffer-Rope solution for manufacturing (which later on became the TOC application for operations) which was a competitor of the Just In Time manufacturing principle of Lean. drumAgile was invented as the Lean way to develop software. So it will not be wrong to say that while Agile is very similar to Lean, TOC is a competitor of Lean, and not a follower. This is why my question in the title is relevant – it might seem that Agile and TOC are two different ways of managing a software project, thus will probably not work together.

This is of course not the way I see it. I will try to explain my view on how Agile and TOC can and should work together in a few posts. I am also planning on doing some live experiments (already did one a few years ago) and will post here how they went.

So let’s start with a very simple explanation why there shouldn’t be any problem in applying both TOC and Agile. The reason is that TOC in general, if you put aside the different applications it already has, is mainly about helping you to think straight and come up with ideas to solve your problems. These are the thinking tools of a Jonah, these are the 5 focusing steps to exploit a constraint. FIG-toc-5fsAgile is also a mindset, with different frameworks, but still a mindset of how software development can get better. At least in my view, neither TOC, nor Agile, claim to be the only correct way to solve your problem. Instead, they both try to help you, giving you some tools, some ways to focus, some directions to look at. In that sense, as long as you are not a fanatic about neither of them, it is obvious that the more tools you have, the more options you have, the likelihood is that you will be able to solve your problem and do better. Once by discovering your current constraint, the other time by making your team much more collaborative. It may even be the same solution to the same problem.

Theoretically, I believe we established that there should not be any problem doing both. In the next parts of this idea, I will get into the more tactical options of using TOC and Agile together.

As always, if you have any comments, or disagree with anything – please let me know.

Star Wars Land Coming To Disney Parks, 4 Star Wars Attractions Detailed, And More – D23

Star Wars Land Coming To Disney Parks, 4 Star Wars Attractions Detailed, And More – D23

Sent via BlinkFeed

The ultimate weapon

When it comes to a Jedi, the ultimate weapon is simple – the lightsaber. It’s true that the master of the force will use the force barehanded to solve most of the more simple situations, like persuading someone, open doors and such, but when the Jedi faces a difficult challenge, whether it is a Sith, or an army, the Jedi will take his lightsaber out and show his true power. Take for example the battle between Yoda and count Dooku on episode II. They start off with some force tricks, soon realizing that these will not prevail, and they battle it out with their lightsabers.

It is obvious this contest cannot be decided by our knowledge of the force, but by our skills with a lightsaber (Dooku).

Top 5 lightsaber fights. Did you notice that most of the time the Jedi will win the battle?

But what about the ultimate weapon of the master of agile? When an agile coach faces his greatest challenge – what is his weapon of choice?


To tell you the truth – I am not sure. I think that like the Jedi uses the power of the force for the more easier issues, so does the coach use tips and tricks, games and best practices to overcome an obstacle. But when it comes to a complex obstacle, even a duel with a “Sith” (a representative of the dark side that takes advantage of the agile methodology for his personal goals) these games or tips will not suffice. I reckon that in such cases, the coach will go back to the basics – to the principles of agile methodology, maybe even to the Agile Manifesto, to fight the fight, to overcome and be able to deliver the message.


For example, let’s say that you go into a retrospective, where the only one who talks is the manager, saying how well he thinks the sprint/release went, and where he thinks the team can improve. When you approach him, on the side, and ask about that, he would say that he thinks the retrospective went very well, and that this is the most productive way of doing it. So he is presumably using an agile approach for ongoing improvement, such as the retrospective, but he is doing it in such a way that the team will not see its value and will not look for the next retro. Explaining the need for retro or for ongoing improvement is not the issue here. It basically comes down to individuals and interactions, where the team needs to improve so the team is the one responsible to conduct a retro, find where things did not go as planned, or as they could, and try to improve there.

I believe that when going back to the basics, that’s where the real power of the agile coach lies, and that’s where he can beat any pretender. Just like a lightsaber duel, where most of the times the dark side will lose.

Here you can decide on your own who wins…

What do you think? What else would you categorize as the ultimate weapon of the agile coach?