

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:
In Agile terms, it’s done, done, done. You don’t move on until everything is complete. Not just coded—but deployable.
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:
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:
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.