I recently ran into a concrete example on waiting that showed me, again, why it’s bad. And how easy the alternative is.
At one of our facilities the cleaning has long been neglected. It was super-dirty in places and you could see that no one had clean here for months, maybe even years. A rescue operation was put into place and in just 5 days the facility was cleaned. About 15 people was engaged in the effort.
That’s really awesome because not only is the cleaning done, but the next time we clean it will not take as much time.
In this post I wanted to share some thoughts on how this is general and what we can do to avoid this situation.
To explain what just happened to the people in the room I drew this diagram on the whiteboard:
We talked for awhile and they seem to understand. Heads where nodding and people went “aaaaah”.
(Yeah, that’s how I measure success in delivering messages. Not really the best way I can tell you… Find better for yourselves.)
The item on the agenda was about finance reporting. We wanted to have the cash reported daily. It turned out that this was hard for them. We asked Why, of course and they said that they had not reported like this before.
That’s when I saw the analogy between these two tasks. I went up to the whiteboard and changed the table into this.
Maybe the numbers should be adjusted a bit but, the principle holds. The longer the wait the longer the task will get.
The work will actually increase just by us waiting and doing nothing.
Summing up
If you’re into agile and lean this is of course not new, in fact you could say that it’s common sense to, but in fact the longer you wait the more work you create. Waiting creates extra work, if you like that better.
The good news is that we are in control of this fact, we decide how often we do the cleaning, reporting, refactoring or whatever.
- Do the cleaning once a month – clean a long time at that occasion.
- Do the reporting once a day – spend 30 seconds doing it
- Refactor you code in the end of the sprint – spend 2-3 days doing it and also stand the risk of introducing new bugs.
- [your example here, or in the comments]
It can of course be stupid too… maybe. Why not clean every minute then? It will only take 10 seconds? Well, there’s a balance here, if you do to much micro-activities they add up taking too much time. This has to do with, what in economics is known as, coordination costs.
In order to clean, I need to get the cleaning gear out, get the warning sign out and then put it all back after the cleaning, and wash my hands afterwards. This is what I need to coordinate in order to do the work, and get reset for next task.
If I already to was ready to clean, because I always had the gear ready and always had gloves then I could just clean and just the actual cleaning time would be used for cleaning. This is known as transaction costs since it’s the time for each cleaning transaction.
If the task is super small we might think about see if we can bunch it together until is worth doing taking the coordination costs into consideration.
Stupid question
“Forgive me, if I ask a stupid question, but how do I know what a suitable size is for my specific task X, Mr. post writer, sir?”
First of all – there are no stupid questions. Secondly about you’re not knowing what the suitable size is; you don’t. Neither do I.
In general, I would recommend you to do smaller, faster tasks more often than big, slower task more seldom. Waiting for the bigger tasks creates more work in itself. The task grows bigger as you wait, in other words.
Try something and then evaluated it and see if you thought that was a good idea. Like an experiment. Yeah, let’s call it an experiment. Do not run the experiment for a very long period of time, because the longer you wait and the bigger the task the more work is created and then … [go back to top of blog post].