It’s hard at the beginning of an adventure to know what things might look like at the end. Often what we expect our endgame to be turns out completely different in reality. At least that’s my experience of life and software projects — including the taste of success.

I’m talking about a Frodo Baggins type of adventure. The ‘Quest of the Ring’ venture, rather than a mundane trip to the dairy (where there are no real variables to be encountered and the time to get there is short).

In Frodo’s quest to destroy the ‘One Ring’, success was the destruction of the ring — and therefore saving the world. A noble and huge quest indeed (three movies worth in fact!). But I’m pretty sure he didn’t know about all the turns and twists he would experience to reach his endgame. Or what his success would feel like at the end. He was jaded, tired and relieved at first — rather than triumphant. Not that our heroes need to be jaded at the end of their software development adventures… 8-)

The screenshot shown above is of the Gutherys Coach application. If I showed a picture of how we initially envisaged the app, you might only vaguely recognise it.

If, at the beginning, people have very specific ideas about the exact steps of the journey — it leaves little room for adaptation of what staff or clients want, think they want, or even what you think they want!. Or, for that matter, what the competition (Ringwraiths) might throw at you.

In software development parlance if you use a waterfall type approach, you have everything thought out at the beginning of the journey and locked down. There are some good things about this approach. And if you’re just traveling to the dairy you may not need agility, flexibility and the ability to pivot.

By taking a lean start-up approach using agile iterations, we can adapt to changing requirements. Or at least change our understanding of requirements with ease. Perhaps this is a better risk management approach than building the whole thing before you know you have built the right thing? If you’re investing hard earned money, having to start all over again is less than ideal (especially if you’re building something substantial). ‘Fail fast’ is the term we use for this.

Occasionally though, you get the feature right first time.

The image above shows an automatic display of a Guthreys Coach trip where the application calculates kilometers for automated quotes and billing into Xero. We got this right first time (ahem). Well, even here to be honest we’ve found that drivers might take slightly different routes than the application calculates for them. Which means people have to enable a manual over-ride to create the correct data.

We also added a feature where the application talks (via API) to the coaches themselves — to get accurate trip data and kilometers. But the reality was that these changes were not obvious at first, to us or the client.

In summary, I think using agile practices with a lean startup mentality is the best way to go on an adventure. That way if you ‘Fail Fast’ you’re only losing a little bit. And it’s not really failure if you’re learning by the exercise itself. That, my heroes, is true success.

‍