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.

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:

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.