I'll be speaking at Agile Wellington on the 19th of February.
My subject: TOC & Agile.
Here's my rather wordy description:
If you could *magically* add 2 good, immediately-productive developers to your team, for free, would your team ship more? It depends, doesn't it? They'd write more code, but would you have enough test capacity to test it? Do you have enough work ready for them to work on? Would you be better *magicing* up 2 hours more customer contact each week? Or an extra tester? Is it possible that adding 2 more developers would result in your team producing LESS?
Every software development system has a bottleneck - a “constraint” - which limits it’s throughput. You might be “constrained” by your developers, though that’s unusual. It’s far more likely to be your testing capacity or you level of customer engagement. In mature teams it’s usually the malleability of your code.
If you don’t know where your constraint is then you are (almost certainly) operating sub-optimally.
In this session you will learn how to quickly identify your system’s constraint and how to operate far more effectively given your constraint.
I’ll share a simple, scalable model you can use - when you get back to work the following day - to apply Theory of Constraints (TOC) thinking to your team, department or division. I'll share an (easily repeatable) story which will help you avoid, or fix, the most common cause of Agile failure. I’ll show you how to use TOC thinking to better chose what features and stories you work on. I’ll show you how (counter-intuitively) to use your new TOC knowledge to choose better technical solutions.
Bold claims? Don't be put off by the “theory” part of TOC - this stuff works in practice. It’s my day job. I discovered TOC, in 1996, (when I was a technical PM for WestpacTrust), I first used it in anger in software development in 1999 and I've used it since. David Anderson’s version of Kanban is based on TOC. Much of Mike Cohn’s planning and estimation work is based on TOC. TOC works and is far easier to implement in software development than most people think. I’ll show you how.