I’ve done many different jobs in my life. I’ve done work on a farm (where I grew up), semi-skilled work in manufacturing, bartending, legal secretary, call centre operator, hotel receptionist, linguist, software tester and iteration manager. One of the less enjoyable jobs I’ve had was working in a factory which made cardboard boxes. I took it to make some quick cash one summer. I was mostly working on the production line but occasionally would get rotated on to internal transport where you got to drive an electric trolley around. That part was quite fun.
There is nothing much to like about working on a production line. The people who work on them are under no illusions about it. But it is an honest job and somebody has to do it (until the robots take over anyway).
Years after that summer of stacking boxes, I got my first job in IT. IT might as well be on a completely different planet from production line work. It is high status, high tech, intellectually demanding and creative work with a high degree of personal autonomy that is conducted in temperature controlled environments. On each of these dimensions it is diametrically opposed to the production line which requires minimal intellect, no creativity and, most challengingly, no personal autonomy. On the production line, you are a cog in the machine. Plain and simple. If the machine stops because of you, somebody comes over to find out why. Time is money.
Beacuse of this extreme juxtaposition of the two industries, I was very surprised when kanban came onto the IT scene. A methodology taken from production lines designed to optimise inventory management. How could that be relevant to the way we work in IT? In IT we build complex systems. The challenges we face in building those complex systems don’t bear much resemblance to what I remembered about working on the production line. The use of kanban seemed to me a category error.
It’s true that IT work can be modelled as a series of interrelated activities and represented by cards on a wall. So can all other work. That is why you now see kanban boards in HR departments and home kitchens and men’s sheds.
Because there is some truth in the analogy, you can’t say that it’s “wrong” to apply kanban to IT. But you can say that it’s invalid.
A useful way to demonstrate a category error is to examine the assumptions underlying the analogy. This is easy enough to do in this case because the claims that are made about kanban are well known. They are broadly as follows:-
- Reduce waste
- Improve worker utilisation
- Increase flow
- Maximise value
- Improve communication
Let’s examine each of these in turn:-
On the production line, time is money. Save time, save money.
IT, on the other hand, involves creative work. In creative work you cannot know in advance how long something will take. Sometimes you get lucky and find a solution quickly. Sometimes not. There’s also feedback loops of various kinds. What seems the right solution in the short term turns out to be the wrong solution long term. New information often comes to light that changes your original assumptions. What seemed like a perfectly good idea before is not such a good idea any more. There’s often no way to know in advance what will turn out to be “waste”. You can’t reduce waste if you can’t identify it.
Improve Worker Utilisation
Solving complex problems is not a linear exercise. It requires creativity. Creativity is correlated with procrostination, trial and error and sometimes “doing nothing”. The subconscious mind is often the driver of creative thinking and it needs the conscious mind to shut up while it does its thing. This is why the solutions to complex problems often pop into your head while you were doing someting else. The classic example is Archimedes having a bath. How to structure our work to recognise and encourage the role of creativity is a whole other debate. One thing’s for sure, keeping people busy (aka worker utilisation) is not conducive to creative thinking.
Kanban was originally concerned with the flow of widgets around a factory. When we talk about flow in IT, it’s the feeling of getting real traction on a problem and delivering the solution efficiently. This kind of flow entails both having the solution to the user’s needs and having the right overall technical framework to deliver it. This usually only happens later in a project when things have settled down after the early uncertainty exploring the problem space. Flow is not something you could or should have all the time throughout an IT project. Sometimes it’s better to be trying things out to see what works. Sometimes you take a wrong turn and have to back track. And sometimes you never get into the flow even though you do grind out a suitable outcome. That’s the way it is with creative work.
Value on a production line is simple thing. The widget you are manufacturing has been around for a long time. There is an established market and consumer base. The bugs have been mostly ironed out. The price is stable. People know what your widget does and what it’s worth. That’s as true of a cardboard box as it is of a new car.
In IT, many projects deliver no value at all because they are highly speculative. The business model is not established. The user base hasn’t been found. You still don’t really know what the product is. It’s also possible to deliver negative value. A product so poorly built that the users would rather not use it (but they have to because somebody at work signed a contract). And there are some products in IT that, even though a lot of people value them, don’t make money.
Defining and measuring (and maximsing) value is very hard to do in IT work. That uncertainty is as much on the business side as on the technical.
On one of the projects I have worked on that used kanban, the product manager asked if we could “set a theme for the week” of work. The reason for this was because it wasn’t possible to look at the board and see a unified goal in the work being done. New cards came and went. Priorities seemed to change from one day to the next. The product owner didn’t feel like they had an adequate grasp on when groups of features would be available. Rather than improving communication in that case, kanban had reduced it.
I was fortunate that my first job in IT was in a company that was striving to do XP software development. What surprised and impressed me the most was the focus on intelligence, creativity and learning. There was the underlying assumption that, in the end, doing things right worked out quicker than doing things fast.
The “business” of IT has traditionally had a different set of priorities. There is the desire for more certainty, predictability and consistency. The production line is still the gold standard for this. I think that is why the introduction of kanban has been driven by the business of IT and not by the engineers.
This tension between the business and the engineers might simply be a perennial feature of IT. It might be that the best we can do is to separate the priorities of the business and the engineering teams in the way prescribed by Scrum. I’d much rather see an attempt at making the business agile. Having everybody aligned around an understanding that the work we do is fundamentally complex and creative. That the search for the business model requires just as much creativity as the search for the technical solution. But kanban is not a step in that direction.