Waste walk

Recommended owner: Coach, scrum master or tech lead familiar with the team’s delivery process. Typically the same person who’ll run the readout at the end of the exercise, so the institutional memory carries through. The facilitator’s job isn’t to police logging — it’s to make logging easy, normal and safe, and to keep the team aware that the data they produce is for them.

Goals

What the team will accomplish:

1. Capture every meaningful unit of effort across the exercise, tagged by activity type and marked value-add or non-value-add.
2. Build a fact-based view of where the team’s hours go.
3. Quantify the productivity opportunity in hours, calendar days and (where leadership cares) dollars.
4. Set the team up with a defensible business case for change.

Impact

What the team walks away with at the end of the exercise:

1. A prioritized, fact-based understanding of what’s hurting team productivity — and where the biggest recoveries are.
2. A shared language for talking about waste without it sounding like a performance review.
3. A team culture where surfacing waste is normal and constructive rather than taboo.
4. A defensible business case for change, especially for the things the team can’t fix on its own and needs leadership help with.

When to run a waste walk

Reach for it when:

• The team knows time is leaking away but feels overwhelmed and unable to change things for the better. The classic case. Velocity feels slower than the work warrants, retros surface the same vague frustrations sprint after sprint and nobody can quantify the gap. The waste walk converts gut feel into action.
• You’re about to ask for budget or organizational change — for tooling, headcount, a meeting-culture reset or a structural fix that touches another team. Leadership funds quantified opportunities, not opinions. Walk into that conversation with hours, not adjectives.
• The team has just absorbed a new tool, platform or process and you suspect it’s costing more than it’s giving back. The first three sprints after a change are when the new overhead is most visible — measure it before it normalizes.
• You haven’t run one in three months or more. Waste walks are a continuous-improvement practice, not a one-off — the continuous part is what makes the math work. The categories that dominated last time are usually solved by now; new ones have emerged. The next walk is how you find them.

Don’t reach for it when:

• The team is in crunch. A waste walk asks for a few minutes a day from every team member, plus a forty-five-minute kickoff and a one-hour readout at the end. Asking for that during a hard delivery window is bad timing and bad faith. Wait until after.
• The team has just formed and trust is still being built. Logging your own activity in a visible way takes a baseline of psychological safety. Spend the first one or two sprints earning that, then run the waste walk.
• You can’t commit to running the readout at the end. A walk without a readout is data that dies in someone’s downloads folder. If the calendar can’t hold both, don’t start.

Audience and personas

Facilitator

Coach, scrum master or tech lead. Familiar with the team’s working cadence and delivery pipeline. Comfortable with the Lean vocabulary or willing to learn it in advance of the kickoff. Trusted by the team — the facilitator is asking everyone to log their own time, which only works when the request feels like an investment, not surveillance.

Required participants

Every team member who contributes during the exercise window — engineers, PO, BA, QA, designers, the scrum master, anyone whose work lands in scope. Part-time contributors count if they’re spending any meaningful time on the team’s work. The waste walk’s value compounds with coverage: gaps in who’s logging produce gaps in what the readout can see.

Optional but valuable

• Line manager or product manager as a one-on-one ahead of the kickoff so they know the walk is happening and what to expect from the readout. They are not required at the kickoff itself — that’s a team session.
• A peer team’s coach or scrum master as a quiet observer, especially if their team is running their own waste walk next sprint. Cross-pollination is fast and usually produces a question or two the team hadn’t thought to ask.

Roles

Assign these before the kickoff so nobody is wondering whose job is whose.

The roles aren’t heavyweight. Most of the time, the facilitator’s job is to be visible, available and quietly encouraging. The team does the work.

The Lean foundations

The waste walk is older than software. It’s worth a few minutes to ground the team in where it came from, because the lineage produces a vocabulary the team will use for the rest of the walk.

Shigeo Shingo — a Japanese industrial engineer and one of the architects of the Toyota Production System — codified the original seven wastes (muda) in the post-war development of TPS at Toyota. The list described categories of activity that consumed resources but produced no value for the customer. Modern Lean practice adds an eighth — non-utilized talent — and remembers all eight with the mnemonic DOWNTIME:

