We pick up the story where our protagonist and his able sidekick (aka Blake and EndGame) start the development of a cloud app to remotely manage Blake’s burgeoning fleet of coaches, drivers, clients and trips.

In any good story, the heroes are truly defined by their villain. In comic strip lore Wonder Woman has Cheetah, Superman has Lex Luthor, Batman has Catwoman etc. Then there’s the uber cool Dr Strange, who has a plethora of villains: Lilith, Loki, Nameless One, Xandu, Blackheart, Morgan Le Fay, Dracula, Umar, Shuma-Gorath, Dagoth, Nightmare, Empirikul, Mephisto, Baron Mordo, etc.

So in our story, who is the villain? Well, just like the mysterious Dr Strange, for software development projects any number of foes can rear their heads.

And the nominees for best villain are:

An “us-and-them” relationship between Customer and Supplier

Or, in our analogy, between the hero and his sidekick. Not that I’m old (sigh) but with more than 20 years experience in the software industry, I have witnessed this villain at work so many times. He’s a nasty one.

Like a marriage, good relationships require forgiveness, selflessness and good communication. Sometimes it means sucking it up and believing the other person knows what they’re doing — even when evidence might look different.

A division between people, groups or departments is hard to correct once it gets entrenched. And this tension isn’t conducive to outcomes that require parties to collaborate. Fostering a clear, honest, transparent and respectful working relationship is vital for the success of a project.

EndGame places huge importance on openness and collaboration between ourselves and our customers. To be a long-term development partner we have to be good at relationships. And with Blake (our hero), this is certainly the case.

An arbitrary schedule, completion or milestone date without any reference to proper effort estimates.

Or alternatively framed: an arbitrary budget without proper effort estimates. Yes, even in an Agile sprint there are time frames.

Hypothetically speaking, one might possibly see this predominantly where work is tendered by perhaps governmental types. Such as, say, when a tender states the high level functional requirements are X; the delivery is Y-n (where Y would be sensible and -n is the crazy number of days less than this you have to deliver!). Oh, and the budget is fixed. But we won’t tell you what it is. Now tender for the work. And if you win…(mwah ha ha ha ha!)

Thankfully this is not the case in our story. Our hero and sidekick worked through costs, requirements and deadlines together and communicated well throughout the project.

Wrong software development process.

While in my experience I’ve found that good people will deliver excellent results regardless (or despite) enunciated processes du-jour, SDLC, [insert desired acronym process here]. Yes, even using Waterfall there were some projects successfully delivered. Nonetheless, it’s possible to select a process that doesn’t fit a project.

Never fear. At EndGame, we’ve got appropriate mature software development processes, so this is not the villain here! Note: IMO even in “Agile” (whatever that means to you) where people are prioritised over process via the manifesto (is that a process?), there are processes. And therefore there’s the danger of serving the process rather than the desired outcome the process is supposed to deliver.

Lack of experienced technical lead, lack of budget, lack of vision, lack of engagement etc etc

These pests can plague any project, but again none of these were the villain in our story. Reviews of our work recently stated:

“[superhero] has engaged EndGame as their development partner, which has resulted in a robust and well-architected software platform.”

And “EndGame, is a reliable resource with sufficient capability and capacity to be a long-term development partner for a start-up business.”

The mysterious unidentified user.

Hmm. An interesting villain. And in all honesty, this invisible opponent did create the biggest challenge to the initial use of the app.

Yes, we made user stories, wrote epics and used cases etc. In a Lean Canvas world, the user is typically part of the solution of the canvas. And yes, we thought about this. Our hero (let’s call him Blakeman) was clear from the start that he wanted to create something that could be commercially exploited in the future. It wasn’t just for him, but also for others. We took this into account up front. Maybe too much.

We initially created a single workflow, intended to satisfy the original user, (Blakeman) and also those new to the software.

Unfortunately, all that “user friendly” stuff actually made the interface work too slowly for Blakeman’s trusty staff who knew the territory like the back of their hands. They didn’t need ease. They needed speed.

In retrospect, in Lean Canvas type thinking, we could have built the app for Blakeman first — rather than thinking about potential other users up front. Then we could have iterated. The reason I say this, is when we started to transition Blakeman’s data and staff into using the app, they realised that some areas were slowing them down.

This lead to some reworking — creating two ways of doing some things: the (thorough) easy to use way and the super fast way. Taking the Lean Canvas thinking further, we could have built the first iteration just for Blakeman, before thinking about users to come.

The story has a happy ending! The app works great. The villain is defeated. And the super hero and sidekick have learned a valuable lesson: Build for the first user and iterate from there.

Many years ago a wise person said to me “understand your user and you understand yourself”. OK. So maybe I just made that up. Perhaps that doesn’t make sense (or maybe Dr Strange would understand it). The point being, if you really know who your first user is, you can:

• make epics, user stories and user cases more tightly focused
• deliver quicker and cheaper and
• validate assumptions earlier.

Which will all help you to: fail fast to succeed long term.

‍