TLDR: The skateboard, bike, car analogy is strategy, not a process. If there are any product owners out there that understand this, I want to work with you.
In arriving at my current opinions on all things software engineering I’ve found no better guiding light and yet no worse applied Agile concept than the famous: skateboard, bike, car analogy. The problem I believe is in its application(s). Whether that be due to misconceptions or a commitment to it as a fundamental principle I am here to set the record straight and describe what I have come to believe is the right way to go about things.
If we are committed to the core tenets of the Agile Manifesto (and actually understand them) then we have an objective standard to delineate the good from the bad. The core idea here is the trajectory we take as it relates to traversing the work required to be agile.
The core issue is that we are jamming the entire “skateboard, bike, card” concept into the development phase alone. Wrong! Instead we should be trying to define a set of requirements that can flow through all the phases without creating a bunch of side effects (you programmers know what I’m talking about). All too often we try to shoot-the-moon with requirements that do nothing but wreak havoc and wreck shop.
Let me illustrate, literally:
You see, we trick ourselves into thinking we’re being “agile” by merely doing Agile-like things. Agile is a strategy, you either follow it or you don’t. We all do work one step at a time and therefore we all break things down into a series of steps. We do that on a personal level as well as a team level. If the mockups, requirements and expectations we receive are sufficiently complex, we get formal about it. Often that means everything get’s jammed into the development phase. That makes everything an “engineering discussion” and things get blurry.
We all understand that we need to break things up into smaller deployable chunks but we don’t agree on how that should be done and that’s the crux of the matter. There are two ways to traverse, depth-first or breadth-first. My answer? Depth first. Always depth first. Shrink your MVP breadth-wise, until you have a self-contained vertical slice free of side effects. That may involve three steps forward and one step back on the next go round but in the long wrong it will be faster.
Let’s dive straight into how I envision the optimal process working:
Begin by defining your feature and estimate the sprints needed for its completion. If it exceeds one sprint, deconstruct your MVP into smaller, self-contained releases. Each release should be achievable in a single sprint and be ready for release.
Consider a scenario where your feature is projected to span three sprints, leading to three MVP iterations: r1, r2, and r3. Let’s not use the: skateboard, bike, car analogy as that’s not a very real world scenario. In the real world we morph things. Let’s use a moped, motorbike, buggy analogy. While r1 offers basic functionality (basic transportation), r2 is more usable (customer needs to travel on a 50 mi/hr road), and r3 represents the ideal version (much safer). Ideally, you complete r1 with essential backend integrations and preliminary frontend work. Although deployable, it might be initially confusing for users, so you might opt to feature flag the whole frontend. If you’re diverted in subsequent sprints and return later to r2, you can then finalize, demonstrate, and release it, providing customers with a usable feature. After four weeks, even if priorities change and customers are already using the new features, you can comfortably switch focus. When you eventually circle back to r3, a decision might be made to stick with the existing version for now (it’s summer, roads are clear).
In contrast, here’s a common, less ideal scenario: You start a feature estimated to take three sprints. The first sprint ends with a hodgepodge of backend and frontend elements, some in development, some in staging, and others pending various dependencies. Is it releasable? Nobody knows. If diverted for two sprints, you’re left with an incomplete feature (a moped with a gas tank in the front where your legs go, it’s a mobike) requiring complex feature flagging across different levels, maybe? Returning to the feature later you face continuity challenges and a patchwork of solutions (you now have a motorbike with moped wheels). This disjointed approach leads to delays (steering is terrible and don’t go too fast!), increased pressure from customers and product owners, and a cycle of inefficiency. When you finally refocus on the MVP after four weeks, you scramble to address numerous issues, culminating in a rushed release (a three wheeled buggy with moped wheels and handlebar steering with a mismatched breaking system) that fails to resonate with customers who now think both your product and your mind are delayed.
The End.
