The ‘How’ of Scientific Development
Uncertainty Required
The technique focuses on questions to answer over things to do. It’s fundamentally different than other techniques because it demands uncertainty. If you know the answer, then there is no hypothesis and there is no learning. You need to go back and form a new hypothesis.
Even when an opportunity is put in front of the team, the idea is not to think of ways to pursue it. The goal is to think of the things we need to learn in order to know how to properly pursue it. Our roadmap to fulfilling that request, then becomes the pursuit of those answers. Once those answers are proven, we’ll have also addressed the opportunity.
The Derivation – Opportunities, Issues, Hypotheses, & Questions
In principle, you only need to use hypotheses for this technique. However, there may be many scenarios when you don’t know how to arrive at a hypothesis, are concerned that you have missed some, or aren’t certain how to start (dis)proving it.
Below is the logical breakdown for how we would get started with scientific development if we were unsure and wanted to be thorough.
- Opportunity
- Issues Tree
- Hypothesis
- Questions
- Hypothesis
- Issues Tree
Opportunity
[…] have a chance
for […]
when […]
If we’re looking to paint a complete picture, we should start with our opportunity statement. The example format is useful in how it captures the essence of the need.
It lets us know for whom we’re pursing the opportunity (who has a chance?), the benefit for which we’re looking (for), and any critiera that helps limit scope (when).
Issues Tree
How can we […]
Once we have our opportunity, we can create our issue tree. This is a list of complications, problems, uncertainty, and anything else that may interfere with fulfilling the opportunity set before us.
Each issue may have sub-issues, and those may also have sub-issues. Thus, we create a “tree” of issues that form the complete set of obstacles between us an fulfilling the opportunity.
These issues should be consistently written to be a “how” question. Sometimes, “why” may be used, but that syntax is more common for diagnostics rather than creating solutions.
Lastly, the tree should be as exhaustive as possible (so we understand the opportunity and obstacles as completely as possible) and mutually exclusive (the same issue should not occur in multiple locations in the tree).
Hypothesis
Can we […]
By […]
For […]
This is the core unit of scientific development. The others act to support creating or acting upon your hypothesis. Although they are useful, they are not required.
The purpose of our experiment is stated first (‘can we’). The idea we will be testing is stated second (‘by’). Our last clause is optional. If your hypothesis will benefit from being restricted by some context (certain people, types of data, etc.) then that would be captured by here (‘for’).
Questions
Questions require no standard format as they may take innumerable forms. However, these questions act in the service of a hypothesis. As such, they can be open ended and result in any type of answer.
If all these questions are answered, then your hypothesis should be either proven or disproven. If you find that after answering all your questions you still don’t have a valid proof, then figure out what questions remain must still be answered.
Due to the nature of these questions, if you were to use a SCRUM-like process for scientific development, these would be like your tasks or sprint backlog items. Every day you should know which questions you are going to try to answer, and how many will then be left to answer within the sprint.
As such, you should likely refrain from drafting your questions until you’re getting ready to test the hypothesis. There’s no telling what you’ll learn or what will change between now and then, which would require you to draft new questions.
Refine & Repeat
Overall, the backlog should begin to reflect the picture of all barriers between yourself and your target conditions. Your sprint work should result in gains toward that state or new ideas for how to get closer. Every day, you’ll be finding answers that get you closer.
Won’t this be slow?
Maybe. It certainly won’t be predictable, and that’s the point.
It’s been found that a focus on running a team like a machine and having a bias for action are two great ways to ruin innovation and make sure your organization isn’t learning or improving. Thinking takes time. Reflecting requires not doing. As said by Lao Tzu:
We mold clay into a pot,
but it is the emptiness inside
that makes the vessel useful.
We may need the clay of the pot like we need hours of time engineering solutions. However, it is in the time that we’re not driving single-mindedly toward solutions that we enable ourselves to experiment, learn, and grow.
Read On
The ‘Why’ of Scientific Development