Showing posts from 2007

Back in Time

Argh, I'm still busy. I write this at 02.23 A.M. I have just finished working for the day. I upgraded my Mac OS to 10.5 (Leopard) recently. I had several reasons for doing this (being a geek is one), but there were two in particular that might be of interest: I wanted a better backup system than the one I have used previously. Leopard comes with the much touted Time Machine. I have done a lot of work on how the choice of requirements analysis methodology affects the final product lately. This has revived my interest in an interaction design methodology, Goal-Directed Design. I don't know if Time Machine was designed using GDD, but it was certainly designed using a very similar philosophy. Time Machine is extremely simple to use. The only thing you need to do to get going is to plug in an external hard drive (I use a 160GB Iomega dedicated to backups only) and start the program. Time machine backs up the internal hard drive. From then on, it makes hourly backups. Time Machine i


In case you were wondering, I haven't gotten tired of blogging. I have been working, a lot. I am working on some stuff that will appear in the blog, but my family and my work takes precedence, so it is going forward very slowly.

The Kanban Juice War

I posed what I believed to be an innocuous problem for the kanbandev group at Yahoo and inadvertently started a bit of a row. The problem was as follows: In a hotel restaurant there is a table with a juice dispenser. Next to the juice dispenser is a stack of trays with glasses. Sometimes the glasses run out, and a queue of customers build up. What is the best way to prevent glass outages? I had a solution, but I wasn't happy with it. It involved using a photocell to detect when the glasses were in danger of running out. One complication was that the serving personnel could not easily see if the glasses were running out. The table with the juice dispenser is in an alcove. The, usually very busy, serving personnel move along paths that make it difficult to see the trays. If there is a queue of people waiting for juice, they obscure the trays, and any simple kanban mechanisms. Of course, if the arrival rate of thirsty restaurant guests is great enough, a queue may form even if there i

A Visit to BNI

A little over a week ago, I visited BNI Spar Hotell in Gårda, Gothenburg. I was invited as a guest by Martin Richards . Last Thursday, I visited again. BNI, Business Network International , is an international business referal organization. The idea is simple. A BNI group consists of a number of representatives for various companies. To avoid internal competition, only one company from each trade is allowed. The members have a breakfast meeting once a week, where they exchange business referals. The members also carry each others business cards, and look out for opportunities to help each other. At my first visit, I was impressed by the well structured and tightly focused meeting. Of course, from my Theory Of Constraints perspective, Throughput is the game, and the group does deliver. I won't mention any figures here, but on average the membership is well worth the cost. I do not know how the Throughput is distributed over the group members, but everyone I met was very happy with

Chain Theory Webcast

I have begun experimenting with webcasts. This is the first result:

Kevin on Blame

Kevin Rutherford made a few comments on my posting on risk aversity . He also posted a link to a posting of his where he is writing about several articles on related topics, including mine. Kevin's posting is well worth reading, and so are the articles he references.

Risk Aversity

If you happen to be a CEO, have you noticed a certain sluggishness in your department managers? A reluctance to take decisive action. Perhaps not. The problem is pervasive, but it is more noticeable from the bottom of the organization than it is from the top. The reason is that even though problem causes can often be found high up, the effects are usually felt further down. Most organizations have a built in resistance to take action. It is generally safer for a person, especially for managers, to take no action at all. The illustration below shows how it works: The Current Reality Tree (CRT) shows that there are two root causes contributing to exaggerated risk aversity: Detected mistakes are punished Decisions resulting in no action are not recorded Because of this, it is a much safer strategy for an individual to take no action, than to take action, when faced with a problem. This discourages managers from taking action. Employees at the lower levels of the corporate hierarchy hesita is Back in Business

I have just relaunched . The site has been rewritten from the ground up. Right now, the material you'll find there is mostly about my TOC consulting business. Over time I will add material on TOC, Lean, and agile. In addition to the address, the Kallokain blog can also be reached at . Please allow up to 48 hours (that would be on Sunday), to allow the address information to propagate over the Internet. (Depending on where you are, the address will work right now. Try it! )

It's a Policy Constraint!

There was some interest in my process improvement story . Both Tobias Fors and Torbjörn Kalin have commented . I talked to the manager at the café. She had noted the head-bang problem long ago, and wanted to fix it by replacing the low hanging lamps. Upper management won't let her. The lamps match other lamps in the bookstore. A possible solution would be to shorten the power cords.

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 b

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 dir

By The Book 3: Throughput Accounting

This is the third part in a series on management accounting for software development. The material is from a book I am working on. To make sense out of it, read part 1 and part 2 first. Let's look at the diagram modeling team A and B again: The developers in team A are already working at full capacity. Thus, they are the constraint of the process. Adding 8 hours of work for a developer, means adding 8 hours to the constraint. Adding 8 hours to the constraint is the same as adding 8 hours to the whole project . The cost is €175 times the number of developers and testers, plus an additional €200 (8 * 4,000 / 160 = 200) for the team leader. This works out to €1,425 (7 * 175 + 200 = 1,425) in increased project costs. In addition, there may be a considerable cost associated with delaying delivery. I'll leave that can of worms alone. (Read about it in Lean Software Development by Tom and Mary Poppendieck, or check out a blog posting by Gustaf Brandberg .) Team B has an easier tim

