A framework for
Learning Cycles
Why?
For a product to be truly viable it must fulfil three aspects:
-
It must address a customer need, or even better it must solve a real customer problem.
-
It must be technically feasible using robust and trusted solutions.
-
It must be producible in a cost- and flow-efficient way.
​​
WHAT?
A learning cycle is a systematic problem-solving process that captures knowledge as it solves problems.
The time invested for learning cycles in early development shortens the time it takes in late development, usually drastically. If you need to get your ideas to market faster, then you need to invest the time for learning cycles in early development. Products get stuck in late development because they run into problems at the point in the development process when change is the most time-consuming and expensive. The way to prevent these problems is to actively seek ways to uncover these problems earlier.
Learning cycles in early development helps eliminate these risks.
Strategic and Tactic Capacity
This approach can be used in both a tactical and strategic aspect, where the tactical part is within a product development effort. While the strategy part reaches beyond that effort, so that the documented learning can be used to radically speed up future developments.
Test-to-Design Yields: “Right the First Time”, optimized design and organizational learning.
The Two Parts
The Lean Learning Cycles Framework is divided into two parts where the first part is done to prepare and plan for the execution of the learning cycles.
The Preparation Part
This part is done to understand that the things we execute on is the right things to do. Are we really addressing the right issues that will create a cost efficient and high-quality solution that will delight our customers?
The Execution Part
The core concept is that execution is done in short two-week iterations. It starts with planning out the activities that will happen during the iteration and ends with an integration event where the results is examined.
Why Learning Cycles Maters?
To accelerate innovation, we must push decisions later.
This seems to go against everything we think we know about how to get things done fast: “Choose early, be decisive and make bold choices”. We also accept the fact that most innovative ideas don’t come to fruition, most products deliver disappointing results or simply fails.
In a well-functioning innovation process, bad ideas fail early. They get screened out as small experiments expose their fundamental flaws. In fact, the ability to fail early, fast and cheap is one measure of a successful innovation process.
Most of the reasons why innovation fails in execution are preventable failures, these innitiatives were doomed to fail because decisions were made based on incorrect assumptions or bad data.
Innovation is risky, and sometimes the risks materialize no matter what we do. But if many innovation programs deliver disappointing results, that points towards a more fundamental problem, we simply do not know how to innovate!
To rebuild confidence, we must eliminate the preventable execution failures at the root cause level — in early development, when those decisions were made. This phase is called the “fuzzy front end” for a reason. It is a time filled with uncertainty. The more innovative the idea, the more uncertainty there is.
Build better decisions
Teams learn how to run rapid experiments, build virtual models to test out ideas, leverage 3D printing and other rapid prototyping tools to build physical models, and get early, meaningful feedback from customers and users to guide better decisions.
Using “Key Decisions” and “Knowledge Gaps” to provide structure and help teams conceptualize the most valuable work they can do to make decisions at the right time, with the right people and the best available knowledge.
Major decisions in an innovation program are “Key Decisions” because they will have significant impact — and the team doesn’t yet have the knowledge to make them with confidence, but they can increase confidence with more research and experimentation.
The Last Responsible Moment is the last moment in time when a decision can be made without causing any additional cost of delay.
Start with the Core Business Hypothesis
Before entering the learning cycles, we need to define what we are trying to achieve. This is described using a hypothesis statement.
A hypothesis is a speculation, a belief, or an idea, that is based on limited evidence. We don’t have all the facts, but we have indications that lead us to supposed explanation. It is the starting point for further investigation.
The Core Hypothesis is a short description of the product vision that describes the reasons why this idea will create customer and business value. It must be written from a business perspective and with the idea of “prove something to move forward”.
Must Have Attributes of a Core Business Hypothesis
A core hypothesis is supposed to be written from a business perspective, it must address a business opportunity or a customer problem. And, like every business hypothesis it must include some essential attributes:
A confidence level: how confident are we in this less-than-factual insight that is being presented to someone for decision-making or further actions?
A severity level: what is the impact of addressing, or not addressing this hypothesis?
Prepare for the Learning Cycles
Documenting the major product attributes and hard requirements will act as a starting point to feed the Learning Cycles and support the search for Key Decisions and Knowledge Gaps. As the process moves forward, each product attribute will get refined into specific features, functions and specifications that satisfy customer needs.
User Stories
User stories should provide a complete view of the product from a customer perspective. Notice that there are no specific features or technology included. Customers don't care about features, they only care what the product will do for them, and this is what user stories attempt to define.
Once user stories are understood, acceptance criteria should also be added, as well as how you'll get validation for the user story.
In a hardware setting these user stories becomes customer centric objectives that describes what the solution is supposed to do for the customer, and as such they are critical for the success of the development activities.
User stories have their place in the Lean Learning Cycles Framework and are necessary to prioritize the needs of the customers as well as to clarify what the customers are trying to achieve. However, since user stories for physical products cannot typically be directly translated into features, functions or tasks, they become the starting point for developing a task backlog rather than backlog items themselves. Once you have written the User Stories, it takes several more steps to identify the specific backlog tasks.
Product Attributes
The team will identify the major attributes of the product to begin the process of developing the backlog of tasks. Product attributes are not detailed requirements you'd find in a waterfall Product Requirements Document (PRD), but does include buckets of functionality, major components or constraints that describe the overall product.
TIPS FOR SUCCESS:
Work with your cross-discipline team to clarify the attributes and identify gaps.
Include designers as early as possible.
Always ask, "Is this set-in stone? Or do we have flexibility to innovate here?"
Attach pictures or links to anything that helps communicate the attributes.
Don't lock yourself into detailed decisions - allow "room to innovate."
Priority Matrix
Matrix thinking has been a powerful tool for hardware development for decades and is a valuable tool for planning for a good reason — user stories will be satisfied by a range of product attributes.
This attribute-to-customer need relationship cannot be documented, understood or analyzed without some form of relational matrix.
The priority matrix has two dimensions. The left-hand side of the matrix shows prioritized user stories. These are customer needs and goals. On the top of the matrix are the range of product attributes we developed in the last step. The relationships between these factors become the basis for the high-level increment planning, prototype plans and dependency identification.
The priority matrix looks at important relationships between user stories and product attributes. You're looking for high areas of importance and where you'll need to apply more attention (innovation) and set priorities.
TIPS FOR SUCCESS:
If this activity is difficult, consider reviewing the user stories and attributes. Have user stories really described what customers desire? Are the attributes too detailed?
Maintain an open mind and ask yourself, "Will improving this attribute help customers in important areas?"
Key Decisions
Key decisions exists in the connection between the product attributes and the user stories they address.
WHY?
The identification of key decisions results in an understanding of the knowledge needed to make those decisions in a fact-based manner. If we work systematically to identify and close knowledge gaps our decision making is improved, resulting in solutions that delight customer, excellent product quality and efficient projects.
WHAT?
This is an opportunity to leverage the team members’ experiences to build a good initial set of knowledge gaps. The team can immediately build the tracking, flow and knowledge capture systems to manage the gaps. After this initial jumpstart, every attempt to close a knowledge gap will probably surface more, but smaller questions. The team needs to accept that not all knowledge gaps will be closed but instead focus on the knowledge gaps that have the most risk and highest impact on the project.
To make wise decisions, the team needs knowledge
The work of any development team in the physical or virtual space is the work of building knowledge needed to make decisions and execute them.
In software, the code itself embodies the knowledge that went into creating it, in a form that can be instantaneously replicated and transported. The time from decision to execution approaches zero. In the physical world, the decision is only the beginning, and we continue to build knowledge until the team’s decisions are fully realized as a product that a customer can buy.
Software teams deliver the code itself to customers, as apps or as firmware flashed into memory. Physical product teams deliver knowledge in many different forms to downstream partners who will source, manufacture and ship the product to the customer. Those partners need to have confidence that this knowledge will enable them to build a good product.
Increment Plan
A clear plan provides structure for the “fuzzy front end” even if we know the plan will change. The process of thinking through what we need to learn and how our questions arrange into logical sequences of inquiry builds development. The plan will need frequent revisions as the knowledge we develop sends us in new directions and opens new lines of inquiry. Yet it’s all too easy for teams to get stuck in this phase of development - or for teams to rush through this phase because it is so uncomfortable to have so many options open.
Time-boxes drives progress
When there is nothing pulling work through the system, we get stuck. Using fixed duration time-boxes helps to solve that problem.
In the Lean Learning Cycles Framework, we do quarterly planning, that are broken down into learning cycles that are 2 to 4 weeks long. So, as we plan the increment, we are making a rough plan of what is to be achieved during the next twelve weeks.
Based on the previous front-loading work try to identify the most critical knowledge gaps to close, the key questions that need to be answered, and the biggest risks that must be mitigated.
In the increment plan we lay out the key decisions in a logical sequence, considering any dependencies between them. We also add the knowledge gaps we need to close to be able to make the key decisions and estimate proximately how long it will take.
As the plan is completed, we should see approximately when knowledge gaps will be closed, and key decisions made.
The plan changes along the way
As the work progresses and knowledge is achieved, we may need to change the plan, this is normal and should be expected.
Risk Mitigation Plan
Brainstorm major risks, determine probability and impact on a 1 to 5 scale, prioritize accordingly, then plan for the highest priority risks and add them to the plan.
Execute the Learning Cycle
Execution of the Lean Learning Cycle is done using short iterations, that begins with planning the tasks and experiments that needs to be performed to achieve the desired results and ends in a demonstration of the same.
The use of a fixed duration timebox ensures that work gets pulled through the system. The timebox is a tool that address both the desire to move too fast and the need to make demonstrable progress.
The use of a fixed duration, standard timebox helps to keep everyone working in sync. The conclusion of a timebox cycle is a natural point to hold an integration event, where teams share their progress and look for areas where their solutions overlap or conflict. The nature of a short timebox pulls work through the system by creating schedule urgency and by ensuring that someone never gets too far off-course before the next review.
Plan the Cycle
As we plan the learning cycle, we are breaking down the knowledge gaps into the actions we need to do to be able to bridge the gap. This is an important, valuable, and productive way of working because it involves all members of the team getting engaged in the project, get to know how their tasks connect to one another, and can influence their own work. A well-planned iteration will lead to a better project.
WHAT?
A short planning event for the cross-functional team where they define problem statement, design experiment and determine success criteria.
It is a time-boxed event, approximately 1-2 hours per week of the learning cycle.
The team refines problem statements and success criteria for each experiment/research that will be performed in the cycle.
How? Use The Scientific Method
At the core of science lies a problem-solving approach called the scientific method. The scientific method has five basic steps, plus one feedback step:
-
Make an observation
-
Make a problem definition
-
Form a hypothesis, or testable explanation
-
Make a prediction based on the hypothesis
-
Test the prediction
-
Iterate: use the results to make decisions, create a new hypotheses or define a new experiment
Execute the Learning Cycle
Run the experiment and gain the learning
Execution is pretty straight forward, it’s just to run the experiments and trials and evaluate the results. But there’s a few things that could help make the process easier.
Use frequent status meetings:
In its bare essence this is basically to start every day with a recap of yesterday and a quick “what are we going to do today”. This is super helpful and help keep the team aligned and focused on the task at hand, while expediting the process.
Conclude in a demo:
At the end of each cycle run a workshop where the results of the experiments are examined. This supports team learning.
It is also a great opportunity to do a little continuous improvement, that is we focus on how we do work, and on how that can be improved.
Integrate the learning and make decisions:
The final question that needs to be answered before we move on to planning the next cycle is: “have we learned enough?” to make an informed and knowledge-based decision?
Intergrate the Learning
A little advance preparation from each person increases the value for everyone, so by preparing an A3 to describe their progress, and ask each person to read the others’ A3s before they arrive.
The Integration Event does not slip even if teams are not ready, it is scheduled for every two weeks and will be held every two weeks, if some teams have not hit their goals, then the rest of the teams need to know what the issues are and how large the gap is between expected results and their actual results.
This type of meeting requires a high degree of interaction and attention to detail. The format and structure of the meeting needs to support the participants’ full participation, since anything that is missed here could cause problems for the rest of the product development process.
Hold the Integration Event as a face-to-face meeting, at least the first even if you must pull people from around the world to do it. The benefits of bringing the team together here will pay off for the rest of the project.
Late integration point meetings to review the issues from prototype testing should be conducted with the prototype right in front of the team. If the prototype is too large to fit in a conference room, then the meeting moves to the place where the team can get their hands on it.
Pivot or persevere decision are the backbone of a lean culture. The team must consciously look at the data and decide on what to do next. Without a data-driven decision on next steps, all the MVPs, experiments, and Build-Measure-Learn Loops don’t mean a thing.
The basic concept of a “pivot or persevere” decision is that once we have gathered enough data, we are obligated to look at the data with clear eyes and decide whether the (insert reason for running the experiment here) is worth pursuing. Deciding where to spend our time and money to achieve the most impact is a fundamental necessity. If our current course of action will not result in the intended outcome, we are obliged to pivot or stop the project entirely
Knowledge Brief
A short, one page, A3 report is a communication tool, that is especially effective for supporting the systematic problem-solving and selectively standardized work that we encourage in a Lean Learning Cycle environment. A3 reports are the primary means for communicating knowledge and ideas.
The Knowledge Capture A3, sometimes called a Knowledge Brief or K-Brief is a report about some area of knowledge that the author wishes to share, or, in the Lean Learning Cycle it is the report about a specific experiment that has been executed.
Knowledge Briefs require the most flexible format. To make a good Knowledge Brief, the author needs the flexibility to use the space on the page in whatever way will best suit the subject matter. A lightweight template for a Knowledge Brief may be a good place for the author to start. The best way to learn how to write a Knowledge Brief is to simply make the attempt and get feedback on the draft, then refine it. It gets easier with experience.