Sashimi

n Agile Project Management with Scrum, there’s a concept that really struck a chord with me: Sashimi. The idea is simple but powerful—software functionality should be delivered as thin, complete slices of value, each one fully implemented end to end.

Each sashimi slice includes:

• Working code
• Automated tests
• Updated documentation
• Data migration scripts (if needed)
• Deployment mechanism

In Agile terms, it’s done, done, done. You don’t move on until everything is complete. Not just coded—but deployable.

It is something that gives business value to the customer. It doesn't matter that improvement is small and incremental, because those sashimi slices can add up to a descent meal if you cycle fast enough.

That is why you have to be ruthless about automating repetitive tasks and eliminating anything that will slow you down. Those little bits administrivia will kill you if you keep hitting those pain points everytime you cycle through the process.

In the Bad Old Days

I would focus on getting the mechanics of a feature working and leave the polish—cosmetic issues, documentation, deployment steps—for later. I’d cluster features together under the logic of “efficiency,” but the result was a mounting list of lower-priority tasks that never quite got done.

Add to that the reality of interruption: just when I’d be mid-way through, I’d get pulled off to deal with a high-priority task. Then another. The result? A backlog of half-finished work that became unmanageable.

The Turning Point

To manage the chaos, I started:

• Breaking tasks into smaller pieces
• Reducing dependencies between new and old code so I could swap components more easily

Then I encountered Lean Software Development and its analogy of partially finished work as inventory—an invisible cost that clogs the system.

This clicked.

I began:

• Reducing the number of open tasks
• Limiting Work in Progress (WIP), a principle central to Kanban
• Reducing task size even further to make context switching less costly and progress more visible

Then I found Ward’s Wiki and the Extreme Programming (XP) community. 

There, I redefined my concept of “Done”.
Done didn’t mean “working on my machine.” 

It meant everything needed to ship to a user.

Evolution Through Experience

This shift didn’t happen overnight. It was shaped by:

• Hard-won experience
• Too many half-finished features
• Too many firefights interrupting other firefights
• Exposure to ideas that articulated the problems I had already felt

Why Sashimi Matters

The concept of sashimi sped up changes that were already taking place in my behaviour and made me more self-aware of the process I was undertaking.

Update: Expanding “Done”

Part of my evolving understanding of “done” now includes  

An automated build environment that runs tests as part of the process.

It's not just a nice-to-have—it's become essential.

Why? Because I’ve seen firsthand how subtle build inconsistencies can derail progress.

"It Worked on My Machine..."

There’s nothing quite as frustrating as having an application that:

• Works perfectly on one developer’s machine
• But fails when built or run elsewhere—on another machine, in CI, or in production

This doesn’t happen often; it is fairly rare. But it’s happened enough times that I no longer trust any manual process to be repeatable or reliable.

Summary

🌀 Agile Practices

• Sashimi in Scrum: delivering thin, end-to-end slices of value.
• Definition of Done: shifting from “works on my machine” to “deployable.”
• Work in Progress (WIP) Limits: from Kanban, reducing open tasks.
• Extreme Programming (XP): redefining completeness, emphasizing shippable quality.

🏭 Lean Thinking

• Partially Finished Work as Inventory: invisible cost that clogs the system.
• Flow Efficiency: smaller tasks, fewer dependencies, reduced delays.
• Continuous Improvement: adopting practices based on reflection and feedback.

⚙️ Technical Foundations

• Automated Builds & Tests: CI/CD pipelines as essential for reliability.
• Deployment Mechanisms: ensuring features can move smoothly to production.
• Reducing Dependencies: making systems easier to swap, replace, or upgrade.

👤 Personal Lessons & Reflections

• The “Bad Old Days”: half-finished features, constant interruptions, firefights.
• Turning Point: discovering Lean & XP as lenses for understanding pain points.
• Evolution Over Time: gradual, experience-driven shift in mindset.
• Self-Awareness in Process: recognizing unfinished work as the real bottleneck.

🔑 Key Takeaways

• If it’s not deployable, it’s not done.
• Half-done isn’t progress. Shippable is.
• Automation isn’t optional—it’s survival.

Related Posts

• The Dangers of Heroism
• 5 Whys

More Information

Online Resources

• Ward’s Wiki

Articles

• Sashimi

Books

Agile Project Management with Scrum by Ken Schwaber

How Scrum can be applied to project management. The book is less of a “theory manual” and more of a practical guide with stories that show Scrum in action — including successes and common pitfalls.

Lean Software Development by Mary & Tom Poppendieck

Adapts lean manufacturing principles (originating from Toyota Production System) to the world of software development. It provides practical tools and guidance for creating faster, more efficient, and higher-quality software while eliminating waste.

Kanban by David J. Anderson

Kanban starts with your existing workflow and evolves it gradually by visualizing work, limiting WIP (work in progress), and improving flow.

Getting Things Done by David Allen

It emphasizes capturing everything out of your head and into an external system, then breaking tasks down into clearly actionable, time-bounded items—often referred to as the “next action.”