So… we know that we’re supposed to be developing software incrementally, using an Agile process like Scrum. We know we should be building our software a little bit at a time — coding, testing, and reviewing as we go, right? What does this actually mean? What do the increments look like? How big are they? How small are they? How do we find them? And so on…

These are all good questions. In this blog I will discuss one part of the puzzle, the Sashimi Method of incremental development, which has been around a long time. I first heard of it in the early 1990s, in the context of RUP (the Rational Unified Process)[1], a high-ceremony Agile process that focused its development on Use Cases. It was introduced to me again, in the late 1990s, as a way to understand XP (eXtreme Programming). And again, in the early 2000s, by Ken Schwaber, as the preferred way to develop software within a Scrum Team. And it’s baked into the current Software Craftsmanship movement, as part of developing Clean Code.

Like I said, the Sashimi method has been around a long time. It’s pretty much a standard way to do things, but not everybody knows about it. Pity. So I’m going to talk about it.

Let’s say our Client has a hankering for salmon, and says to us: “I want a salmon.” and we decide to build her one.

Method 1: The Architecture-Centric Method

The Architecture-Centric Method is pretty simple. Here’s what might happen:

  1. First, we build the skeleton (architecture) of the fish;
  2. Then we add in some guts, brain, gills, and other ‘innards’ (the required infrastructure);
  3. Then the muscles (the actual functional code);
  4. And, finally, the skin and fins (the interface).

And, voila, we have a salmon to deliver to our Client.

Method 2: The Sashimi Method

Now let’s do it in an Agile way. We’re not sure that the Client really wants a salmon, we just know that was just the best she could do to explain what she wanted. We’re Agile, so we know ‘we don’t know what we want to know,’ so we start building something, a little bit at a time, to try to figure it out. Sashimi is thinly-sliced fish, and this method is called the Sashimi Method because we build our fish one thin slice at a time:

  1. First, we work with our Client to build a thin ‘slice’ of functionality, determined by a single Acceptance Test. This requires building a little bit of bone, a little bit of ‘innards’, some muscles, and some skin. After getting it accepted and adding the Acceptance Test to the Regression Test suite, we Refactor it to clean up its structure.
  2. Then, we work with the Client to build another ‘slice’ defined by an Acceptance Test, and add it to whatever slices we already have. Add the Acceptance Test to the Regression Test Suite. Refactor so that the bones line up, the muscles line up, the guts line up, the skin lines up, and we can’t tell where the new stuff stops and the old stuff begins
  3. Review what we have so far with the Client.
  4. Repeat Steps 2-3 until the Client says: “that’s enough! I’ll take it…” and then deliver it to her.

The “Sashimi Method” For Building Software | 3Back Scrum & Agile Blog

So, what’s going on here, with the Sashimi Method?

  • We are building the fish one passing Acceptance Test at a time;
  • We are making the required Architectural Decisions (bones) and building required Infrastructure (‘innards’) as we go, only building what we need to support the Acceptance Test we’re currently adding;
  • We are refactoring constantly, so that design ’emerges’ and the fish has uniform quality throughout; and
  • We let the Client lead, so we only build what she actually wants, which could be only the fillets with just enough bones and ‘innards’ to support them.

Note that we started off thinking we were developing a Salmon, but maybe the Client has us finish up by building a Trout. We could wind up delivering a fish that is half Salmon, half Trout — and only the good parts… yummy!

And, that’s the Sashimi Method.

It’s Not Really that Simple

This method is simple, and it’s also simplistic.

In the Sashimi Method, all Stories are Functional Stories that build a little Architecture, a little Infrastructure, some functionality and some interface.

Real development isn’t like that:

  • Only some Functional Stories require us to make Architectural Decisions or build some Infrastructure. We call these Architecturally-Significant Functional Stories, and the other Functional Stories leverage what they build;
  • Not all Stories are Functional. All the Team’s work comes from the Backlog in the form of Stories, and not all work is Developing Functionality.
    • The Team may need to do some Spikes, Exploratory Testing, Release Activities, Training the Client, etc… There is a lot of Product-related work to do besides actual Development; and
    • The Team may need to do Chores, which is work that is not Development but just needs to be done in order to be able to Develop; examples include acquiring Tools and Team Training.

But, except for these exceptions, the Sashimi Method is a pretty good metaphor for Agile Software Development.

Looking for more ways to refine the methods your Team uses to software?

 We’ve got a Scrum 3.0 Conference for that.

As Always, Stay Agile.


Notes and Sources

  1. “Rational Unified Process: Overview.” RUP Homepage. Accessed May 18, 2017. http://sce.uhcl.edu/helm/rationalunifiedprocess/.

Leave a Reply

Your email address will not be published. Required fields are marked *