Have you ever found yourself wondering if the product or feature you’re working on really provides the most value to your customers? Maybe you’re not sure why the output your Agile team creates from the Product Backlog just doesn’t seem to have the impact on your organization’s goals you expected? Or why halfway through a project it feels like you’re scrambling to finish something that is somehow at the same time urgently overdue and yesterday’s news? It sounds like you might need to look at Lean Discovery.
What is Lean Discovery, you ask?
In short, Lean Discovery is used to maximize business value from IT initiatives through systematic, adaptive determination of “the right thing” in the face of uncertainty about project risks and customer expectations.
So, what does this really mean?
1. Lean Discovery focuses on solving the right problem and achieving business value.
Many methodologies focus on how to build things right – faster, cheaper, and with higher quality. Lean Discovery supports increased productivity by eliminating waste, primarily by helping teams to build the right things in the first place. The Lean Discovery process drives Product Owners and teams to continuously examine the business value of their product based on feedback from the customer. At the end of the day, what you build is still more important than building it well and fast.
2. You should never assume you know what your customers really want.
One of usability’s golden rules is “you are not the user.” In many cases, simply asking users about their requirements doesn’t produce a complete picture of their needs. It’s rarely easy to get access to the right users and people are generally much better evaluating a product that has been built than stating needs or preferences in the abstract. Lean Discovery relies on the “build-measure-learn” loop to validate assumptions and learn from users’ feedback once they have had a chance to see a real product. That “product” doesn’t always need to be a fully functional system or item – in fact, the goal of Lean Discovery is to learn as quickly and with the least investment possible. The idea of the “Minimum Viable Product (MVP)” is to build or do the smallest thing that can be put in front of customers to get feedback on whether the project creates actual value.
3. Keep calm and acknowledge uncertainty.
It may be difficult to get a complete understanding of what your customers want right now, but it’s impossible to reliably predict the future, especially since technology, customer expectations, competitive pressures, regulations, etc. are constantly changing. And yet in most cases, organizations commit significant resources for long periods of time based on assumptions and predictions about expected outcomes. Even worse, once committed, progress reports are notoriously optimistic until the final reveal, often at the bitter end.
Lean Discovery provides a process and tools to identify those project assumptions that are most likely to lead to failure if incorrect. These could be related to customer adoption and profitability, but also about technical constraints like interoperability or performance – a lesson the federal government learned the hard way with healthcare.gov. Stated as hypotheses rather than requirements, these key assumptions can then be tested early using an MVP before the entire project budget and timeline is used up, providing an important contribution to risk management. In every complex environment occasional failure is inevitable, but validated learning often allows for projects to be adjusted towards value creation. Even in the worst case, it’s far better to fail fast on a small budget than to find out at the end that all those resources didn’t produce any real value.
4. Sorry, we don’t know the exact scope just yet.
Many project teams take scrupulous care of defining thorough requirements before beginning a project, usually based on what was promised in the business case. Business stakeholders know that this is the only time they can provide input, so they request anything they can guess they might possibly want. As a result, many things that get built turn out to have very little actual value to anyone. While every project aims to stay inside the “iron triangle” of cost, schedule and scope, few succeed due to this institutionalized incentive to overload. Lean Discovery’s emphasis on experimentation and validation, in combination with the iterative and adaptive development approach of Agile, allows the organization to focus on delivering the features with the highest business value at the current time and adjust priorities when the relative value of some element of the anticipated scope changes due to user feedback or external factors. As a side effect, this approach encourages a culture of willingness to admit that we don’t know everything upfront and that everyone is wrong from time to time (even the HiPPO) – both crucial ingredients for fostering innovation.
5. Lean Discovery is not the same as Agile or Scrum.
The term “Lean Discovery” often gets thrown into conversations alongside “Agile” and “Scrum,” but it’s not all the same thing. To enable fast and (relatively) cheap learning from actual end user feedback, development needs to create a working product quickly, and that pretty much requires Agile and DevOps. Rather than being content with producing “working software,” though, Lean Discovery builds on that development capability to validate the business value and impact of the latest product or feature iteration. In short, Agile and Scrum will deliver a product in a more efficient way and Lean Discovery will make sure it’s the product you want.
6. Lean Discovery is not something the IT folks can do on their own.
Unlike Agile, Lean Discovery doesn’t focus on improving delivery by the development team. Rather, Lean Discovery extends the Agile feedback loops back to the Product Owner and business stakeholders. This ongoing “reality check” helps to ensure that items are prioritized in the Product Backlog based on the highest business value, that development moves on to the next thing when “good enough” is good enough, and that development resources are redirected as early as possible when a project turns out to be not feasible or fails to materialize the expected impact.
Have you tried a Lean Discovery approach? Do you see a use for this in your own organization? Share your thoughts in the comments below.