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, 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 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
Quick visualization design studio
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.
Michael Dougherty is a seasoned agile practitioner and trainer with more than 12 years of experience, and he has been bringing “order from chaos” as an IT consultant for more than 24 years. As the former vice president of the Agile Leadership Network in Houston, Texas, Michael has a passion for process and has spoken on several topics, including technical debt and agile checklists.
Michael is currently the national project manager at Magenic, leading a massive training program for the company's offshore and delivery center consultants.
The opinions expressed in this blog are those of Michael Dougherty and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.