The Exploratory lifecycle is based on the Lean Start-Up principles advocated by Eric Ries and improved with strategies for complex adaptive systems from Cynefin. The aim of this lifecycle is to minimize up-front investments in solutions in favor of small experiments that are market tested and measured early and often during the project. As the solution is being developed, the delivery team has the opportunity to deliver what is truly required based on feedback from actual usage.
Figure: DAD’s Exploratory lifecycle (click to expand).
How This Lifecycle Works
Now let’s describe how the Exploratory lifecycle works. There are six activities to this lifecycle:
- Envision. Your team will explore the idea and identify one or more potential implementation strategy for implementing it. This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper. You want to do just enough thinking to identify viable hypotheses for what your customers actually want. These hypotheses need to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
- Build a little. Your team should invest just enough effort to build potential solutions that test each hypotheses. In lean parlance you want to build what’s known as a minimally viable products (MVPs). The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypotheses.
- Deploy. The each MVP is ready it is deployed into an environment where you can test how people interact with it. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
- Observe & measure. Once each MVP is being tested you want to determine what aspects of it, if any, are of interest to your user base. To do this you will need to instrument your MVP so that it logs data regarding important events within it. For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on. The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you. Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base. This in turn allows you to make a fact-based go-forward decision. If the functionality is well received then you may choose to continue with the existing strategy and add more functionality. Or your strategy may be so successful that you decide that you’re ready to productize the development of this functionality. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
- Cancel. Sometimes you discover that the idea isn’t going to work out after all. In fact, this is particularly common in research and development (R&D) environments as well as start ups. The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
- Productize. After several iterations of building a little, deploying, and then observing & measuring that you’ve identified functionality that will be successful in the marketplace (or in the case of internal application development successful with your user base). As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DA lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, and so on – and effectively treat the time they spent following this lifecycle as their Inception phase.
When to Apply This Lifecycle
The Exploratory lifecycle is useful in these types of situations:
- The solution addresses high incertitude cases such as a new unexplored market or a new product
- The stakeholders and delivery team are very flexible in adapting the solution as it is being developed
- You have one or more valid hypotheses/strategies to test with clear go/no-go criteria for when the test is over
- You are willing to experiment and evolve your idea based on your learnings
Get a Poster
Would you like a printable poster of this lifecycle? Disciplined Agile Consortium (DAC) members can download a printable PDF file. Not a member? Don’t worry, you can sign up for free.