Without that ongoing reinforcement, the mnemonic stays in the deck and the team falls back on the euphemisms they already had — “process overhead,” “tech debt,” “scope creep.” Those are the words DOWNTIME exists to replace.

Kaizen — the why behind the practice

The waste walk pairs with the Lean concept of kaizen — continuous, incremental improvement. The 1% rule: one percent better every day compounds to roughly thirty-seven times over a year. Software teams chasing 10x improvements once a year almost always lose to teams running small, disciplined improvements every sprint. The waste walk is how a team finds the next 1%.

Value stream engineering and the choice of vocabulary

The technique a waste walk produces — sorting effort into value-adding and non-value-adding categories — is value stream mapping (VSM), a tool that came out of Six Sigma’s adaptation of TPS for non-manufacturing work. VSM’s language was built for production lines. Adapted directly into a scrum team’s vocabulary, the labels can land awkwardly: nobody likes hearing that the meeting they ran was “non-value add.”

GembaKai gives the organization a choice. The same data can be labelled in-sprint versus out-of-sprint — effort that directly advances the sprint’s commitments versus everything else. Functionally it’s identical to VA / NVA, but it sidesteps the language barrier most scrum teams hit. Teams running waterfall, kanban or hybrid models usually prefer the original VA / NVA terminology because it matches the references they already use. The terminology is an organization-level setting, not a per-team or per-sprint toggle — confirm with your GembaKai admin which one your organization runs on before the kickoff, and use that label consistently throughout the walk. If the org-level choice doesn’t fit the team’s culture, that’s a conversation to have with the admin before sprint zero, not something to relitigate during the walk.

Activities and how they’re categorized

GembaKai organizes activities into named categories of work — meetings, refinement, coding, testing, manual operations, training, rework and so on. The readout aggregates those activities into three primary out-of-sprint categories: rework, automation (manual work that should be automated) and planning (meetings, decisions, dependencies). A fourth bucket, overhead, is always out-of-sprint regardless — corporate training, all-hands, HR work and anything else that doesn’t move the team’s product forward.

A note on context switching. The readout also surfaces an analytical category, context switching — but nobody logs against it directly. The system computes it from each team member’s logging granularity: how many distinct activities someone captures in a day, measured against a baseline. Frequent switching shows up as a higher activity count for the same number of hours. The implication for the team is simply log honestly — don’t collapse a fragmented afternoon into a single ninety-minute block to keep the form short. That collapses the signal the system uses to see the switching.

For everything else, the in-sprint / out-of-sprint call is a judgement the team member makes when they log. The rule of thumb:

• Preparation activities (refinement, design, AC writing) are in-sprint unless the outcome required rework — for instance, refining a story a second time because the right people weren’t in the room the first time.
• Development activities (coding, pairing, testing) are in-sprint unless the outcome required rework — for instance, redoing work because the acceptance criteria turned out to be wrong, or because a manual deploy step failed and had to be repeated.
• Delivery activities (deploys, approvals, validation) are out-of-sprint if they involved manual work that should have been automated, or waits that better planning would have avoided.

The team doesn’t have to get every call right. The aggregate over a window of ten or so logging days is what produces signal — individual judgement-call errors wash out in the totals.

Pre-launch (1–2 weeks out)

The facilitator’s job before the kickoff. None of it is heavy, but skipping it shows up later as a team that didn’t quite know what was coming and an exercise of patchy logging.

1. Set up the sprint in GembaKai. Create the sprint, set its dates to match the team’s working cadence and invite the team members. As team members join the platform they’ll select their role, which customizes activity terminology based on typical day-to-day activities. Two GembaKai mechanics worth knowing up front:

   • Sprint states are mostly automatic. A new sprint starts in planning and transitions to open on the morning of its start date. About two days after the end date it transitions to closed — or incomplete, if the team didn’t capture enough data. You can drive the transitions manually too.
   • Membership has to match. A team member must be active on both the Team and the Sprint to log activity. If someone joins partway through, add them to both.

   Confirm separately that the org-level terminology setting (in-sprint / out-of-sprint versus VA / NVA — see the previous section) matches what the team is expecting; if it doesn’t, fix that with the GembaKai admin before the kickoff, not during it.

   

   

