Tag: ThinkingProductionSystem

The ‘Who’ of Scientific Development

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

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

The ‘What’ of Scientific Development

The key is that our hypotheses are not deliverables. They are ideas seeking validation. This twist has important ramifications for how we end and enter sprints. At the end of a sprint, we can look at what we’ve done and for each hypothesis we can say: “yes” or “no”. Our planning is about what we will learn, rather than what we will do. “No” – We Didn’t Fail, the Hypothesis was Wrong By focusing on what was learned, scientific development tries to make “failing” much safer by changing what it means to fail. Today, failure is not delivering a solution. It sounds and feels like the team didn’t work hard enough, didn’t estimate accurately, or otherwise failed. This becomes a feedback loop that discourages risk taking and discovery. Ramifications for this feedback are obvious and very likely all around you. Concerns are about planning, estimation accuracy, faster execution, and more specialization. With scientific development, ending a sprint where a hypothesis results in a “no” is merely disproving the hypothesis. The hypothesis was wrong. Our technique was likely fine. Our work ethic was fine. Our idea was the thing that was wrong. In fact, in many ways this is a highly desirable outcome. For every “no”, we should have an in depth review of how we arrived at the hypothesis, how we tested it, and our results (code and all). This review will offer innumerable learning opportunities for those exploring the hypothesis while building the coaching skills of the team. Despite that, when we arrive at a “no”, we should use our learning to create a new hypothesis, which we can test in a subsequent sprint. The only outcome that does reflect poorly on the team’s performance, is when they don’t know the answer at the end of the sprint. “Yes” – Doing to Learn > Learning to Do With all this talk of proving a hypothesis and repeated hypothesis refining, you may be concerned that the team will spend all of it’s time thinking rather than doing. Those are fair concerns and can happen. They can also happen when writing stories or even in a classic waterfall project. Ultimately, it becomes a matter of facilitation. Proving a hypothesis is not a matter of citing a question on Stack Overflow and saying “yup, I saw it on there”. Proving a hypothesis means providing a working solution that definitively proves the hypothesis in the proper environment. If it’s starting to look as though proving your “yes” or “no” can involve a great deal of work, then good. It can. That’s the point. Scientific development is not about doing less, it’s about optimizing the people rather than the work they’re doing. Planning – A Different Conversation Sprint planning would also take a subtle, yet important shift. Most sprint planning looks at what needs to be done and ask who is best suited to do it. When we’re looking at which hypotheses we want to test, the question is less about “who wants to get this done?”, and is more like “who wants to learn this?”. That is a small, yet critical shift. The very nature of sprint planning could be pivoted from being a conversation about what we will do and turn it into a forum for helping people develop the skills they want to acquire. It could be the first step in unifying the act of work planning and team member growth. Of course, the convention alone won’t be enough to completely unify these things, but that is not the point. It’s a tool to assist you in becoming professional learners and experimenters rather than coders. It also takes learning and growth out of one-on-one and annual reviews and makes it part of the sprint process. Because planning is a team activity, this also means that everyone on the team will know what each other are learning and how each other are growing. This makes it possible for the entire team to support each others’ professional growth, rather than leaving that to leaders. In some ways, the team can’t help from doing that. If the team deeply reviews and offers feedback on all “no” results, then there is no escaping team members being perhaps the greatest asset to each others’ continued learning and development. Read On The ‘Why’ of Scientific Development The ‘How’ of Scientific Development The ‘Who’ of Scientific Development

The ‘Why’ of Scientific Development

Can we use our backlog for professional growth by tracking and talking about what we want to learn? Stories are nice, but… As an agile coach I’ve spent a lot of time teaching and helping people practice writing stories in the classic format “As a […] I Want […] So That […]”. The virtues of this format are well known, so I won’t waste words there. But, what about the shortcomings? Keeping Busy Because stories represent conversations, they’re intended to defer discovery until the last possible moment. However, classical thinking still demands that we think of them as deliverables. Once we begin down that road, it can be very easy to begin treating stories just like a queue of work to keep people busy. We’re not comfortable with uncertainty, so we research everything then write and estimate stories for projects upfront. Roles and teams get put in place to ensure that the stories are written, vetted, and prioritized with enough of a buffer that the engineering team never stops coding. In planning, we question whose best suited to get work done so the most value is being delivered. After all, we want our velocity and utilization to be high. We optimize ourselves for speed and turn ourselves into a small team of specialists. You Get What You Optimize Those outcomes aren’t accidental. They are a direct outcome of trying to optimize a system to maximize the utilization of a limited resource (team member time). We want to keep them busy. Unfortunately, optimizing to keep everyone busy, makes it very hard to manage other aspects of our work. Are we doing the right things? Are we doing them the right way? Are people growing? Of those, concern about team member growth is the biggest miss. Most companies know this already, and to fix it they add team member development as a separate activity. Every year there is a review. In many companies, every few weeks there’s a one-on-one meeting between the team member and leader. These are the forums for facilitating growth. Ironically, as we make headway with iterative delivery and agile practices for our work itself, our people development is still firmly rooted in a waterfall-like annual cycle with few feedback loops. A Backlog of Growth & Learning Opportunities What would it look like if our backlog wasn’t a list of things to do? What would it look like if it was a list of things to learn and ways to grow? What would it mean to our organization if leaders were prioritizing and discussing opportunities for team member growth rather than deliverables? These are the questions that led me to propose the idea of scientific development. Read On The ‘What’ of Scientific Development The ‘How’ of Scientific Development The ‘Who’ of Scientific Development