If you choose agile – you need a good story

There can be no doubt that there is a perspective that adoption of the agile software development methodology is the popular choice of most organizations these days.

However if your organization is vested in a waterfall approach to development and there is no compelling reason to switch to agile – why would you do it?

There are two elements around “story” in the Agile development methodology. Making a switch from the more traditional product development methodologies to leaner and “agile” ones, requires a good justification – a good story for the purposes of rationalizing the transition or staying with the status quo.

A good story around the switch should aim to win the hearts and minds of not only the proponents of the Agile Product Development methodology but also the product team itself. The developers too. In fact, anyone who may be vaguely interested in the methodology that is being applied to software or product development – like perhaps the investors?

 

Within the  Agile Methodology – there is also the concept of a “user story” but I will talk more on that another time.

 

My opinion is that most people who are involved in the creation of physical and digital products genuinely want to be agile and don’t really much care about the methodology as much as they care about being efficient and effective in the creation of demonstrable results – being leaner in the approach to product development implies getting something built faster and with less effort. This is effectively an integral part of the agile manifesto.

Having worked in a number of industries and roles, but predominantly in the digital world, on all sides of the equation, as a product manager, a product owner, a product designer, a product developer and a product consumer I feel somewhat qualified to comment but of course, one’s knowledge is never absolute and every day one learns or discovers something new – especially if one is receptive to feedback, dialog, and debate.

Is it what you say it is?

One thing I am pretty confident of, though, is that just because you call what you do, something. That doesn’t mean that that is what it really is. I might, for example, say that I am an ‘excellent’ parent and a disciplinarian. But what does that really mean? In the end, only one of these three attributes that I ascribe to myself is almost certainly true. I am a parent.

So returning to the concept of “agile product development” – while I might subscribe to this particular methodology – what I really subscribe to is the notion that product development should be undertaken with agility as the focus. There is a difference.
Agility, in my book, means principally being able to easily and quickly respond to a needed or proposed change in the characteristics of the product to meet the demands of the market or audience for which it is intended.

If an agile product development methodology underscores and supports this desire for agility, then good, I am all for it. If it simply makes me shoulder process overhead – it failed.

Agile means, having a conversation

There are many attributes related to an Agile Methodology that accelerate the development lifecycle from concept to product. Among these aspects, there is the concept of lightweight requirements definitions – made up of themes, epics and stories and the interminable backlog but there is also the idea of short development cycles – sprints.

“Sprints” in the context of the Agile Methodology and in the Agile:Scrum Framework incorporate periodic “meetings of the minds” in sprint planning sessions, daily scrums, sprint reviews and sprint retrospectives – all aimed to provide all stakeholders with insight into progress, challenges, and blockers.

Having these meetings regularly, even if they are just of a five-minute duration, with all interested parties, involved, means you don’t land up with a shocking surprise at the end of the development cycle where designers and developers are frustrated and product managers and product owners are disappointed. The important thing is the free flow of dialog and feedback.

More dialog – less rework – that’s a lean principle and a six sigma principle – eliminate the waste!

Creating the Minimum Viable Product

Another concept that is often used in the same breath as an agile product development methodology is the Minimum Viable Product or MVP.
To my mind, this is a sorely abused descriptor. Often I think, things get called MVP’s when they are nothing more than proving models or proof of a concept – these may be incomplete architecturally.  in my opinion, if it doesn’t adequately address the market requirement it is not an MVP.

If you’re creating something from scratch or just a concept to show prospects and interest parties – is this really ready for prime-time – is it something you really want to put out in the wild and have to support, maintain and service?

As has been said elsewhere, a proof of concept or POC is there to validate that something can be built. MVPs validate that something should be built. POCs test feature validity, MVPs test market viability.

Back in the day I recall working with a phone circuit designer to create a switch that would do an off-hook dial automatically. It took several iterations before we created what we wanted. Every week I would get the prototype in a bubble wrap envelope, hook it up to my gear and test it. When it got to a level of prototype maturity that I felt made it good enough, we produced a few hundred units – those were MVPs.

The end-game was to consider how to integrate that piece of circuitry into a larger piece of hardware that didn’t have this little widget as an add-on or better still – avoid a circuit based approach altogether and move to something entirely a software digital switch that would work with VoIP.

Our end objective was digital all the way and this was simply a transition piece.
I do wonder, whether existing products that get re-made or rearchitected – can really be called MVPs though. You could argue that an existing product is an MVP already and the shiny new version is a different MVP but in reality, if you don’t plan to do any new major investment in expanding appeal or broadening the market relevance – why are you doing this? It is an interesting challenge.

The objective of any MVP, to me, is to help you determine where to make your next investment, I don’t think it should be considered as a mechanism to coerce existing customers to part with more shekels unless the value proposition is considerably greater. I think this idea is especially true if you release a product that doesn’t even have all the capabilities of your legacy product.

Consider why would a customer really consider making the switch to a new product?

I do think that MVP’s can help you in understanding your product development methodology mindset, though. If nothing else, an MVP perhaps helps bring clarity as to whether your product development methodology really is agile or not.

So when someone asks you what you think of agile as a development methodology, hopefully you have a good story.

A good enough story that helps you decide whether it is really actually conceptually important or whether what you’re really looking for, is just a better way to think about and develop new products.