2. Send a heads-up to the team a week out. A short message explaining what a waste walk is, why the team is doing one and what the time commitment looks like (a few minutes a day, plus a forty-five-minute kickoff and a one-hour readout at the end).

3. Invite the team to GembaKai. If any members don’t have accounts, add them and send invites. Check in and make sure they have successfully logged in before the kickoff. Part of the kickoff is a hands-on exercise.

4. Schedule the kickoff and the readout in the same calendar action. Forty-five minutes for the kickoff on or shortly before sprint start; one hour for the readout on or shortly after sprint end. Get both on calendars now. If the readout slips because it never got booked, the walk loses its point.

5. Have a one-on-one with the engineering manager. Five minutes. Tell them the team is running a waste walk, what the readout will produce and that you’ll share the findings. This is partly a courtesy and partly insurance — leadership that gets surprised by data tends to resist it. Leadership that knew it was coming tends to engage with it.

6. Decide on the daily nudge mechanic. GembaKai already sends an automated nudge to anyone who isn’t actively logging. Often that’s not enough. Layer a second prompt that fits the team’s existing rituals: a Slack reminder, a calendar block at 4:55 PM or a daily message in the team channel. The rule is that missing a day costs more than the discipline does, because nobody remembers what they were doing forty-eight hours ago.

Kickoff session — about 45 minutes

The kickoff is a single team session, in person or video, scheduled close to the start of the sprint. Forty-five minutes is the budget; the team is doing real work the same day and the kickoff should feel like a careful explanation rather than a workshop.

Exercise 1 — Framing the waste walk (3 min)

Open with the why. The team will spend the exercise logging activity not because anyone is auditing them, but because the team itself is the customer of the data. Hit three points:

1. The waste walk produces empirical data on where the team’s time is going. It replaces “we feel slow” with hours.
2. The data belongs to the team. Aggregated, anonymized, summarized in the readout. No individual’s logs are surfaced to anyone outside the team.
3. The whole exercise costs each person two or three minutes a day, plus the kickoff and the readout. That’s it.

Frame the practice as introspection, not measurement of the people. The first time a team hears “we’re going to log our activity,” the worry is performance review. Address it in the first ninety seconds and the rest of the session is easier.

Exercise 2 — DOWNTIME and the Lean lineage (10 min)

Walk the team through the eight wastes. Don’t lecture — name each one and ask the team for a software example. They’ll produce better examples than you would, and the act of generating them sticks better than hearing them.

A short story works well to anchor the lineage: Shigeo Shingo at Toyota, the seven wastes coming out of the production system, the eighth added later, the practice spreading through Six Sigma and eventually into software via Lean Software Development. “This is older than every framework you’ve used. The reason it works for us is the same reason it worked for Toyota: where time goes is almost never where you think it goes.”

If the team has appetite, talk briefly about kaizen and the 1% rule. If they’re hungry to get to the app, skip it — you can bring it back at the readout.

Exercise 3 — Tour the GembaKai app (10 min)

Project the app and walk the team through the screens they’ll use. Three pages matter:

1. The activity view — where they’ll log each day. Show the activity list, the in-sprint / out-of-sprint toggle, the comment field and how to mark a partial split when something was half-good, half-rework.
2. The comment cards — where the qualitative material lives. Most teams underuse this; a one-line comment on a thirty-minute activity (“manual deploy step number four — should be automated”) is what makes the readout vivid.
3. The sprint timeline — used by the team for a day-by-day picture of what’s getting captured; also mention the activity thresholds (visible on the sprint activity page).
4. Reminders — Mention that they’ll receive an email from GembaKai when the sprint opens, and a separate nudge in the afternoon if they haven’t logged anything yet.

Show how to view closed sprints and prior readouts if any exist — orientation pays off later.

Exercise 4 — The mini-walk (15 min)

