I Didn’t See That Waste

“If it was a snake, it would have bitten me.” – common US Idiom.

We have invisible waste in all of our software shops. It’s not so much that the waste cannot be seen, but rather that it is habitually overlooked.

When we’re in the midst of a time-consuming, low-value task we tend to just “gut it through” and move on. After all, it’s only 10 or 15 minutes, and I’m not working with a team, so it’s just my time. It’s not holding up the rest of the team. Soon it is done and forgotten.

We might notice the really big issues, but the “normal” daily waste we just take in stride.

While the resilience and diligence of a team is appreciated in the small, tolerance for waste can be staggeringly expensive.

It’s easy to justify spending 15 minutes on a dull task rather than spend an hour or two eliminating the task.

Be very careful what you choose to call "normal."

If 8 team members each spend 15 minutes at a time, twice a week, doing something that could be automated or eliminated, that’s 4 hours of productivity down the drain for the week. That’s on the order of 200 hours a year. Eliminating that waste could saves us weeks of effort every year.

Would you spend an hour or two to save 5 weeks of development time every year? Of course you would! Would you spend an hour or two to save 15 minutes of dull work? Of course not.

When we don’t recognize and consider how many times a thing is done and by how many people, we become focused on the near term and not the overall waste. This kind of thinking keeps us wasting months of time every year.

How Does A Waste Snake Work?

Some years ago Martine Devos taught me about the Waste Snake, which I believe is her invention.

It’s a simple formality:

• When you are doing tedious low-value work, or waiting idly you write up a sticky note about it.
• You select a central place (we used to use a bulletin board in pre-covid, but Miro/Mural will work now) to post the card so others can see it.
• Periodically (daily?) you look at the board and see what low-value or no-value tasks have been occupying your time (or the team’s time).
• When you decide enough is enough, you allocate time to fixing the problem - reducing or eliminating the waste and waits.

There are nearly always so many wastes in a normal week that if you posted them side-by-side, you would quickly run out of wall space.

Martine suggested that when you reach the end of the bulletin board or mural space, you start wrapping around and going back the other direction. This forms a big, long S shape that may fold back on itself several times.

People often playfully add a drawing or cutout of an actual snake head and tail to the ends of the waste snake.

Example from: JGodsell showing a well-populated waste snake:

A Quick Story

Some years ago I asked the team I was coaching about their pain points. They said that there was a random, intermittent problem with version control. At some point in the day, it would simply be unavailable. They had to wait for it to come back up, and nobody knew how long that would take.

They had been tolerating it, sometimes by creating temporary branches, stashing changes, or finding non-dev work to do until it was available.

I suggested Martine’s Waste Snake technique, and (being pre-COVID days) we cleared some wall space and put sticky notes and pens on a table near the space.

We decided to record the time of day and the duration of the outage on the cards.

The next day version control was unavailable around 9:30am. It was down for about a half-hour and was available for the rest of the day.

The next day it went down again. Same time. Same duration.

The third day? It was at the same time, for the same duration.

Perhaps the outage wasn’t intermittent at all!

The time of the morning when people noticed it was intermittent, though. Sometimes they were in a meeting or doing some research and didn’t notice at all. Sometimes they noticed when it first happened, sometimes at the end of the half-hour.

On investigation, we learned that the server hosting our version control system was in India, where the time zone is about 9.5 hours ahead of ours.

9.5 hours? Our system was unavailable at 9:30 am?

Are they doing backups at midnight their time?

Yes. Indeed, they were. They wanted to do back up the system when there wasn’t any load (in India) on the servers, and nobody is programming at midnight. It was a very reasonable choice if one forgot the global span of the business.

They agreed to schedule backups 2 hours earlier, which worked for them and for us.

We never had that type of downtime again.

What Counts as Waste?

Often when we establish a waste snake, there is a question about what to report.

Do you report waiting on PRs?

Do you report doing code reviews?

Do you report meetings?

Do you report debugging or is that normal development?

Is looking up answers on the internet waste? What about coffee breaks?

The answer can vary, of course.

Technically, in lean, time spent that isn’t directly adding value to a product is waste.

Example from Ammeon, now renamed Intive, which they present with a listing of waste categories (“Lean Wastes”) on the side:

There are many articles and posters available to help people understand what constitutes waste. It would also be good for more people to read what Mary and Tom wrote about Lean Software Development.

There are degrees of waste. Some waste is necessary and some is not. Some occur while adding value to a product, others prevent value-added work.

There is pure waste like the downtime caused by inconvenient backup scheduling, and there is necessary waste such as coordinating with others and developing skills and knowledge. What makes necessary waste necessary is that it sustains or improves the organization’s ability to add value to their products. Testing and refactoring aren’t “value adding” but are “necessary”.

There are wastes involved while adding value, such as wrestling with crufty code or insufficient editing tools.

Ignorance is one such item - if you are using old and clunky techniques rather than using convenient new language features or libraries you are likely spending much more time writing code than you technically have to spend.

One can feel productive (“I wrote a lot of code today!”) without being productive (“but that could have been three lines if you knew your stack better!”).

So what do we put on the waste snake?

We can’t expect people to report the wastes that they don’t see or feel. If people were to list the moments when they were frustrated, bored, or delayed then there would be plenty of material for the waste snake.

What interrupts, bores, or frustrates us?

We can list the wastes we see and feel, and worry later on about solving them once we see which items are most common and most disruptive.

Example from: David Denham with motto and team name:

The job of the waste snake is not to solve the problem but to make us aware of the wastes all around us.

There is an extra benefit, though: once we start to notice the waste all around us, we develop our sense of waste and begin to see many more ways to improve our way of working.

The secret to success seems to be

Use this month
to make next month
better than last month

“Better,” of course, is locally defined, but I like to think of it as achieving more with less effort, less stress, and less risk.

Use your waste snake to make your job easier and your product community happier.

Related Discussion:

We had an open discussion through our Industrial Logic TwitterSpace. Here is the recording of that conversation.