Eliminating Development Waste

As a delivery lead, your job is not to make people busier; it is to make value flow. This course gives you two complementary toolkits for exactly that: Lean thinking to strip waste out of how work moves, and Extreme Programming discipline to build quality in so the work stays fast. You will then extend those foundations into DevOps, DevSecOps, and the responsible use of AI in delivery.

By the end of this course, you'll be able to:

• Diagnose waste in a delivery process using the eight wastes and value stream mapping.
• Embed XP technical discipline (TDD, pairing, refactoring, continuous integration) that builds quality in rather than inspecting it out.
• Shift quality left and protect a sustainable pace using fast feedback loops and well-being signals.
• Tighten customer feedback loops and deliver value in small, usable increments.
• Modernize delivery with trunk-based development, progressive delivery, shift-left security, and DORA metrics.
• Introduce AI into delivery with clear guardrails and honest ROI, not inflated velocity.

This first unit starts where Lean does: learning to see the waste that quietly inflates your lead time, and to set up flow that prevents it from piling back up.

When a team "ships slowly despite working hard," the problem is almost never effort. It is waste built into the process. Mary and Tom Poppendieck adapted Toyota's wastes to software in Lean Software Development, and the eight wastes give you a vocabulary to name what's stealing your time instead of vaguely blaming velocity.

Walk your board and look for them by name. "Partially done work" is anything started but not delivered: branches open for weeks, code waiting on review. "Extra features" are gold-plating nobody asked for. "Relearning" is re-deriving knowledge that already existed but wasn't captured. "Handoffs" are every transfer between people or teams, each one losing context. "Task switching" is the cost of everyone juggling three things at once. "Delays" are the queues where work sits idle. "Defects" are rework, the most expensive when caught late. And "unused talent" is the senior engineer stuck doing ticket triage instead of the hard design only they can do.

The coaching move is simple: stop treating these as individual failings and start treating them as system signals. When you can point at a card and say "that is partially done work aging in a queue," you have converted a frustration into something the team can actually fix.

Naming wastes one at a time is useful, but to find the biggest one you need to see the whole flow. Value Stream Mapping is how you do it. You draw every step a work item passes through from idea to production, then mark two numbers on each step: the active work time (touch time) and the wait time before it.

Do this once and a pattern almost always jumps out. A feature that took two days of actual coding spent three weeks in the pipeline, most of it waiting for review, for QA, for a release window. That ratio is the point. The leverage is rarely in making the coding faster; it is in collapsing the waiting, the handoffs, and the rework that sit between the value-added steps.

A simple value stream map makes the gap impossible to miss. For each step, write the touch time (active work) next to the wait time before the next step picks it up:

Touch time is a fraction of total lead time; the rest is work sitting idle in queues. That ratio — value-added time versus elapsed time — is exactly where the leverage lives.

So map it with the team, not for them. Put the steps on a wall, ask "how long does work actually sit here before someone picks it up?", and let the wait time make the case. You are not looking for an idealized process. You are looking for the gap between how work is supposed to move and how it really does.

Once you can see the waiting, the instinct is to keep everyone maximally busy so nothing is idle. That instinct is the trap. Pushing work onto people the moment they have a free minute creates more partially done work, more task switching, and longer queues. The fix is a pull system: work is pulled into a stage only when there is genuine capacity to finish it, with WIP limits as the signal. This is what enables just-in-time delivery, and it almost always feels less efficient locally while being far more effective system-wide.

That tension between local efficiency and system effectiveness is the most important idea in this unit.

• Dan: Everyone's slammed this sprint, so we're moving fast.
• Nova: Busy, sure. But how many of those eleven items are actually finished and in front of users?
• Dan: Two. The rest are mid-review or waiting on QA.
• Nova: So nine are partially done work sitting in queues. The team is fully utilized and the system is barely flowing.
• Dan: When you put it that way, "busy" isn't the number I should be watching.

Notice Nova never argues effort. She reframes the metric from utilization (busy people) to effectiveness (value delivered), and the conclusion follows on its own.

The takeaway for this unit: a busy system is not a fast one, so manage flow, not occupancy. Several practices build on this next. You'll start with a quick value-stream reading exercise to sharpen your eye for waiting versus value-added work, then write an assessment that names three real wastes you could hand to engineering leadership, and rehearse the live conversation where you defend smaller batches against the "but that's less efficient" reflex. Your move this week: pick one workflow, mark its wait times, and let the ratio do the talking.