Lucy in the Chocolate Factory

This little gem explains why push systems are a bad idea:

What do you think happens when an organization based on push systems tries to go agile without changing the rest of the organization?

The Trap Has Been Reset

In my previous post I wrote about improving systems vs. improving processes. Yesterday, I went back to the book café in my little anecdote, and found that someone had moved the tables back to their original position. The insidious lamp trap has been reset for the next customer.

As I pointed out, improving systems instead of just processes is worthwhile, but hard to do. It does take a lot of effort, usually over an extended period of time.

Maybe I'll move the tables back under the lamps again this afternoon.

Process vs. System Improvement

A couple of days ago I sat in my favorite book café and worked on a Current Reality Tree. Opposite from where I was sitting, a couple with a small child sat down. The man sat at the right table. The woman sat at the left table. (Right and left are from the position of the viewer, i.e me, throughout this article.) After a few minutes, the man rose up, tried to go between the tables, and hit his head on a lamp hanging from the ceiling.

The figure above shows the tables where the couple was sitting. If you look closely at the picture, you won't be surprised that a couple of minutes later, when the man rose up again, he hit his head, just like he did before. The lamps are not centered over the tables, so rising up to the left of either table is likely to result in a bump on the head.

The third time the man rose up, he instigated a process change. Instead of trying to go between the two tables, he went to the right of his table. This time, he didn't hit his head.

Most people would be satisfied with this. Indeed, we do such process changes all the time, little accommodations to work around the imperfections in the systems we are part of.

However, changing just the process left the couple with unsolved problems. One problem is that if there is a small process variation, for example, if the man forgets to move to the right when he rises, he is likely to bump his head again. Another problem is that the woman might bump her head too. As you can see in the picture, the lamp above her table was also off center.

At this time I pointed out the problem with the off center lamps to the couple, and suggested that they should move the tables a little bit to the left. The man grinned (a bit sheepishly) at me, and moved his table, but not the other one. Nor did the woman.

This is very interesting behavior. The man recognized a possible systems improvement when it was pointed out to him, and moved the table. Both he and his partner failed to apply the same solution to the table standing next to it. This is a failure to generalize a solution. They could see the problem with the rightmost table, yet did not recognize that there was an identical problem with the table to the left.

Eventually the couple left, without either one getting bumped on the head. The woman, though she did not implement the systems improvement, i.e. moving the table, did rise carefully, so as not to bump into the lamp above her table.

When they had left, I moved the leftmost table, like this:
In general, we are much better at adapting processes than we are at improving systems. On the other hand, improving systems tends to yield much better results. In this case, all customers sitting down at either of the two tables will enjoy a head-bump free stay at the café. Maybe the café will attract a little bit more business as a result. Customers receiving head-bumps might be less likely to return.

To me, the story illustrates one of the core properties shared by TOC and Lean. Both aim at improving systems. That is why they are so effective. It is also one of the reasons why they are so hard to implement.

Review: Throughput Accounting vs. Throughput Accounting

Been to busy to blog again, but I have been reading. For some time now, I have been studying whatever material I can lay my hands on about Throughput Accounting (TA). TA is a management accounting system that is based on the Theory Of Constraints (TOC).

Who needs another accounting model? Just about everyone, it turns out, because the standard model, GAAP Accounting (Cost Accounting), is so fraught with problems it is positively dangerous. Though GAAP accounting works sometimes, it does not always come up with the right answers. TA is a more reliable alternative.

This review covers not one, but two TA books, the recently published Throughput Accounting by Stephen Bragg, and Thomas Corbett's Throughput Accounting, from 1999. (Yes, they have the same title.)

In the book Throughput Accounting: A Guide to Constraint Management, Stephen Bragg explains how TA works, and he does it very well. The focus is on accounting for manufacturing companies. Thus, some of the specifics are not directly applicable to the software industry. However, all the principles are.

The book discusses not only the basics of TA, but also how to use TA for performance measurement and reporting. Bragg also discusses the differences between TA and GAAP Accounting financial statements, and how to construct an accounting system that uses TA for reporting to management, and GAAP Accounting for external reports.

If there is one weakness in the book, it is that Bragg asks the reader to just accept the TA view of a company. He does not prove GAAP Accounting wrong, at least not from the start.
For me, this was not a problem. I have read up on TA before, and have used it in my work when doing financial analysis, and when I have modeled project value streams. For a reader with a background in GAAP Accounting, it might be harder to make the switch to the TA system.

Nevertheless, this is my favorite TA book, though I would advice anyone without previous TOC or TA experience to also read Throughput Accounting, by Thomas Corbett. Corbett spends a lot more energy describing what is wrong with standard GAAP Accounting before offering TA as an alternative.

Corbett's book does not cover quite the range that Bragg's book does, so I'm glad I have read both. Even if you have read one, the other will contribute something of value. When working through the examples in Corbett's book, I found one minor error, but as the end result was correct, I believe it is a typo, not an error in the calculations.

Both books are worth longer reviews, but as both are fairly short, there is an alternative to reading a comprehensive review: read the books!