blog podcast

Thoughts on Lean and IT

To my distress after leaving school I have time and again been faced with the fact that although school rewards you with praise and good notes when you manage to regurgitate given sets of truths, the real world seldom hands you precise definitions or clear cut choices. Instead we see terms appearing that get re-interpreted over and over again and finally you reach polarization. Not because necessarily people disagree on the core ideas, but because people no longer agree on what core ideas actually underlie a specific term.

I was then surprised when I scrolled through my LinkedIn feed (I know, it’s usually at your own peril) and found a post on how Lean does not apply to software because software is not mass production.

I have no ego concerning Lean. I can take no credit for inventing the ideas, and neither have I thought long and hard enough on the topic to want to say we’ve finally found the concept to solve everything. I did find the thoughts very insightful though when I read “This is Lean” earlier this year. I also found them useful and I found them containing solutions to everyday problems I have seen throughout my career. Seeing this dismissal of the idea made me want to think. And I thought.

First of. Some of you might have encountered Kanban, and this is usually the word that would get associated with Lean. The idea is that you construct a flow for something to be implemented. Let’s take a fictional IT company and you might have a flow consisting of:

These are all steps (give or take) you probably want to perform from having an idea pop up to having it available to your customers. The idea of Kanban is that you define this flow and you then limit the amount of work items that are allowed in any specific state. You then tell the developers: “You are not allowed to have a higher WIP than the number I have said for this column”. If there is a higher number it should be investigated why that is happening, and then we should try to tweak our process so that we don’t have to encounter this kind of situation in the future.

This what is written above is what I have experienced at workplaces. And this is not a judgement. I’m not saying it is good or bad. That is how the rules have been defined.

What I think is good regarding this is the focus on wanting to have good “flow” (ie. the speed for this feature to go from idea to being released should be good) as opposed to high resource utilization (ie. the important thing is that all developers are doing “something” that they are good at all the time).

What I think is missed with this model is: I think most developers don’t respect the WIP limit. Obviously if you are blocked you are not just going to sit on your chair and wait, you start working on something else instead. I also don’t think most people actually evaluates why the WIP was breached, so the actual processes are not changing. This is one central point. The reasoning behind Kanban is that you want to investigate why something is slowing down and solve the reason by improving your process. If you are not tweaking your process you’re missing the point. I think with Kanban as with Lean as with Scrum. People very often miss the point.

Everyone loves Bruce Lee. Or they should. And he said “The best technique is no technique”. I subscribe to this idea. But it doesn’t mean that one should just do whatever and everything becomes great. My experience in many workplaces has been that few people reflect on ways of working. I think it is a great loss to not consider that failures and problems that arise are not sufficiently explained by pointing to individual mistakes (that you then not highlight because you don’t want to put the individual in a difficult spot) but rather they should be explained by the underlying processes and systems that allowed (or perhaps even encouraged) this mistake from happening. At the same time you don’t want to tie people so hard to systems and processes (technique) that they are unable to tackle the problems in front of them in an efficient way.

What you want is a framework of values that you are able to align everyone with. With these values and these understandings people are able to interpret the problems in front of them in a satisfactory way to handle them in a way that adds value not only to your department but to your company as a whole.

Lean is based on a couple of insights:

Software might or might not be a question of mass production (I honestly haven’t made up my mind). It does stand to gain from incorporating Lean values.