
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
More Information
Online Resources
Books
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.
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 starts with your existing workflow and
evolves it gradually by visualizing work, limiting WIP
(work in progress), and improving flow.
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.”