Menu Close

Continuous Discovery – What is it?

In the last post, I talked about where the world of agile software development is and how we have all collectively ignored the question of value to end users and buyers. Not because we are bad people but because the question of value is fundamentally difficult to answer than the question of delivery.

In my role as the Head of Capabilities for ThoughtWorks India, I struggle with the exact same question. I can understand learning needs of the organization and take bets on how we might be able to fill the gap, but to measure the effectiveness of any learning intervention is very difficult. Especially when the skills in question are non-technical (like negotiation OR influencing, etc).

So most of the software industry has concentrated on how to deliver software continuously because it is easy to measure that and that’s a great platform to build on. The next frontier now, is for us to make sure that the software we are delivering is valuable.

Problems with the Discovery phase

As I mentioned in the last post, in most organizations, the question of value is left to the Product Owner and the common reaction is for them to do a “Discovery” before the development starts. That’s a step in the right direction but there are 2 problems with it.

Firstly, the result of a discovery is usually a roadmap of features that need to be delivered over a few months to an year. This means that the team is going to measure it’s success by whether they’ve been able to deliver on time according to the roadmap.

Secondly, and this is more serious, having a discovery phase sets the expectation with stakeholders (as well as the team) that the time for experimentation is over and the time for delivery has begun.

So what is Continuous Discovery?

In simple words, continuous discovery is an approach that encourages the team to keep experimenting throughout the life of the product.

It is a method that helps teams continuously evaluate the items in their roadmap for value, usability, viability and feasibility. This enables the teams to continue experimenting alongside delivery so as to incorporate real feedback into what they are building.

But rather than define this as a process, let’s use some observable behaviours that signify a team practicing continuous discovery.

  • The product team is measured on outcomes rather than output
  • The product team meets real customers every week where they conduct small experiments that help them move towards their desired outcome
  • The Product Manager, Designer and Tech Lead work closely together everyday
  • The team that does discovery is the same team that does delivery

And there you have it! It sounds simple but is extremely difficult to achieve. We’ll look at some hurdles in the next post.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.