In a previous post, we defined Lean Discovery as a set of tools and processes to deal with the inherent uncertainty of trying to determine what our customers want and need, and how the market and operating environments for our product will develop in the future. We achieve this by applying concepts like Lean Startup’s Minimum Viable Product (MVP) and Lean UX’s testable hypotheses to validate assumptions about the business value of a product or feature we’re thinking about building.
Still not sure whether your organization could benefit from Lean Discovery? Here are four signs that your organization should consider Lean Discovery:
1. Our Organization Regularly Builds Things That Don’t Impact Business Goals
We have all seen this happen – lots of money is spent, often over a great length of time, and yet when the dust settles, there doesn’t seem to be much of a positive impact on the intended goal. Or worse yet, nobody quite knew what the underlying business goal was in the first place. There are several underlying reasons for why this can happen. For starters, too many organizations don’t explicitly tie features or entire systems back to quantified business goals. Even if those are in place, it’s surprisingly difficult to determine how to create the right kind of impact – studies at Amazon and Microsoft show that more than 50% of improvement attempts had no positive impact on the desired metric and up to a third actually moved the needle in the wrong direction. The implication is that our intuitive understanding of what we need to do to “make things better” and unfortunately misses the mark more often than not.
How Can Lean Discovery Help?
Lean Discovery provides ways to tackle these issues by interpreting feature suggestions (aka “requirements”) as assumptions about how features contribute to business value, and running experiments using MVPs to test the ones most critical to the project’s success early on. Of course having a defined goal in the first place is crucial to drive a project towards success. The Lean Startup approach emphasizes this point by replacing the question “can we build this?” with the more important “should we build this?”
2. Projects Are Always Over Budget and Often Fail
Two of the biggest problems with the traditional waterfall SDLC are that 1) a development project can be considered to have made significant progress against plan without having delivered a single piece of a working system or application and 2) that validation of the underlying value assumptions is not available until the entire project is completed and presented to the end users. As a result, by the time unanticipated complexities and user feedback finally make artificially suppressed changes unavoidable, there is neither enough time nor budget left.
If an organization’s culture is very hierarchical and solution designs are generally driven by a HiPPO (Highest Paid Person’s Opinion), this becomes an even more significant problem, especially if there are no “safe” ways to provide objective feedback to decision makers. When questioning a value proposition is considered “not being a team player” and problems are an occasion for finger pointing instead of a joint responsibility, then “watermelon status reports” (green on the outside, deep red underneath) become the expected norm and projects resulting in long, drawn-out semi-failure seem inevitable. One outcome that we unfortunately see with disconcerting frequency in the federal government and similarly bureaucratic organizations, is that it is more advantageous for team leads to keep on pretending – and spending money – even after it becomes apparent that a system delivers little ROI to the intended users due to incorrect value assumptions and/or plain old quality problems.
How Can Lean Discovery Help?
Lean Discovery addresses these issues in a variety of ways. Regular and early evaluation of small vertical slices of an application by actual users, enabled by Agile development and DevOps delivery, provides feedback to validate value assumptions and allows for adjustments before it’s too late. By defining quantitative goals, it becomes possible to measure progress by evaluating impact – instead of just output in the form of completed features. This, in turn, means the project’s value proposition can be assessed objectively. Experiments are conducted on a small scale, so failure doesn’t have a significant impact on the organization as a whole. And finally, since work prioritization should at least in part be based on expected impact, the highest ROI towards the goal is realized early and the project can move on to the next goal once returns diminish, without unquestioningly burning through the entire budget.
3. Our Organization has a Hard Time Innovating
When there is any level of uncertainty about what customers would want or need and how that maps back to organizational goals, it usually requires several tries to hone in on the best solution. And yet, in many organizations, admitting uncertainty or “not knowing” is seen as a sign of incompetence and shutting down a project because it failed to achieve the desired results can be a career ender.
How Can Lean Discovery Help?
Contrast that with the mindset of a “learning organization” where failing fast and cheap using Minimum Viable Products is appreciated as a way to determine the most promising approach and avoid more costly mistakes down the road. By making experimentation an accepted and even required part of the process, Lean Discovery encourages a culture that acknowledges uncertainty as a fact of today’s operating environment – instead of someone’s personal weakness.
4. We Invested a Lot in Going Agile but it Didn’t Magically Make Everything Better
Assuming your organization has paid sufficient attention to the culture change required for Agile to work and is actually “being Agile” rather than just “doing Agile” – congratulations, you’ve made an important (and difficult) first step! So your development and delivery teams are cranking out high quality software at dizzying rates, and yet all this awesomeness somehow fails to move the needle on the things you really need to improve. How come?
Well, the issue may be that your organization has optimized “building the thing right” but not paid enough attention to “building the right thing.” Agile is focused on creating and deploying what is specified in the Product Backlog – how those items or stories get in there is arguably not in scope. Some people coming from the business side – product design, marketing, strategy – go as far as to argue that “Agile doesn’t have a brain” because they view it as a machine that cranks out whatever you tell it to.
How Can Lean Discovery Help?
Determining the “right thing” to build is difficult under the best of circumstances. Lean Discovery supports collaboration between the business and IT through concepts like Hypothesis-Driven Development and integrating Lean UX into the development process. Agile and DevOps are necessary in the sense that they enable fast and relatively cheap change to adapt and adjust based on what is learned from customer feedback, but Agile alone is not sufficient. Lean Discovery provides the additional learning loop that ties feedback on product changes back to the respective business goals.
What other organizational issues have you addressed with Lean Discovery? Share your thoughts and insights in the comments section.