Forewarned is forearmed for this post, I will admit that this evening has been largely filled with music of a more psychedelic nature. You can blame Jefferson Airplane for this, but if you stick with me for the journey you will learn the connection between fish, extreme sports and technology processes with nary a reference to Douglas Adams (so long and thanks for all the fish).
Fish
There is a curious fixation in agile circles with animals, from references to chickens and pigs through to fish dishes in this case Sashimi (OK, not technically an animal, but I’m trying to keep the word count down believe it or not).
Sashimi is a dish that comprises thinly sliced pieces of fish (or meat) and eaten with soy sauce. Ken Schwaber, one of the godfathers of Scrum is a particular fan.
Each thin slice is complete in itself, a complete taste similar to the way every other slice tastes.
Ken Schwaber – Agile Project Management with Scrum
The Sashimi approach to software architecture actually predates agile methodologies by a number of years, but has been thoroughly adopted by the agile world.
The principle behind the Sashimi approach is that development should progress in a series of small iterations (slices) with each iteration being complete, resulting in an increment in functionality and by extension value to the customer.
That all makes perfect sense, what could possibly go wrong?
A common interpretation of this approach takes the abuse of fish a little further:
A customer approaches your team requesting a salmon. The traditional approach to software development will start by building the skeleton (the architecture), then build out the guts (nasty, but representing the infrastructure of the system), followed by the muscle (the main logic and functionality) and finally the pretty shimmering skin (the user interfaces).
With the Sashimi method, and any agile method, the assumption is that the client isn’t entirely sure what they want. Do they really want a salmon, or is it just a bit of a fish? So your team builds a slice that includes a bit of skeleton, a bit of the guts, a little muscle and then just enough skin for the customer to see some value. If the customer is happy it’s handed over, otherwise another slice is started.
It’s a bit of a brutal way to express a technical concept, but park the image of a salmon steak in your head for a minute – one with the guts included – while I move on.
Skateboards
Second only to the animal fixation is the transport fixation, courtesy of the Lean world.
When discussing the Minimum Viable Product concept as espoused by Eric Ries in his excellent The Lean Startup you’ll find many variations on the following graph.
The Minimum Viable Product (MVP) helps entrepreneurs start the process of learning as quickly as possible.
Eric Ries – The Lean Startup
The concept here is that the first product produced is not perfect, nor should it be. An organisation, and particularly a startup, needs to explore the problem space by producing something that allows the organisation to quickly gather feedback. It’s an engine for the Build – Measure – Learn cycle advocated in the book.
In the most often cited example, the startup is trying to to break into the heavily populated lean startup transport market, and don’t want to jump immediately to designing and building a car, which is an expensive proposition. The approach, which leads to the above graphic is to start with a skateboard, evolve to a scooter when more feedback is received and then progress to a bike, a motorbike and ultimately a car.
It’s a nice clean model that captures the iterative, evolutionary process quite neatly.
So, similar to the Sashimi approach, the organisation builds the MVP, gets feedback, adjusts and produces the next iteration.
The Problem with Fish and Skateboards
So whether you came looking for a salmon, and ended up with a slightly messy salmon steak, or came looking for a car, and ended up with a skateboard, the concept is similar: produce something that satisfies the customers needs with a minimum of wasted time, money and resources.
Having adroitly drawn the connection between fish and skateboards, we must now look to one of the most common pitfalls of the application of these approaches.
Both models suggest that every aspect of the product being developed can simply evolve, that somehow the desired outcome will naturally emerge. The result, if carelessly applied, can be something akin to Homer Simpson’s car design:
The fundamental error is the appropriate application of what these methods offer. Both are dealing with learning more about the problem being solved, but in different contexts.
While products developed using the Sashimi approach are intended to be put into production, MVP solutions are only meant to be used to gather enough information until a full understanding of the problem domain has developed. The implication of course is that the MVP is entirely disposable.
Let’s take a moment here to reflect. How many times has your organisation, or maybe even you, proposed taking a Sashimi approach to building an MVP, when in fact there was no intention of throwing the result away?
For Sashimi to work, there must be a guiding set of principles in place to ensure that, for all that we may not build out the full architecture up front, we at least have a very clear concept of our boundaries. I’ve more to say on Architecture in one of my earlier posts.
Every slice, every iteration, must get closer to the customer’s desired outcome, but it can’t be building a legacy of problems while getting there because this approach is not intended to be disposable. Thus you are not building an MVP.
The MVP, which looks very similar on the surface, does not carry this baggage because it’s not meant to live that long. Once you have learned all that you need to learn, you must produce the production version.
I’ve rarely heard anyone who has proposed an MVP approach clarify that it will be thrown away in favour of developing the production solution. Despite what all of the friendly graphics present, there is really no way to leap a production architecture from a skateboard to a car without at least one re-write.
An MVP is not an evolutionary approach to a bigger production solution. You are ignoring the complexities of production grade resilience, reliability, scalability, security and a host of other factors in favour of speed with this approach. These are things you shouldn’t later try to retrofit into your production solution.
I often think about it from the customers perspective; a perspective I encourage everyone to take. Your customer has asked for a car, but you take the MVP approach. At the first demo, the customer is expecting to see something vaguely car-like, and you present… a skateboard. Is the customer delighted?
If you’re going to build a car, then start with a plan to build a car and then take the Sashimi approach to its development. If, on the other hand, you don’t exactly know what you’re going to build, take the MVP approach. When you understand what your offering to the market is going to be, build the production version.
I’ll leave the last thoughts on this to Eric Ries who discusses the origins of Dropbox in his book. He tells the story of Drew Houston co-founder and CEO who was trying to get backing for his idea. He couldn’t build a prototype; it would have been too expensive, and too time consuming.
Drew took a different approach, and produced a simple three minute video demonstrating the concept, and got his funding. Dropbox had revenues close to $2bn in 2020, based on an MVP that was a video. The video, for those of you who are interested, was never released into production as a first version.
This is the MVP you want to build. The one that communicates the concept, elicits feedback, and does so with a minimum of cost and effort.
Support Ukraine
The invasion of Ukraine is an act of aggression that we should all oppose and speak out against. I will continue to Stand with Ukraine and its people until peace is restored.
Photo by Ivan Samkov from Pexels
Lean icons by DinosoftLab from NounProject.com
Bows and Arrows 