Everyone logs their activities of yesterday, live, together. Pick yesterday rather than today so people don’t get pulled into trying to log everything in real time during the kickoff.

The mini-walk does three things at once: it converts the theory into muscle memory, it surfaces edge cases the team will hit later (what if I context-switched four times? what if I don’t remember exactly how long the meeting ran?) and it gives the facilitator a chance to answer those edge cases for everyone at once instead of one Slack thread at a time.

You launch a mini-walk from the Team dashboard. Everyone on the team who’s already logged in will automatically be pulled into an “Onboarding mini-walk” exercise. This is the time to translate theory into muscle memory, questions into knowledge.

The mini-walk operates like this:

• It pulls everyone into a model sprint (just 5 days long, with the first day set as the prior workday).
• At the same time, a board is set up where every activity logged is shown, along with the comments from the activity.
• Any activities that are logged in the mini-walk are a rehearsal. We’ll use the activity to log yesterday’s activities, talk about the choices made and discuss how DOWNTIME may change how we look at things.

Click the “Start Mini-walk” button to launch the exercise, then:

1. Just under the join code is a URL with a small copy icon. Click it, then paste the URL into team chat. Anyone late to the party can click the URL to join the exercise.
2. Click on the facilitator board link directly below the join code box — this will take you to the mini-walk board. All activities logged during the exercise will appear on the board automatically.
3. You can use the board just as you would other GembaKai boards — organize cards, add your own and even write a few helpful hints (all using the speed dial).

A few mechanics to be aware of:

• If you lose track of the mini-walk board, you can find it on the home page (in the Artifacts list).
• Only active team members will join the exercise. Anyone who is not a member of the team won’t have access.
• Team members will also see an “Onboarding mini-walk” sprint in their activity sidebar. They can join the activity be either clicking the URL with the join code, or by selecting the “Onboarding mini-walk” sprint manually.
• The exercise and the mini-walk board will automatically close after 2 hours.
• On the mini-walk board menu you’ll find an “End mini-walk” menu item. Clicking this will kick everyone out of the exercise and tear down the exercise board and sprint.

Common questions that come up here, with the answers worth having ready:

• “What if I don’t remember the exact time?” Round to the nearest fifteen minutes. Precision matters less than coverage.
• “What if I context-switched four times?” Log each piece honestly — separate activities, separate entries, even short ones. There’s no context-switching activity to log against; the system measures switching by counting how many distinct activities you logged in a day relative to a baseline. Granular logging gives the readout the signal it needs.
• “What if I’m not sure if it’s in-sprint or out-of-sprint?” Think about the DOWNTIME mnemonic. Does any one type of waste seem to fit? If not, default to in-sprint. The aggregate is what matters; the team will get better at the call across the sprint.

Exercise 5 — Psychological safety and commitment (5 min)

The hardest exercise in the session and the one most worth getting right. Three explicit commitments from the facilitator:

1. Aggregation only. Individual logs are not surfaced to leadership, to other teams or to anyone outside the team. The readout shows team totals, not per-person numbers.
2. No performance use. The data is for process improvement. It will not feed performance reviews, capacity planning or staffing decisions. If the team’s leadership disagrees with that boundary, the boundary needs to be settled before the walk, not during it.
3. Visibility goes both ways. The team will see the readout. The team will pick the next workshop. Leadership sees aggregates — not raw data — and only after the team has had the conversation.

Then ask for the team’s commitment in return: log every day, even on partial days, even when the day was unusual. The walk only works on full coverage.

Close with the readout date. Confirm it on the calendar. “Two weeks from Friday, one hour, this room. The data we collect between now and then is what we’ll be looking at.”

During the sprint — the daily ritual

After the kickoff, the facilitator’s job becomes mostly invisible. Three things keep the walk healthy.

The end-of-day stand-down (5 min/day)

A five-minute, end-of-day prompt for the team. Not a meeting — a Slack message, a calendar block, a stand-up rider, whatever fits the team’s existing rituals. The prompt is one line: “Two minutes — log today’s activity in GembaKai. Comments help future-you. See you tomorrow.”

