We often think that we waste our time because of small things. Like getting a coffee or having a bigger lunch. But the reality is that the work we do is filled with time wasters that cost us more time than any break that we take.
If we are not able to identify and mitigate them, we are doomed to never get rid of them.
The initial 7 lean waste came from the Toyota Production System, and were applied to lean manufacturing. In a sentence, to factories. But over the years it has evolved. It evolved in a way that we were able to map them to our industry of software development.
This is a summary of the 7 lean wastes.
#1 Task-Switching
We waste time when task or context switching because of something called the psychological refractory period.
Without entering into much science, it means that whenever we need to stop what we are doing and move to something else, our brain needs to adapt. That adaptation is not free, it takes processing power and that in the end is time. It can cost you up to 40% when task-switching.
And if you are thinking. NO, I can multitask without wasting time. Then, my friend, you are a lucky one and part of a very exclusive group. Only 2% of the population is good at that, so, congrats.
#2 Partially Done Work
Yesterday I was having a chat with one of my teammates and he mentioned the analogy I used for this one. I think it is the best way to explain partially done work.
One person is peeling an apple with a knife, and another person is peeling a potato with a potato peeler. Who is the fastest?
You may say the potato person is the faster right? He/she has the right tool. And we all know that if we use the right tool for the job we become more productive.
But the devil is in the details. The outcome in both cases is very different. One gives you an edible product that you can use right away, the other will still need extra steps to be completed, like seasoning and cooking. Unless you like raw potatoes, then this is completely different.
If you think about it, when you leave partially done work on the table, you are also task switching. One waste feeds into the other.
#3 Delays
Why do we leave partially done work on the table? Most of the time, not all of the time, but most of the time this is due to delays. If you need to start tackling any waste, I would suggest going for this one first. Why? Because it bleeds into two of the other lean wastes.
Delays cause work to be unfinished (partially done work), so we need to move our focus to something else (task-switching). This is why communication is important, proper planning so that we don’t get held up with delays.
Plans are nothing; planning is everything.
Dwight D. Eisenhower
As President Eisenhower said, planning is important, but don’t get held up on the plan either. We need to malleable. We need to have the agility to adapt to what comes ahead.
If you want to fix one and only one of the lean wastes, as I said before, try and fix this one.
4# Hand-Offs
I love this quote.
Code is like a good joke, if you have to explain it, you are doing it wrong.
Ok, I understand it is not as simple as that, but it makes a point. If your code does not speak for itself, then we need to do a hand-off, right? And hand-offs take time. They need to be documented (extra work). Meetings need to be setup (task-switching).
Another quote that I love is:
The best communication is no communication
If what you have is so clear that you don’t need to explain it, then there is no need to hand-off. We can save time by making everything visible that can be visible.
And remember, hand-offs only work, because we assume no information will be lost during the hand-off. If you ask me, this is a real risk assumption.
#5 Extra Work
If you do waterfall software development, there is a high chance you are doing extra work. Why? In one word, Feedback loop.
Extra work occurs when you don’t know that you did everything that needed to be done. As simple as that.
80% of the value comes from 20% of the features
We all know this. Just look at the options bar on Microsoft Word. How many of those features do you use? Now think about how many other pieces of software you have that contain features that you never use. If most people don’t use it, why did we spend time building it?
Well, the answer is simple. Delays in the feedback loop. We kept on doing things without asking “If we deliver now, do you have everything you need? Or do you want to spend more of your money developing these extra things?”
#6 Defects
Oh, the dreaded defects. Bugs. Incidents. Status pages and on-call support.
One thing we can all agree on, and if we cannot, we should, is that bugs are part of any software. So why are they a problem? Simple, they cost time to fix. Not just the time to fix, but also the time they were in production messing something else without being found.
We can never get rid of all the bugs, but that doesn’t mean we should not try and mitigate them. There are several ways we can do this.
We need to have automated testing and continuous delivery to prevent errors that we already know. We should have on-call support, triage phase, and an internal service desk to deal with new bugs that escape our process.
Just because we cannot live without them, doesn’t mean we need to accept them. Especially if we have already dealt with them. Which segways right into the last lean waste.
#7 Relearning
Nothing is more frustrating than having to learn what you already learned before. Imagine that today you completely forget the ABC and have to learn it all over again. How long do you think it will take you?
In reality, it doesn’t matter how long, it is already a waste. Why did you forget it in the first place? This is the real question that causes re-learning.
How much did civilization lose, when the great library of Alexandria burned to the ground?
Usually, there are deeper underlying causes than just forgetting. For example, hand-offs. There is a high chance something will be lost in translation. Information lost is information that needs to be gathered again, meaning, re-learned.
Those who do not learn history are doomed to repeat it
The agile manifesto puts a good emphasis on “working software over comprehensive documentation” and I couldn’t agree more. Pay close attention, it says over, not instead. Proper documentation will save you time if you ever have to re-learn something.
Cheers,