By The Book 2: The Way Of the Cost Accountant

Let's explore the problem in my previous post using Cost Accounting (CA). CA is the generally accepted management accounting method. It is used by companies all over the world, and it is the accounting method mandated by law in most countries (that I know of): CA makes the calculation like this: A developer has to work 8 hours to fix the defect. The developer makes €3,500 per 160 hour month. This would work out to €175 (8⋅3, 500 ÷ 160 = 175). However, CA allocates overhead costs from management, rent, electricity, and other things. These costs are shared by all workers. The overhead costs can be quite large. Let's be conservative and say they are €1,000 per developer and month. A developer’s total cost is now 4,500/month (3, 500 + 1, 000). Cost Accounting then gives us 8 ⋅ 4, 500 ÷ 160 = 225. That is, it would cost €225 to fix the defect. The cost is the same for teams A and B. Let's do a thought experiment. Have a look at the figure above. The teams spend working time in o

By The Book

I am actually getting somewhere with the book I am working on. Here is a small excerpt: Consider two project teams, A and B. Each team has one project manager, four developers and three testers. Each team member makes €3,500/month and works 160 hours/month. The project managers make €4,000/month. Both teams produce 80 Story Points worth of functionality in a week. In team A, the developers work very hard, but the testers have time to surf the Web now and then. In team B, it is the other way around. The testers are pressed to keep up, so the developers slow down a bit to avoid deluging them with more work than they can handle. On the same day, a defect is found in each project. Both defects will take eight hours for a developer to fix. What is the cost to team A? What is the cost to team B? Give it a try. I'll publish the solution in a couple of days. (Hint: the answer is slightly less obvious than it looks.)

Fixes That Fail

Many companies use a standard response in troubled times, they appoint a new CEO. The new CEO takes measures. If the CEO is a former sales person, he focuses on improving sales. If the CEO is a former accountant, there will be a savings program. A CEO with a technical background will focus on developing new products. The outcome is usually one of the following: The company takes a nosedive, crashes and burns. Nothing happens. The gradual decline continues. Eventually yet another CEO is appointed. There is improvement. Sometimes the improvement is radical. after awhile, the rate of improvement abates. Then the company begins to backslide. Eventually another CEO is appointed. There is a sustained improvement in the company's financial health. This is rare though. The third alternative, initial success followed by backsliding, is in many ways the most interesting outcome. First of all it is a common outcome. Second, it often seems inexplicable. The CEO proved his management genius

Truth, Damned Truth, and Statistics, Part 2

This is part 2 in a series of articles. You can read the first part if you click here . In the previous article in this series, I discussed how to measure and visualize the Throughput part of the Return On Investment (ROI) equation. This time I'll focus on Inventory (I). As you may recall, Inventory is defined as "money tied up in the system". Inventory includes all the equipment you use in a development project, computers, software, chairs, tables, etc. In a manufacturing process, Inventory would also include the partially finished material being worked on in the process itself, the Work-In-Progress, or WIP. In a software development process there is no WIP, but there is an analog: partially finished software. This includes requirements, design specifications, and any code that is not fully finished, tested, and ready for release. Partially finished software is sometimes called Design-In-Progress, or DIP. The DIP has a monetary value. The value of the DIP is the amount o

Five Things Managers (Usually) Don't Get About Agile

Clash 1: Goals Traditional development methods set three goals: Keep within budget Implement all requirements (often specified before the project starts) Make the deadline Agile projects set the following goal: Maximize the Return On Investment (ROI) To maximize the ROI, an agile project changes the following variables: Cost Scope Time In other words, what traditional software development, and most companies, set as fixed goals, are just the things an agile project need to change to reach its goal. Clash 2: Push vs. Pull Another major difference is that most companies, and traditional development methods, are based on push systems, while agile is based on pull systems. : In a push system , each step in a production line does what the previous step tells it to do. In a pull system , each step in a production line does what the following step has to do. The situation when orders start travelling from both ends of the command chain can at best be described as chaotic. Clash 3: Cost Effi is Down, but Kallokain is Up

As you may have noticed has been down for some time. The site went down because some of the software broke when the host system was upgraded. Before putting the system up again, I will fix some broken links and other problems. My schedule is rather full these days, mostly with the joys of fatherhood, but also with a major writing project, and a few other things, so getting the site going again will take some time. I will spend time blogging again though. The past few months have been incredibly hectic, but the past few weeks my life has settled down to a somewhat saner pace. Besides, my writing addiction is stronger than ever.

Truth, Damned Truth, and Statistics

Statistics may not be what floats your boat, but statistics can tell some important things about software development projects. In this article, I'll show how even a very simple analysis of some basic project measurements can be exceedingly useful. The data in the following analysis is fake, but the situations they describe are from real projects. A commercial software development project is a system that turns requirements into money. Therefore it makes sense to use economic measures, at least for a birds eye view of a project. If you have read my earlier postings, you will be familiar with the basic equation describing the state of a business system, the Return On Investment (ROI) equation: ROI = (T - OE) / I T = Throughput, the rate at which the project generates money. Because it is hard to put a monetary value on each unit of client valued functionality, this is commonly measured in Story Points, Function Points, or Feature Descriptions instead. I'll use Story Points, beca