The point is to lower the cognitive cost of logging until it’s smaller than the cognitive cost of not logging. Most teams that abandon waste walks abandon them on day three because the daily logging slipped on day two and never recovered. The stand-down is the protection against that.

Following up on missed logs

Each morning, check who logged yesterday and who didn’t. For the people who didn’t, a short, private, friendly message — “Hey, didn’t see your log for yesterday. Two minutes when you have them?” No public shaming, no team-channel call-outs. The walk is a team practice; chasing logs is one-on-one work.

If someone hasn’t logged for three days running, talk to them. Usually it’s a tool friction or a confusion the kickoff didn’t fully resolve, and a five-minute conversation fixes both. Occasionally it’s discomfort with the practice itself, in which case it’s worth surfacing — not punishing — so the team can decide together whether the walk is the right move for them right now.

Watch the comments, not just the totals

The qualitative material in the comment cards is what makes the readout land. Mid-sprint, skim the comments coming in. Two or three vivid ones a day is a healthy team; zero is a team logging numbers without context. If the comments are sparse, mention it at the next stand-down: “Future-you will thank present-you for a one-line comment. Especially on the rough days.”

What to watch for as facilitator

You’re not looking at the numbers in detail during the sprint — that’s the readout’s job. But three things are worth noticing in flight:

• Coverage — is everyone logging, every day? If coverage drops below about eighty percent across the team, the readout’s signal degrades and it’s worth a re-up at the next stand-up.
• Unusual spikes — a single day where someone logged eight hours of rework. Not a problem in itself, but worth a private check-in: was it a bad day, a structural issue or a misread of the activity?
• Pattern early reads — by the middle of the sprint you’ll see the shape of the data. Resist the urge to share that read with the team. The readout is the moment to read the data together; previewing it dilutes the surprise that makes the readout work.

Closing handoff

The waste walk ends the day the sprint closes. The very next session — typically within a week — is the GembaKai readout, which is its own one-hour structured workshop. The handoff between the two is mechanical:

1. Close the sprint in GembaKai. This freezes the data and unlocks the readout view.
2. Spot-check the data for anything that looks anomalous before the readout — a category that spiked unexpectedly, an activity with one logged hour total (usually a misclassification), a team member whose totals look wrong. Note them; don’t act on them yet. The readout is the right venue.
3. Confirm the readout calendar invite is still on. Send the readout’s pre-homework (covered in the readout guide).

The readout is where the sprint’s data becomes a decision — which follow-on workshop to run next.

Tips for success

Carried forward from the Lean tradition, with adaptations for software teams.

Create psychological safety, and keep creating it. The first commitment in the kickoff isn’t enough on its own. Repeat it during the sprint. Anytime the data threatens to feel like measurement of people, name the threat and reset the framing. Process improvement, not performance evaluation.

Everyone takes part. A waste walk that excludes the senior engineer, the PO or the designer produces a readout with a hole in it. Make sure the optionality is clear in advance (“everyone in the sprint logs”) and the holdouts have a reason that the team can engage with.

Don’t bypass leadership. Especially when the readout is likely to produce a business case for change outside the team. Leadership that gets the case in a conversation accepts it; leadership that gets blindsided rejects it. The pre-launch one-on-one is the protection.

Be observant. The data is one source of truth. The conversations around the data are another. A team member who comments “this was rework” on three logs in a week is telling you something the totals won’t.

Be genuine. When someone surfaces a piece of waste that turns into a workshop action, name them. When the team’s logging discipline holds through a rough week, say so. The walk is a team practice and team practices are sustained by recognition.

Do no harm. Don’t start a waste walk in a crunch. Don’t start one the week after a difficult release. Don’t start one when the team is rebuilding trust after a hard conversation. Bad timing turns the practice into one more burden.

When not to run a waste walk

The full set of conditions where the walk’s introspective nature hurts more than it helps:

