Back when I studied, I worked part time in a local store. I was responsible for juice, soda, beer, wine, and other bottles of alcoholic drinks. I was responsible to order them, and to manage and refill remains over the week. Being a small shop, I also needed to be a jack of all traits. At times I had to have an eye on refilling vegetables, and fruits. At other times, I needed to refill milk, or answer inquiries from our cashiers. That said, there are some lessons I learned in that shop that helped me find my way once I joined my first job. Here are some nuggets from that time.

Customer-driven

In a local shop, over time, you know everyone. You know the customers that come regularly, of course you know all your colleagues, and over time, you find out who is still coming back to get their weekly shopping done, and who doesn’t. Over the course of the ten years that I worked in that shop, I learned a crucial lesson: your customer matters.

For example the customer matters when you work in the shop, are currently busy with refilling what was left from the last order, have five minutes until the end of your shift, and he approaches you with the question where he may find coal for his barbecue. If you tell him that you can’t answer that question because your shift will be over in five minutes, he is likely to walk out of the shop – and never come back.

For a long time, I thought that “the customer matters” means to do everything for your customer. That is not the case. It’s more that you should be honest, and seek to help him. If I didn’t have a clue about that other department that was in charge for the bbq coals, I still could find a colleague from that department, and refer the customer to her. If I was unable to find anyone with a clue, I could still say sorry to the customer – and make sure the problem in our shop gets addressed to the right person, so that it won’t reoccur again. If we were out of milk on a Saturday by noon, I could still inform our department lead about that problem, so he can have a chat with the responsible person.

So, the customer matters, but don’t lie to her or him.

When I started consulting a few years back, I had another terrible lesson to learn. In a local shop there is a sort of natural equilibrium between customer demand, and the persons working there. No one would put 100 employees in a shop that only had 20 customers during a day. That would be too much staff overhead – or the wrong location to run that shop to start with. In consulting the demand from your customers may rise higher than the amount of time you can actually throw in. That comes with particular stress, if you combine it with a total freedom of stuff that you can do. In short time you overburden yourself. I have felt into that trap, and from time to time I try to make experiments to stress the point whether this is really all I can do, or whether there is more. For example that kept me from writing more blog entries recently.

But I digress.

In a shop there is a limit to the amount of questions you will get on average over the course of the day. In consulting that is not necessarily the case. At that point you need to find a way to limit what you put on your shoulder, and learn to say “no” to some things that look shiny. The same holds for some larger product development companies as well. They start things all over the place, and keep on wondering why it’s so hard and expensive to get work done. The short answer is you have overburdened yourself. Start to really prioritize, and staff the projects that you really need to do. If you find yourself with a list of ten projects that don’t get staffed afterwards, then this is your inventory of projects that slows you down. You should think hard, how you could realize them. Maybe taking on more staff is a good thing for you, maybe saying “no” is the right thing. The only thing that will happen for sure, is that the other projects that you staffed will get stuff done – and usually a whole lot faster than before.

Inventory can overload you

I remember a time when I ordered vast amounts of stuff to fill the shelfs, for example there were breaks between Christmas and New Year’s where we didn’t receive any additional orders for some foods. At that point, I had to pre-plan, and order more. Or for father’s day in Germany, there is a habit to buy lots of beer, and wander with your friends through nature. One year, I had ordered four times the usual amount. Of course, all of that did not fit into the shelf. So, I put it back to inventory, and had to re-fill over the course of the week once customers bought out all of our beer.

For most of the time, I had four to five ‘rollies’ with stuff that didn’t fit on the shelf. In that week I had eight of them. That hurt me a lot later, because refilling also took a whole lot longer. I had to move double the amount of ‘rollies’ over the week, I had to re-arrange what was still remaining, and for the pieces where I had too positively ordered too much, I had to suffer for even longer than the one to two weeks around father’s day.

But I remember a particular time when our inventory in the lager kept on going up. That was really painful. It almost seemed we had dramatically slowed down with refilling from our inventory. It also felt crowded, and I felt work as pretty busy. It seemed everyone was busy ordering new stuff since they did not get to refill the inventory. So inventory went up even further, and slowed us even more down. Still, the customer was happy, but was the price for that happiness worth paying for? I never thought so.

Now, while inventory in a supermarket is pretty painful, because you can see it all day, how does this relate to software? In software, as Alistair Cockburn taught me, inventory can be thought of as unvalidated decisions laying around and waiting for the next person in sequence to take it, and build it further. For example, the classical requirements document that carries unvalidated decisions about requirements. Architecture and design decisions will be built as another layer of unvalidated decisions upon that. Finally, the first time these decisions will be validated is when the finished software faces the customer.

The problem with unvalidated decisions in software compared to a supermarket is that in a supermarket the inventory will really hurt you, because there is limited storage area, and you will have a lot of work moving all those inventory ‘rollies’. In software, I never managed to fill my hard-drive with unvalidated decisions. Even if I did, I would probably start spreading some of the decisions in the virtual cloud, online, or on DVDs, long before I ran out of disk space. That is why visual management with paper on wall has a dramatic effect in most companies: it hurts. And remember, all that is telling you, is that you have too much inventory going on. In the supermarket situation, we were only able to change the amount of our inventory with a large change in how we organized our work. And it took a lot of time to do so. That’s the case with most legacy code as well. The first few tests will not help you. It will take a lot of time to pay off for all the pain that you created earlier. Sorry, there is no free lunch.

Why do I remember these lessons?

While reading Larman and Vodde on Scaling Lean & Agile Development, I remembered these lessons, and could resonate well with queueing theory, systems thinking, and Lean management. I think it is time to take these lessons more seriously into practice. So, back at work, think about all the inventory that you have currently at work, and try to think about at least three ways to reduce it. Also keep in mind that there is always a deeper reason behind the problems you realize. Wonder what caused you to introduce that inventory in first place, and how to solve that. Oh, and really think more about your customer. I know, he’s probably far-far away in a land of fairy dust and unicorns, but a customer that disappointedly runs out of your workplace because you couldn’t help him, could infect other potential customers. Think about it.