Are you building the right solution?

I’m a real stickler for finding value in what I buy.  There are few times that I go for the “fancy trends”.  For instance, when it comes to cars, I want it to get me from point A to point B without fear of breaking down at a high level of comfort.  I want it to be durable, long lasting with the fewest visits to the repair shops possible.  It doesn’t need to be fast nor slick.  That’s my definition of value.  However, a good friend of mine loves fast and slick looking cars, even if that means a few more trips to the repair shop.  Clearly our definition of value is different and I shouldn’t have him choose my car for me and vice-versa.

This same values applies for the software people use.  Understanding the value of what you are building for your end client base (the users) is key to sustaining and growing your business.  In Agile, this takes on the form of the Product Owner who represents the end user.  Often, the best Product Owners are the ones that are also users.

However, getting input via one source is risky and when millions of dollars or more is invested in a new or updated product, you want to ensure that all that investment hits the right target.  Traditional Agile delivery methodologies don’t focus on further validations that the right product is being built.

Horror stories of companies of building the products and “no one comes”.  No “Field of Dreams” is automatically received.  Hope is no longer a strategy for success.

Dominant in the past up through the 1990’s and still often present today, the IT organization lead the construction of software and more times than not, the result was software the end users disliked or tolerated at best.

Then Business took on a more direct role with SME’s, the Product Owner or Product Manager and under Agile, that communication increased and now more quality software that end users liked has been built.  Today the majority of software development is led by a line of business (LOB), not Information Technology.  About time our workforce got there.

Projects are still failing

Still, over 15 percent of Agile projects completely fail and over half are challenged per the 2015 Standish Group study of over 50,000 projects[1], so things still need improvement.

Top reasons for project failure are:

• “Lack of user involvement”
• “Incomplete requirements” which is related to lack of user involvement 

I’ve personally witnessed recent projects that start off with business and IT alignment at the start, then IT is left with the product owner as the bottleneck and then the resulting solution does what was agreed on, but like the car example, the “durable car” was given when the “fast and slick car” was wanted.

The discovery path

So success for a project shouldn’t be restricted to just delivered software, but instead how well received and the end user feedback of the software.  There are many approaches to address this lingering gap, and one that is very effective is called the discovery path.

The discovery path is based on the lean principle of value stream mapping[2] and the ideas introduced by Jeff Patton called Dual Track Scrum.

The main concept of the discovery path is to hold sprints for determining that the right product is being built by have repeated sprints of reviews with the user community in parallel with the delivery path used in traditional scrum.

The discovery path includes several methods to validate your ideas with your target users as early as possible.  Examples include:

• Building an opportunity backlog
• User research/interviewing
• Story mapping
• Quick visualization design studio
• Detailed personas
• Right fidelity prototypes
• Key Performance Indicators (KPIs)

This falls under the marketing approach of an opportunity canvas that consists of pains, remedies, experiments, ideas and options. These will be covered in future blogs.

Carrying this out can be scalable, but certainly adds expense to the bottom line delivery of a project.  However, the value of building excellent software versus building good software can make your business an Uber instead of clone such as a Lyft or Grab.  Mobile solutions are typically excellent candidates for using the discovery path.  If your software only needs to be “good enough” and have limited budget, then implementing the discovery path may fit for you in only the barest approach.

In our industry of delivering value, clearly defining what “value” mean in the eyes of your users matters more than your definition of “value”.  Even as a user, assuming value is fixed and cannot expand and grow is an oversight witnessed in today’s software development world.  Get in lead of that world by connecting better to your users via the discovery path.

[1] Standish Group 2015 Chaos Report

[2] Value Stream Mapping