Category: Uncategorized

Scientific development is designed to mirror the unpredictability of the scientific method. Most organizations will have a hard time tolerating that. Others, like those in the pharmaceutical industry, may be able to embrace these ideas without difficulty. The primary barrier to using this technique will be from your organization. If teams have great autonomy, are self sufficient (don’t need others to get their work done), and aren’t driven by near term ROI decisions, then this technique is a natural fit. That probably is not your team, nor any other within your organization. However, you could still include a few hypotheses even if you work closely with many teams, must follow explicit standards, and have a scrutinized budget. But we’re a small shop and need to meet client deadlines to get by There’s a time to just get things done, but be mindful of that mode not becoming your only way of being. Perhaps you can try this technique, but on internal projects. Perhaps, you may even apply this to maintenance work as a way of critically reviewing how best to improve your products and services rather than just keeping them running or patching up bugs. But we’re in a large enterprise and need to work with others on large projects Be prudent. Be a good member of the extended team and do what is necessary to play nicely. However, that shouldn’t preclude the use of some hypotheses to ensure the team is growing and pushing themselves. Perhaps, there are even hypotheses related to your current project work whose answers may alter your trajectory. We understand our work; we do it all the time. Why bother with a hypothesis? That sure sounds like a good argument. It may even make you think that writing hypotheses would be a waste of that team’s time. Nothing could be further from the truth. If the team feels that writing a hypothesis is a waste of time because they know the answer, then they’re wasting their own time. Doing the same thing they’ve done before won’t result in learning. For a team of skilled people, there is no greater waste than to spend weeks, or months, or years of their life keeping busy and not really learning. In this way, taking the time to write a hypothesis may feel like wasted minutes, but it might just spare them years of wasted opportunities. What if they were forced to create a hypothesis? What would they start asking that would be testable, they do not know the answer to, and will be a growth opportunity? Maybe something like: Can we put ourselves in a position to do unique value added work By creating a utility that will allow our clients to do for themselves what we have traditionally done for them? Can they? I don’t know. But they’re sure to learn a lot for the effort. So, everyone should do this? This technique (like any agile practice) is a tool that can offer certain advantages or help solve certain problems. If you don’t have those problems or don’t want those advantages, then look elsewhere. Should my my team consider this? Do you want a team that is collectively supporting each others’ growth? Do you want team members to see how what they’re doing today is building skills and knowledge for tomorrow? If those sound like things you want, maybe it’s time to run an experiment. Are there symptoms that should encourage me to try this? Do you have tools for tracking team member growth that are independent of the work being done? Do people feel as though work is interfering with their growth & learning rather than work being the engine of growth & learning? Do people look back over the year and see all the stuff they did but are unsure if they’ve really grown or developed at all? If those sound familiar, maybe it’s time to run an experiment. Try to formulate a hypothesis and put it to the test. You may just learn something. Read On The ‘Why’ of Scientific Development The ‘What’ of Scientific Development 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 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 The ‘What’ of Scientific Development The ‘Who’ of Scientific Development