Stop doing things that don’t make us faster, better, more focused
What if every day you made a 1% quality of life improvement to your team's way of working? After a year, you'd be performing at a multiple of 37X.
I have a certain no-nonsense sensibility about software development. It almost seems common sense, grounded in my second nature: eschew whatever seems like a diversion. Only do what is purely focused on writing fantastic code that actually works. Don’t put up with any distractions — if it’s not the shortest path to the right outcome, than don’t do it.
Maybe it takes years of writing code and managing teams to get it. Maybe it’s just that I don’t have patience for anything else.
But there are a lot of distractions — ad hoc meetings, poorly organized ceremonies, rework, and other demands. How do we defend our teams from this?
Awareness is key. Specifically, creating a laser-focused awareness about what is wasteful and what is valuable.
Years ago, I started doing an exercise with my own team to build that awareness. The goal was to figure out where our time was going — and stop doing things that didn’t make us faster, better, more focused. That exercise is a “waste walk.”
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
Anytime you'd like to read more, you can upgrade to a paid subscription.
Discover waste, prioritize value
A waste walk identifies activities that drain your team’s time, energy and resources. It focuses your effort on plugging those gaps and recovering the lost energy.
I’ve written about this before, but it was fairly abstract and high level. I thought it would be interesting to get concrete with a case study written from a recent exercise.
The goals of a waste walk are simple:
Discover what activities are sapping a team’s efficiency and focus.
Prioritize the worst offenders.
Figure out how to recapture that lost effort and time.
Do it without getting in the way of day-to-day activities.
Unlike a lot of “productivity exercises,” waste walks are team-driven and entirely concerned with making quality of life improvements for the team.
The waste walk doesn’t involve any outsiders, doesn’t introduce complicated and ineffective new methodologies, and doesn’t measure strange metrics to gauge productivity.
Instead, it’s an entirely team-driven exercise — by the team, and for the team. It’s a simple exercise wherein each member in the team buckets their activity in two categories: value add and non-value add.
It exposes what activities are in the team’s way. At the end of the exercise it’s always crystal clear what needs to be fixed so the team can speed up.
Where did waste walks come from?
The idea was originally developed by Taiichi Ohno, the Chief Engineer at Toyota, as part of the Toyota Production System (TPS). While its roots are deep in the industrial automotive process, TPS itself is fundamentally an approach to agile and continuous improvement.12
Toyota’s work culture integrates Kaizen, a Japanese word that means “change for the better.” It made the “1% rule” famous — empowering everyone to achieve 1% improvement daily, and in so doing attain a 37X improvement by the end of the year.
It means that striving for incremental, daily progress rather than drastic changes accumulates into more significant gains over time.
It’s a concept deeply embedded in Japanese culture. It’s a philosophy that puts attention on continuously improving one’s personal, home, social, and working life. Applied to the workplace it encompasses everyone — managers and workers alike.
Running a waste walk
Running a waste walk is almost ridiculously simple. Once your team has done it a couple of times, it becomes second nature — and it takes no more than a couple of minutes a day.
You don’t need any special tools. A simple Google Sheet to keep track of a few numbers is all you need:
While a Google Sheet works, something more structured is even better. The platform I wrote does a nice job and — after years of refinement — it now includes a dashboard and a handy, mobile-friendly app for the team (making activity logging a breeze).3
Case in point
I facilitate waste walks with my clients. The data exposed is always interesting, but what really matters is what you do with it.
In one case, a few things jumped right out:
First, the team’s value add vs. non-value add ratio was 38%. In other words, their overall efficiency loss was 38%.
Way too much work ended up in rework, manual activity and investigation.
A lot of time was going into planning even though it was happening inside the sprint, leading to wait time when the team didn’t have information they needed.
At first, a team hearing their “efficiency is 62%” might react negatively.
There’s another way to look at it: it’s an opportunity to accelerate: they had 163% of potential sitting on the table, waiting for the team to grab it!
Imagine that for a moment. Accelerating your own team’s velocity by a factor of about 1.6x — and improving your own quality of life along the way.
Can I ask a favor? Take a moment and refer a friend. It really helps build my readership so I can keep writing! Plus, you earn free premium access for each referral.
Building a case for quality of life
Most often, what a team learns from a waste walk isn’t exactly a revelation. Nearly every team I’ve worked with knows things could be better. They have a pretty good idea overall what could be made better.
What’s missing is a solid business case and prioritization.
That’s where a structured waste walk helps. The whole point is to quantify exactly where all that wasted effort is going — not just have a vague idea that automated testing might be better than manual testing, but to be able to show it with real, hard numbers.
In my client’s case, that 38% inefficiency translates into some really interesting upside. By recapturing that lost productivity it would mean an extra 6,635 hours of productive work gained back over the year!
That’s enough of an interesting business case to get the attention of leadership.
And once we have their attention, we can build a case to fix the problem — and, simultaneously, qualitatively improve the team’s life.
Setting reasonable goals
We can’t fix everything overnight. And trying to fix everything at once would be folly. Massive organizational reengineering efforts tend to fail more often than succeed.
A more rational approach is to prioritize the largest, non-value add culprit. Find the one or two things that are slowing the team down the most, and fix them.
For this team, manual activity is the #1 culprit. This includes time sunk into repetitive work, like manual testing, deployment management and configuration.
Rework is the #2 culprit. In other words, the team is spending too much time redoing work that should have been done once. That includes fixing bugs, investigating problems, filling in missing acceptance criteria and the like.
Strengthening your case
Having a strategy that more than doubles team productivity is exciting. Proving how it will work is something else.
Having specific, hard numbers is important.
For this we dig into each specific category. For example, the area of manual process.
Our waste walk exercise asked each team member to “bucket” their time each day. It only takes a couple of minutes, especially if you have a handy app. Those buckets include operations, manual testing, acceptance testing, and the like.
The team also indicates whether the activity was value add, or non-value add. The dividing line here is pretty simple: “value add” is work that is unique and adds value directly to the sprint and the product. For example, checking in brand new code.
On the other hand, “non-value add” is work that’s not unique, or that doesn’t add value directly to the sprint. Here, things like repetitive manual testing or manually deploying an environment would be “non-value add.” Likewise, hands-on tuning of an environment is considered non-value add (it could have been done through Infrastructure as Code instead).
Diving deeper: the root cause
Once you know where your effort is being wasted, the next step may not necessarily be fixing it.
Sometimes, it’s figuring out why that effort is being lost.
With manual process, it’s usually clear. Automate repetitive manual activity, recapturing time otherwise spent doing what machines could do for us.
But what about that big bucket of “rework?” Remember, that’s “work that should have been done once.” It’s a category that points the finger toward time spent diagnosing and fixing bugs and making changes.
This is where you’ll want to do some root cause analysis. Ask yourself, “why do we spend so much time here?”
That’s what a “rework retrospective” is for. It uncovers the root cause of the rework, even if it lies much earlier in the development pipeline:
Poor requirements gathering can often lead to flawless implementation of something the customer doesn’t want. Solution: Fix the requirements analysis and documentation phase, and “shift left” some technical expertise to help those efforts.
Defects in (or on the way to) production often indicate badly stated acceptance criteria. If the entire team doesn’t put attention on capturing complete criteria, it won’t matter. Improving acceptance criteria will cascade into fewer defects.
Frequent incidents around production deployment could indicate inconsistent deployment practices. This is usually because of manual process, which tends to be error prone. Infrastructure as Code and DSO templates will improve reliability and repeatability.
A note on perception
A waste walk is a powerful tool. It’s one I love to see teams use because it’s so effective at improving a team’s quality of life. It’s almost incidental that it also improves efficiency.
But an unfamiliar team could perceive it with fear. You’re asking the team to record data about performance. Here’s how you can avoid that fear:
Anonymize all of the data. Don’t put names on the activity tracking worksheets, just use a number. Assure the team it won’t affect personal performance.
Aggregate all the information so that individual performance data cannot be tracked.
Keep the focus on continuous improvement. Statistics like “38% efficiency” are less interesting than “6,636 hours of free productivity gained back.”
Make sure your team is in the loop and understands this is team driven. Your goal is to convince leadership to make changes you want.
Make change happen
Your team knows what’s broken. They’ve known for months, maybe years. But knowing isn’t enough.
What separates high-performing teams from everyone else isn’t better ideas — it’s better execution. It’s the discipline to measure what matters, prioritize ruthlessly, and act decisively.
The waste walk gives you that discipline. With a few minutes a day, you’ll have hard numbers that cut through all the noise. You’ll know exactly where your time goes and what needs to change. You see what inaction costs you.
More importantly, you’ll have the ammunition you need to make it happen, just like my client did:
Quantified waste transforming vague frustrations into specific targets. No more arguing about whether manual testing is “kind of a problem” — you’ll know it’s costing you 94 hours per sprint.
Prioritized opportunities focusing your limited energy on the highest-impact changes. Fix rework and automation first, worry about the small stuff later.
Root cause clarity ensures you’re solving the real problem, not just the symptoms. Poor requirements upstream create defects downstream — attack the source.
A bulletproof business case that gets leadership attention and resources. When you can show 6,636 hours of recaptured productivity, the conversation changes fast.
Stop tolerating waste. Start measuring it. Your team’s quality of life depends on it.
Further reading
If you found this article interesting you might enjoy this too:
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
Dan Sawyer, How To Do a Lean Waste Walk: Guide & Template, Expert Employee, expertemployee.com.
Nawras Skhmot, What is Lean?, Aug. 2017, The Lean Way blog, theleanway.net.
Boss Logic’s waste walk application provides advanced analytics, sprint-over-sprint comparisons, and workshops structured around recapturing productivity.