Software platforms that don’t evolve over time or stay up to date with current digital trends are at a disadvantage in the global marketplace. Because of this, many developers are implementing more adaptive tactics into their building process. The resulting method, commonly referred to as Agile, is best understood through the “Skateboard to Car” analogy.
Discover why Agile matters through the “Skateboard to Car” analogy:
The above image, originally conceived as a way of explaining Agile in a nutshell, went viral and even landed itself in the book “User Story Mapping” by Jeff Patton. Though a somewhat broad characterization of the method, it remains a helpful metaphor that demonstrates why developers and software purchasers alike should invest in a solution that grows alongside an organization over time.
Avoiding the Waterfall Method
Is there an alternative to Agile? When it comes to delivering a software platform, there's also what's dubbed the Waterfall Method, also referred as the Big Bang Method. In his blog post explaining the difference between Big Bang delivery and Agile, the image’s creator Henrik Kniberg had this to say:
“Many projects fail badly because they do Big Bang delivery (build the thing until 100% done and deliver at the end). I’ve lost count of the number of failed projects I’ve seen because of this [...] However, when Agile is presented as an alternative people sometimes balk at the idea of delivering an unfinished product – who wants half of a car?”
He’s not kidding about the failure rate either. The 2015 CHAOS Report by the Standish Group stated that only 14% of projects where the Waterfall method was used were successful. Subsequent CHAOS reports have continued paint a similar picture, anointing Agile as the approach one must use to adapt to ever-changing customer requests.
Forget About What You Thought You Ordered
Agile detractors are those who believe you don’t need those in-between steps (i.e. - multiple deliveries and/or updates). They only see a partially finished product as "not getting what they ordered." When they finally receive the full version - in this case, the car at the end of the journey - they may still be annoyed that they were made to sit through additional software development stages before being handed the keys.
Think about it this way though: if those intermediary steps were ignored, a car would still be delivered to the customer, but they’d be getting a model that hasn’t undergone any testing, any security checks and, most importantly, was made without considering the client’s unique needs.
"Skateboard to Car" Metaphor, Explained
The "Skateboard to Car" journey is a multi-stage metaphor that conceptualizes the values at the heart of Agile development.
As a first step, the skateboard is admittedly not ideal when compared to what the final product will eventually be. That said, it's at least a small improvement over having nothing at all. It has wheels and can get you places faster than if you had to walk. Through general usage, the customer may praise the increase in speed that the skateboard provides but he or she will also likely point out how unstable it is when you're trying to get around. Developers can take this feedback and use it to construct the next version of the software solution: the scooter.
As a sequel of sorts, the scooter is a welcome substitute for the skateboard because the customer can get around with added stability, thanks to the handlebars. However, one major drawback is that this mode of transportation lacks speed if you're travelling long distances.
The solution? The bicycle, which is the midway point between skateboard and car. It's a significant upgrade in terms of speed and mobility, making the bicycle option one that may impress the customer more than anticipated. In terms of functionality, they may roll with this iteration of the software without even waiting for the car.
On the other hand, maybe the purchaser wants even more out of the platform. Therefore, the next step is to add an engine, giving us a motorcycle. Similarly to the bicycle, an obvious deficiency is that there’s no roof over your head to combat inclement weather, which leads to the final of five possible stages: the car.
At this point, your customer will have a fully-fledged piece of software that should meet all of their needs and wants. Better still, the car is more robust and loaded with tons of intricate features that he or she would never have received with a cookie-cutter alternative delivered the product using Big Bang methodology.
Agile = Incremental Improvements
If you're a development team using Agile, the goal is to deliver a software solution that is tailored to the administrators and their specific desires, be it for increased speed or optimization for mobile. Regardless, each new update is seen as an Incremental Improvement, all of which are based on feedback that the developers receive.
The customer may not be entirely happy with the first version of their software application; the important thing to keep in mind is that those feelings are fine. Both the customer and development team members should be focused on learning from an honest dialogue about the project at hand, rather than wasting large amounts of time on enhancements that the purchaser doesn't care about. He or she still wants that car but, in the meantime, they’re already using your current build of the software and should actively be giving the developers feedback based on what’s working for them and what’s still lacking.
What Does the Metaphor Mean for Me?
The moral of the story behind the "Skateboard to Car" visualization of Agile development tells us that starting small doesn’t mean you can’t be thinking big when it comes to long-term solutions. Kniberg brings up Spotify as an example of how Agile can work wonders for a platform’s user base:
“As a startup in 2006, Spotify was founded on some key assumptions – that people are happy to stream (rather than own) music, that labels and artists are willing to let people do so legally, and that fast and stable streaming is technically feasible. Remember, this was 2006 when music streaming (like Real Player) was a pretty horrible experience, and pirate-copied music was pretty much the norm. The technical part of the challenge was: ‘Is it even possible to make a client that streams music instantly when you hit the Play button? Is it possible to get rid of that pesky ‘Buffering’ progress bar?’”
The debut version of Spotify - their skateboard - wasn’t glamorous, but clearly, it didn't stay stuck in that position for very long. How? Open communication and actively taking feedback greatly improved each new update and helped the platform adapt to new changes in the tech landscape.
The same story should apply a software solution that you're thinking of investing in for your organization. If the Spotify example proves anything, it's that software built using Waterfall methodology wasn’t created with your company in mind. Solutions made with an Agile mindset are far more likely to conform to your specific wants and needs, leaving you with a more satisfying user experience overall.
Want some more insight that will help your business become a winner? Download our free eBook with 10 marketing tools you can use to grow engagement and revenue today!