> why do you not explain a bit more about the ideas of TOC? I really
mean the ideas, the principles and the basics.
First, here is my XPday2004 powerpoint presentation:
It is better viewed in powerpoint, rather than in the browser, so I
recommend that you save it to your local drive and then open it.
In this talk I covered 3 aspects of goldratt's Theory of Constraints as they
apply to software development which conveniently overlapped with the three
conclusion from the HBR article, "Getting the Most out of Your Product
Development Process" by Adler, Mandelbaum, Nguyen, Schwerer [HARVARD
BUSINESS REVIEW, March-April 1996, p. 136]
1. The first conclusion "Investments to relieve bottlenecks yield
disproportionately large time-to-market benefits".
This conclusion is what TOC is best known for - managing bottlenecks. I
cheated here and showed this excellent animation:
that elegantly and
humorously demonstrates how to manage processes.
The animation shows a facotry and it's quite easy to understand when you see
physical work flowing (or not flowing).
But it's not so easy to translate to software development where the
work-in-process is mostly invisible. If you're in a waterfall enviornment
the bottleneck is probably hidden under the pile of uncompleted-work. The
secret in the environments is to ask the old timers. Give them a few
minutes/hours/days and they'll probably all agree that the same
skillset/department is the bottleneck. In lot's of places it is
unnecessarily the DBA department or "the customer". In my last big
waterfall project everyone knew that lack of actuaries slowed down every
Agile environments make it easier for 3 reasons. First, the "rules" tend to
eliminate the typical bottlenecks (e.g. customer on site helps remove the
customer bottleneck, generalists rather than specialists helps remove the
DBA bottleneck). Second, working in small iterations removes the massive
amount of WIP which is hiding the bottleneck. Third, the true bottleneck
will start screaming out for attention during the daily meetings when it
appears time-after-time, across many projects as an obstacle.
2. Conclusion 2 was "Projects get done faster if the organisation takes on
fewer at a time"
The powerpoint annimation shows how most organisations try to do too many
projects at once, which forces staff to multi-task between projects. Run
the animation and you'll probably be surprised to find that working on less
actually acheives much, much, more. (Each project is shorter, the total
cash flow is much higher)
Trust me here: run the multi-tasking animation three times. There is no
smoke and no mirrors. Multi-tasking is evil and killing your productivity.
3. Conclusion 3 was "Eliminating unnecessary variations in workloads and
work processes eliminates distractions and delays, thereby freeing up the
organisation to focus on the creative parts of the business"
I use a simplified, animated version of Goldratt's "Current Reality Tree" to
build up the cause-and-effect into a 1 page tree that shows how using the
waterfall sdlc causes a massive amount of "unncessary variations" (i.e.
avoidable rework), which is way beyond the capabilities of the critical path
project mangement system to cope with.
You can find the detailed work behind this here:
But, be warned, this is a work
in process and might be somewhat confusing if you haven't followed it along.
This is the basis of my Goldratt-esqe business novel I'm currently writing
> The processes that Goldratt describes are very hard to do --- you know
this ... you
showed it at the XP Days in London last year.