We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head).
The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.
Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions
- Why does it impact our work?
- What could be the causes of this?
- How can we measure it?
- How can we avoid it?
For today the focus is Partially Done work. Some say this is self-explanatory, but I believe it is a bit more complex. Let me ask you this question?
One person is peeling an apple with a knife, and another person is peeling a potato with a potato peeler. Who is the fastest?
If your end goal is to just peel something, the potato will win. But if your objective is to get it ready for someone to eat, then who is going to want a raw potato? In this case, the apple peeler, although it looks slower, the moment it finishes, it is ready.
If the potato peeler does not cook the potato, the work is partially done.
When we waste time with partially done items, it doesn’t necessarily mean that they are almost done like in the potato case. What it really means is that the work on the item has started but was never completed. Somewhere along the way we stopped and put it on the side.
Why does it impact our work?
- First of all, because we spend time on it.
- If it is never done/delivered, we cannot access the value proposition of that piece of work.
- Task switching, partially done work is something we were doing and had to put aside before finishing, to do something else.
- It may linger in our backlog forever and become obsolete.
What could be the causes of this?
- Wrong prioritization of work
- Bad project management
- Work not being broken down into small enough pieces
How can we measure it?
- Check for items flagged/blocked on any stages of the process.
- Items that were pulled back for work and then pushed back to the backlog
- More than 1 item picked up by the same person. Parallelism of work doesn’t exist.
- Untested or not merged code that we are not working on.
If we don’t measure it, we cannot inspect it. If we cannot inspect, how can we adapt?
How can we avoid it?
- Finish what you started. Don’t start what you can’t finish.
- If you have a daily, focus on moving the tickets to the DONE state more than moving work into progress.
- Limit the amount of work in progress in your process.
- Have something similar to a DoR that prevents work from starting without the proper information.
If you have read this far, you deserve it. Here is a Halloween pumpkin.