“Fresh Air, Deep Dive” is Jonah Group’s new public-facing newsletter, and this is the first issue! We highlight a current topic of conversation in the software industry and how it may impact you, as well as to give you an update of what’s happening at Jonah.
Welcome to issue #4 of Fresh Air, Deep Dive 🐳 — Jonah Group’s monthly newsletter, which highlights current topics of conversation in the software industry and how it may impact you.
In the last issue, we discussed how Agile sometimes means "slower and more expensive." In this issue, we take a look at the consequences of the "Sprint" mentality, and consider an alternative to the Minimum Viable Product (MVP).
“Jonah Says” Stop Sprinting— Your team is going to burn out!
Better than the MVP — What's missing from the “Minimum Viable Product?”
Resources — Suggestions for further reading
“Sprint” is another word from the Agile world that could be improved. The word “Sprint” implies that the team is moving at a frenetic pace for a short period of time in order to achieve a goal. We all know there is no shortage of goals; every subsequent Sprint will also have one!
Products keep evolving. Can a team "sprint" toward the deployment of one product increment, sprint toward the next, sprint yet again, followed by… you get the picture. No of course they can’t, at least not without a painful and debilitating lactic acid buildup (burnout) over time. Sprinting throughout a race with no end isn’t Agile – it’s just a downward spiral.
"Jonah Says" Tip #1: Stop Sprinting!
Software Engineers need time to restore creative juices, to reflect on team processes and design choices, and most importantly to address technical debt. Debt is the set of hidden gremlins or ghosts in the machine that only surface long after a project has been delivered, cheques have been written, and the champagne from the delivery celebration has run dry. Technical debt is the spaghetti code that is brittle to change, is not properly factored, is difficult to operate and manage, is not commented well, contains few unit tests, does the job but performs poorly, and is a teeming heap of anti-patterns. And no this doesn’t mean your development team isn’t capable. This will happen to any codebase without the proper attention and safeguards.
All of this is why Jonah says “Stop Sprinting!” Or at least stop using that word to describe the iterative Agile process. We suggest the terms “iteration” and “product increment.” These implicitly evoke notions of a more humane pace over the long term, while still embracing and enjoying the benefits of iterating.
Let’s not inadvertently set expectations too high for our product owners. Set aside an iteration every now and then to deal with technical debt. Track velocity from iteration to iteration, and study how to improve this over time with structural improvements (as opposed to simply "having higher expectations"). Finally, develop themes or sprint goals more fully to contextualize the importance of "going fast" when it's needed, but be sure to remember that everything can't be an emergency!
The “Minimum Viable Product” (MVP) is one of those ubiquitous software terms that everyone seems to use when referring to version 1.0 of their system. While the MVP is generally the first customer-available version, we should all remember why the MVP is an important artifact. It’s right there in the name, really:
MINIMUM. Since it’s small, the lag time from project start to customer feedback is constrained. Bringing a large and expensive offering to market increases the likelihood that a lot of money will have been spent by the time users first see it… and summarily hate it.
VIABLE. This idea is that the MVP has some value on its own, albeit perhaps small, to the user base. The thought is that that they will experience this value in a real way, even if there is much more to come.
PRODUCT. The MVP represents a vertical slice through the product’s feature roadmap. As such, every layer of the architecture is exercised by the time the MVP is complete. Every SDLC process used to move from concept to production has been exercised at least once before the MVP is live. Users can use it. The MVP is really thus a product all on its own
One of my longstanding clients and I were recently chatting, and he said his team had instead adopted the phrase “Minimum Lovable Product.” I pondered for a moment and the lightbulb went off. I’ll admit to never having heard the phrase before, but a short search later it turns out that — like every other seemingly creative epiphany one might have — this is not a new concept.
Will your MVP generate customer love?
While ticking all of the boxes above, too often the MVP ends up being underwhelming to the user. “Is that all there is?” they ask themselves. Drawing a circle around the minimum scope is a tough tightrope to walk. You don’t want to go overboard spending money and including features before validating them with the market, but you also need to make sure that the gems you deliver do sparkle.
Beyond a self-contained product above the minimum valuable threshold, stakeholders should also consider what version of the product will evoke surprise and delight in their users. Change is hard, and you only get one chance to make a first impression, so your MVP also needs to invoke a deeper affinity with the product in order to get the prospect to accept change.
Lovable products increase the acceptance of change.
When designing your first version, make sure to include a delightful core feature that will get your users talking and their hearts beating. To select these core features, don't simply rely on your own intuition; ask a partner to help you with user research, and solicit feedback from friendlies in your prospective user base to understand what will resonate.
When Frankie Beverly sang Love is the Key, maybe he was thinking of the MLP.
.png?upscale=true&width=240&upscale=true&name=output-onlinepngtools%20(5).png)