• Crunch. Wait. The walk is meaningful when the team has the bandwidth to think about it.
• Newly formed team. Two or three sprints of running together first, so the logging happens inside an established baseline of trust.
• Hostile leadership context. If leadership is going to use the data for things the walk’s contract explicitly forbids — performance reviews, headcount decisions, capacity squeezes — the walk doesn’t run safely. Settle that conversation first or don’t run at all.
• Already mid-improvement. If the team has just landed a major process change and is still absorbing it, give the change a sprint or two to settle before measuring it.

Capturing activity day-to-day is rarely harmful in itself. The risk concentrates in the readout — that’s where vulnerable material gets discussed and acted on. If the readout can’t happen in good conditions, the walk shouldn’t start.

Alternative paths

Trial mini-walk

Some teams want to try the practice before committing a full sprint. Run a one-week mini-walk — same kickoff, same daily ritual, scaled-down readout — to let the team feel the cost and the value before going further. The readout for a one-week walk is shorter and the data is thinner, but it’s enough to make the do we want to do this for real? decision an informed one.

Async-first or distributed teams

The kickoff works on video. The daily ritual works in async. What weakens is the comment density — async teams tend to log numbers and skip the qualitative material. Compensate with a richer mid-sprint check-in: a Wednesday Slack thread asking “what’s the most representative comment from your week so far?” will recover most of the qualitative signal a co-located team gets for free.

Mid-cadence change

If sprint boundaries don’t match the team’s natural delivery rhythm — for instance, a kanban team without sprints — run the walk over a fixed two-week window that the team picks deliberately. Same kickoff, same daily ritual, same handoff. The readout adjusts naturally; there’s no scrum-specific machinery in either guide.

Capturing results

The result of the waste walk is the data the team logs. That data flows directly into the readout — no separate write-up step is needed at this stage. The readout produces the meeting summary, the chosen workshop, the action list and the paper trail.

Two facilitator-side notes worth keeping:

1. Document any unusual sprint conditions that might affect the readout’s interpretation — a holiday, a major outage, an unusual amount of customer demos. Drop these into the readout’s pre-homework notes so they’re not surprises in the room.
2. Capture lessons learned about the walk itself. If the kickoff missed something, if an activity category was confusing, if a logging mechanism didn’t fit — note it for the next walk. Each walk is an iteration on the practice as much as it is data on the team.

Follow-up

• Within 24 hours of sprint close: close the sprint in GembaKai, spot-check the data, confirm the readout is on calendars.
• Within one week of sprint close: run the readout. The data goes stale faster than most teams expect.
• At least every three months, sooner if you can: run the next waste walk. Continuous improvement works because it’s continuous — discover what needs fixing, fix it, repeat. Three months is the outer edge of useful cadence; teams that run a walk every two or three sprints get the strongest signal because the gap between seeing the problem and measuring the fix is short enough to feel like a feedback loop instead of a once-a-quarter ritual.

References

Related guides

• GembaKai readout — the one-hour closing session this walk produces the data for. Always paired.
• Gemba walk — Taiichi Ohno’s go see practice. Useful when the readout’s data raises questions only direct observation can answer.
• Rework workshop, automation workshop, planning workshop — the three follow-on workshops the readout typically picks from.

Process guide

• Pareto analysis — the 80/20 method the readout uses to pick the next workshop from the waste walk’s data.

Delivery Playbook articles

• My formula for running a successful workshop — the meta-framework these guides follow.
• Value stream engineering in a nutshell — the VSM lineage in more depth than this guide covers.
• Context switching is killing your gains (part 2) — companion piece on one of the four primary readout categories.

External references

• Shigeo Shingo, A Study of the Toyota Production System from an Industrial Engineering Viewpoint (Productivity Press, 1989) — the canonical English-language source on the seven wastes from one of the architects of TPS.
• Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988) — the foundational text. Ohno was Shingo’s collaborator and TPS’s other principal architect.
• Masaaki Imai, Gemba Kaizen (McGraw-Hill, 1997) — the canonical Western adaptation of kaizen for non-Toyota contexts.
• Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003) — the bridge between manufacturing Lean and software practice.
• Lean Enterprise Institute, The 8 wastes of Lean — short, authoritative reference for the DOWNTIME list.
• Value stream mapping (Wikipedia) — the VSM technique the waste walk’s bucketing draws from.