malvasia bianca

I just finished another one of Eliyahu Goldratt’s business novels on the Theory of Constraints. I didn’t lose sleep over it the way I did with The Goal, but it was quite good. And useful to see ToC applied to product development situations, instead of just manufacturing situations.

One thing that caught my eye: not only does it speak somewhat ill of Just in Time, it lumps the latter together with assembly lines. Only somewhat ill, to be sure: assembly lines and JIT are both successful in limiting the amount of inventory that can accumulate between stages, limiting the waste of overproduction. TOC agrees that that’s a good idea in general; but it’s really focused on alleviating the ill effects of bottlenecks, which means that while it’s happy to have production stages that aren’t involved in bottlenecks be idle when not needed (as JIT supports, but perhaps assembly lines have a harder time with?), it wants to make sure that there’s material ready to allow bottleneck production stages to be active whenever possible. Mind you, TOC doesn’t want pre-bottleneck stages to produce for the sake of production, but they definitely shouldn’t run the risk of letting the bottlenecks be idle.

So: who’s right? TOC or lean (of which JIT is a component)? I’m pretty sure I’ve run across favorable mentions of The Goal in lean discussions, so I doubt they’re too strongly opposed. (It would, of course, be inconceivable that both are wrong: I couldn’t possibly be obsessed with two areas of thought that are both mistaken.)

Of course, lean isn’t just JIT: there are other tools in there. And doubtless part of the answer is that, because of the increased predictability that lean’s high quality gives you (via its other tools), the need for TOC-style production buffers is lessened. And kanban, the technique by which JIT is maintained, could probably be used to get TOC-style buffers. Kanban is the pull-style mechanism where each step requests new material from its predecessor by handing it containers to fill. The simplest example is one-bucket kanban: if you have a sequence of steps where each step requires one item from its predecessor, then this is the situation where each step keeps one piece of inventory on hand. That way, if a request comes in from its successor, it will be able to quickly build what is required. (While, at the same time, putting in a similar request to its predecessor, to make sure its one feeding bucket remains full.)

This works great if all steps take the same time, but sometimes different steps take diferent times. In those situations, you can add buckets as necessary. Or, I suppose, remove buckets – for example, when buying books, Amazon normally ships books to me a little faster than I want to buy them, so while I normally use one bucket, I don’t always worry about keeping the bucket full.

If we wanted to adapt this to the TOC concerns, then, I suppose they might recommend that your bottleneck should have more buckets preceding it than would otherwise be strictly necessary to fill that step’s demands: you’re trading off excess inventory before the bottleneck for the risk of having your bottleneck not working at full capacity if something goes wrong. Given TOC’s focus on bottlenecks, that seems like a reasonable tradeoff.

I’m not sure that lean would agree, though – they would probably see this as a failure, and focus instead on improving the predictibility of the bottleneck’s predecessors. Given the apparent effectiveness of lean’s tools for improving predictibility of manufacturing, that sounds like a reasonable response to me. Non-lean shops might want to focus more on the bottleneck’s buffer, though. (Don’t get me wrong, buffers in TOC situations are much letter than buffers that other methods find acceptable.) Also, lean covers more than just manufacturing; maybe it takes more of a TOC-style approach in, say, product development? Honestly, I have no idea.

So: what does this mean about my situation at work? Again, I have no idea: I’m having a hard time finding the sequence of steps that will enable me to even ask the question of what the bottleneck is. For now, probably the best thing is for me to watch and figure out where something inventory-like is piling up, because it will naturally appear before bottlenecks. If the bottleneck is under my control, though, then probably the right thing to do isn’t to focus on the chains leading up to the bottleneck, though: the right thing to do is instead to eliminate the bottleneck by, say, increasing the number of people who can work on that area of code. (If it is an area of code.) So lean over TOC for me.

Kanban calculations have started to appear. For example, one of the questions that my team had been recently asking in its previous incarnation is how large a task backlog we needed from my boss. We’d been doing a monthly planning cycle with my boss, combined with internal weekly planning cycles; it’s not clear that’s a great mix, though. If we really only had a month of cards then, at the end of the month, we’d be mostly done with them, and might be unnecessarily idle because we wouldn’t have quite have enough to work on. So, at any given time, it’s useful to have, say, an extra week of backup cards built up. There’s also a problem at the start of a month: we have a whole month of backlog then, and that can actually be a bit much – sometimes, for example, we had a hard time accurately predicting how long it would take for us to do a card a few weeks off, because we needed to get our hands dirty with the preparatory work first.

So the lesson seemed to be that two or three weeks was about the right size for our kanban bucket: that’s best for production leveling, keeping us working at our maximum productive pace. And, actually, I suspect that that size is actually a bit too large – we need a bit of a buffer in case we’re more productive than expected over the course of a week, but lean suggests that you don’t want buffer for the purpose of making sure that people can’t still work on something if, for whatever reason, they’re not suitable for working on tasks that would otherwise be higher priority. You should instead see the latter as a bug, figure out its root cause, and try to eliminate it.

Lots and lots of stuff for me to learn. Lean concepts are starting to fit together for me, but I’m also becoming increasingly aware of just how little I really understand lean. And how little I really understand several other things…