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
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
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
Done didn’t mean “working on my machine.”
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
Articles
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.
No comments:
Post a Comment