Design Thinking, Lean & Agile | Will Jeffrey | Skillshare
Drawer
Search

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Design Thinking, Lean & Agile

teacher avatar Will Jeffrey, Because Agile Matters

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

    • 1.

      Course Overview

      1:53

    • 2.

      Building With Agile the Thing Right

      2:20

    • 3.

      Building With Lean the Right Things

      2:32

    • 4.

      Exploring With Design Thinking the Problem

      2:23

    • 5.

      Tying It All Together

      3:01

    • 6.

      Defining an Actionable Strategy

      3:45

    • 7.

      Acting to Learn

      6:59

    • 8.

      Leading Teams to Win

      14:18

    • 9.

      Wrapping Up

      1:45

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

472

Students

2

Projects

About This Class

Please don't forget to leave a review. Thanks!

By the end of the course, you will be able to find an approach that gets your team building the right thing, and building the thing right.

Highly touted methodologies, such as Agile, Lean, and Design Thinking, leave many organizations bamboozled by an unprecedented array of processes, tools, and methods for digital product development. Many teams meet their peril trying to make sense of these options. How do the methods fit together to achieve the right outcome? What’s the best approach for your circumstances?

Blindly applying any model, framework, or method seldom delivers the desired result. Agile began as a better answer for delivering software. Lean focuses on product success. And Design Thinking is an approach for exploring opportunities and problems to solve. 

You will learn:

  • Understand how design thinking, the lean movement, and agile software development can make a difference
  • Define your beliefs and assumptions as well as your strategy
  • Diagnose the current condition and explore possible futures
  • Decide what to learn, and how to learn it, through fast research and experimentation
  • Know how to lead teams to win

Please don't forget to leave a review. Thanks!

Meet Your Teacher

Teacher Profile Image

Will Jeffrey

Because Agile Matters

Teacher

Will Jeffrey and his wife currently live in France. He earned a Master's degree in Management Information Systems from the Sorbonne Business School in Paris. He is a member of the Agile Alliance and a Professional Agile Trainer certified by the prestigious International Consortium for Agile and Scrum.org.

Over the last 20 years, he has trained and coached hundreds of people, including Fortune 500 leaders and teams, startups, and entrepreneurial organizations.

Will is a skilled author of online business courses who consistently offers his experience on Scrum, Agile, and Lean with his 7000 LinkedIn followers and 500 000 post views each year, in addition to agile coaching and training.

You are warmly welcome to join my LinkedIn and Skillshare networks.

... See full profile

Level: Intermediate

Class Ratings

Expectations Met?
    Exceeded!
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Course Overview: Hi everyone. My name is Will Jeffrey and welcome to my course, how to combine design thinking. Design thinking is the latest buzz phrase to have taken over the business and technology world. That seems like the phrase is popping up in nearly every context. A few years ago, Lean UX was all the rage, following a few years focused on Lean Startup. A few years before that, every tech company I knew was rushing to implement agile development processes. It's not that any of these approaches have become less useful over time, but people are experimenting with new ways to build products and successful techniques to get attached to is the next big thing that will prove to be a magical solution for everyone. The problem is that in the excitement of discussing something new, we don't always connect the dots of our existing methods and people can be left confused as to how to best implement things altogether. In a nutshell, here's how you can link the three together. Design thinking is how we explore and solve problems. Lean as our framework for testing our beliefs and learning our way to the right outcomes. Agile is how we adapt to changing conditions with software. The goal of this class is to help you find an approach that gets your team building the right thing and building the thing right. Some of the major topics we will cover include understand the differences between design thinking, Lean, UX, and agile. And know how to combine elements of each for your team. In the next sections, we're going to cover the following items. The goal of Agile is to build the thing right? The goal of Lean is to build the right things. Design Thinking is helping to explore the problem. How to work with Agile, Lean and design thinking altogether. How to define actionable strategy, the importance of acting to learn. And lastly, how to lead your team to win. 2. Building With Agile the Thing Right: Let's be clear, Agile is a software development approach. He was born out of frustration with traditional Waterfall software practices. With a long period of up front requirements gathering and design work than a long development stage of implementing set designs, but without the ability to understand or respond to changing needs. The outcome was that teams were spending a long time building things that people didn't really want or need. And companies were struggling. Software developers started experimenting with new ways to build and came up with a set of shared values and principles to guide teams to do better work. The official agile manifesto was released in 2001. Here's the manifesto It reads, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. The Agile Alliance has also define 12 detailed principles to follow, but does not prescribe any particular processes. So Dev teams often end up using specific frameworks like Scrum or Kanban to help them figure out how to organize, plan, and execute their work. There's a strong focus on teams independence to self-organize. So no two Agile teams look the same, even within the same departments or organizations. If you want to learn more about agile and have the four values and 12 principles explained. Please take my class entitled The Agile from doing to being agile. In theory, agile approaches not only play well with UX practices, but actively require ongoing UX research to constantly understand the changing needs of the customers. However, in practice, teams can get caught up on trying to release more working code faster. And it can be hard to dedicate anytime at all to conducting research or focusing on design decisions. Agile teams often struggle with how to best incorporate UX team members and their work into their practices. 3. Building With Lean the Right Things: Lean UX was born out of the struggle that so many teams had incorporating UX best practices as they adjusted their development processes to Agile methods and attempted to speed up time from idea to implementation. Lean UX is the umbrella term for altering traditional UX methods to fit faster timeframes, which often means shifting focus away from detailed deliverables. This idea was published in 2013 by Jeff got tough. Still one of the great authors in Lean UX topic. But beware, you may also hear about Lean and Lean Startup, which often get conflated but do have specific meetings and distinct elements. Lean is derived from manufacturing best practices and focuses on general business and management practices to reduce waste and maximize value. Lean startup is a broader business and product development approach that suggests incorporating periods of experimentation in order to reduce waste and risk. The terms aren't mutually exclusive, but nor are they interchangeable. Factor Lean UX. The core idea is to alter traditional UX design methods to become faster. Rather than spending a lot of time thoroughly designing and documenting each element. The team is meant to quickly and collaboratively visualize ideas and gather feedback as soon as possible from both other team members and stakeholders and the users. This process mirrors the traditional UX process, but each step is shortened. Let's say a team is working on integrating a new feature. That team might first have a quick white boarding sessions to flesh out the core workflow. Once the group agrees on a direction that can show a low-fidelity designed to users and incorporate the feedback foundering a joint sketch session where this sort of more interaction details. You'll notice this example doesn't have any fully functional prototypes for detailed test reports, but Lean UX isn't an excuse to skip steps. Rather it's an invitation to do just enough to build a shared vision and get feedback, scaling up and back different tools or methods as it makes the most sense for your specific context. Lean UX also doesn't suggest you completely abandoned documentation more that the experience decisions are taken away from UX professionals. Rather, it suggests that the whole team is involved with the design process. So there are no surprises or unforeseen technical challenges. Feedback is collected early and often, and if changes need to be made, it can be done quickly and easily before much time has been invested in final designs. 4. Exploring With Design Thinking the Problem: Design thinking is a general approach to creative problem-solving. Popularized by the Stanford D dot School and IDEO and recently adopted by many tech companies. The approach has five steps and his couched as a way to frame and solve problems of all sorts. The first step is empathize, which looks an awful lot like old school research phases. You gather as much information as possible to learn about the people involved, their problems and motivations and their context. This could mean you do things like conduct interviews, observe people in their space, talk to experts, will look at past behavior patterns. Next, you analyze what you've gathered and synthesized thoughts to define a core problem for the audience you are serving. Look at what you've learned about the group, what they need, and where there may be gaps to create a succinct problem statement to frame your next steps. The third step is to ideate solutions to the stated problem, incorporating creative techniques to look at the problem from many angles and come up with as many different ideas as possible. The idea is to first go wide, generating lots of alternatives before narrowing it down to a few possible solutions to test out. Before you can gather any feedback. The team needs to prototype or create low-cost representations of the solution. A prototype can be anything from a series of sketches to a pixel perfect front-end simulation of a proposed process. The goal is to strike a balance such that the solution seems real enough to get authentic feedback, but it's relatively low cost and easy to produce. Finally, you want to test the prototypes by putting them in front of real or representative users and observing what they do and how they react. Then using the information to form next rounds. You should note that while the process is presented linearly, in reality, the phases may overlap or something you learn along the way, we'll prompt you to revisit problem empathy, or definition. The approach is meant to be structured but flexible. All of this should sound pretty familiar. Design thinking is a formula to help teams collaboratively understand and solve problems by framing them around the people involved in incorporating feedback early and often, which is also at the core of good UX practice. 5. Tying It All Together: Design thinking, Lean, and Agile mindsets aren't mutually exclusive. In fact, there's quite a lot of overlap. This is confusing at first because we often prefer simple explanations. And second, because in the messy world in which we live, we tend to blend mindsets into ways of working that makes sense for the job at hand. Some might disagree, but this is for the greater good. There's nothing to be gained from dogmatic adherence to a particular right way to do things. On the contrary, when we thinking we blend and combine different approaches in meaningful ways, we're exercising our innate ability as humans to solve problems. So often the question is Lean or Agile? The answer is really end. It's lean and agile and design thinking. The lean mindset drives continuous experimentation to learn our way to the correct answers. It helps in identifying the appropriate things to build, as well as improving the system of work that delivers value. This is entirely agnostic to the medium in which value is produced. That is, it could be software underpants or healthcare. The design thinking mindset is all about understanding constraints, seeing opportunity, and exploring possibilities. It's a quest toward finding opportunities and exploring solutions that create value for customers or the organization. The agile mindset is about achieving outcomes with software and the best way is how IT teams unlocked value continuously, adapt to changing needs and build quality into the software they create. Is at the intersection of these three mindsets that we see how everything can fit together. Together. Lean and design thinking helps us to understand where we are today, where we want to be tomorrow, and pursue success through exploration, experimentation, and validated learning. The discipline of framing problems and opportunities and exploring many options and design thinking melds beautifully with the Lean practice of scientific thinking and Learning by Design Thinking and agile ARRA collaboration in realistic solutions. Software is the medium. Engineers and designers are the artisans. Together. They craft solutions that deliver on desired outcomes. And they do their work iteratively, continuously and paired together. Agile and Lean is where strategy meets execution, then gives a framework for testing our beliefs and refining strategy through learning. This learn by doing approach works only if every part of the system is highly adaptive. Agile provides the flexibility to respond to change, which is a first-class capability for aligning technology delivery to real value. Always the strengths of each mindset come together to help us achieve the right outcomes. Design thinking is about exploring problems and opportunities. Lean moves us toward building the right things. And Agile is a way of building things, right? 6. Defining an Actionable Strategy: And actionable strategy is one that defines enough direction to allow action to occur. It's lightweight, rapid, at adaptable. Actionable Strategy acknowledges that nothing is truly knowable. Complex systems are intractable and that learning and responding is the best path to desired outcomes. Step one, diagnose the current condition. This first step draws on the focus and empathy for customer. Intuitive reasoning and questioning that is baked into design thinking. This helps us to discover customer value and identify areas for further exploration. Lee and brings critical reasoning and analytical judgement. This helps later when defining our first action and benchmarking our future success. Step to explore possible futures. By entertaining what might be, we generate options. Exploring possibilities is all about asking provoking questions, entertaining, unconstrained thinking, following tangents and new avenues of thought, we create choices before we make choices. This is where we take advantage of the concept of emergence by engaging in a quest to explore the possibilities, we discover new meaning and instead, which often informs us where to go next. This is the homeland of design thinking. We've understood the problem or opportunity in step one now we're exploring many possible solutions before later converging on our proposal in step three. To quote Dr. Jason Fox, don't look for facts or answers. Look for better questions. If the questions we ask and the meaning we explore that will generate the insights most useful to strategy. Step three set of course, this is where we make choices about which direction to take. We're evaluating our options, deciding what matters most. And homing in on strategic intent. Setting a course is more than simply declaring our goals and objectives. We must define an overall direction. And we need some guiding principles on how we believe we'll win yet leaving out any specific instructions about precisely what to do. This is about strategy and leadership. Lean thinking informs how we set challenges and coordinate coherent action. Agile provides the means for creating Technology Solutions walked, keeping options open and remaining adaptive to change. The decentralization of control and leadership of autonomous teams is how we stay aligned to purpose and make better decisions. To quote Jeff Bezos, be stubborn on the vision, but flexible on the details. Step four, take action and adjust. Now it's time to test our beliefs through action. We make our hypotheses testable. Experiments, measure the outcomes and refine our initial strategy through learning. This is where strategy is quenched by action and made real. A strategy without action is merely speculation and conjecture. It's from action that we learn the most. I think this quote from Thomas Edison is a good conclusion for this step. Vision without action is hallucination. The four steps to actionable strategy or like the glue between these mindsets. The fundamentals of design thinking are put to best use in the first two steps, where our intent is to understand today's reality and explore the possibilities for the future. The lean mindset comes to bear in steps 134, where it's all about identifying the best opportunities to pursue, setting direction and learning our way to success through deliberate experimentation. Much of this experimentation might not involve writing a line of code. After all, working software is still an experiment, just a really expensive one, has confidence increases and software's the experiment. Agile is how teams constantly adapted change, repeatedly adjusting their course and taking next steps, Step four. 7. Acting to Learn: This section is all about how to learn well for better decision-making. We explore how to articulate our beliefs and riskiest assumptions, and then design experiments that help us learn the relevant things to help put theory into practice. There's loads of methods for validating problems, evaluating potential solutions, and testing market demand. Strategy is about doing. Doing is how we learn. Learning is how we, when action is how we push it Theory toward reality. And in our complex world, winning is often about how we learn and respond, not how much we know. Learning your way to a strategy that works begins by doing the following. Defining your beliefs and assumptions so that they can be tested. Deciding the most important thing to learn and how you'll learn it. Designing experiments that will deliver learning. Defining your beliefs and assumptions. Before we talk with customers or run an experiment, we need to identify what we need to learn. Otherwise, we'll have a lovely chap, but might not learn anything that lets us know where on the right track. The problem assumption model helps break down our beliefs and identify the underlying assumptions in our thinking. Those assumptions are the basis of what we test. We can translate them into questions for customer interviews or use them to design experiments that create a measurable result. The problem assumption model is flexible. You can begin from anywhere, problems, solutions, assumptions or questions and elaborative fill out your thinking. Many people begin with solutions and then explore the problem being solved. Later, moving onto the implied assumptions. As adoption of design thinking continues, more and more teams begin with the problem and then elaborate their solutions, assumptions, and questions. Beside what to learn and how to learn it. Know what you need to learn. That sounds obvious, but it's surprising how often teams choose research methods that can't deliver the insight needed to move forward. Over use of online surveys to quiz customers about their desire, intent, or behavior is one such anti-pattern. A well-designed, any unexecuted survey has its place. But so much of the time, product teams will learn more through other methods like observation or conversation. Another anti-pattern is conflating a good result in a prototype test with strong customer affinity with a problem or demand for the solution, without being confident in the problem being solved in measuring the true demand for the solution, teams risk shipping awesome products that customers are unaware of, don't care about, or never use. Research and experiments for learning. Sometimes we learn things that we weren't expecting to learn. Perhaps more often, we don't learn enough to make conclusive or definitive decisions. Finding the signal and the noise is challenging enough. So anything that reduces bad ambiguity and helps us to look in the relevant places with the appropriate tools is a good thing. Probably validation. Many solutions fail because they solve no meaningful problem. Charlie Guo, learn that lesson the hard way. We fall in love with our ideas and our biases get the better of us. We focus too much on the solution without properly understanding if there's really a problem worth solving. As he said, I don't want to start another company until I find a problem that I care about. A problem that I eat, sleep, and breathe. A problem worth solving. We're going to consider two types of problems. First, our customer problems. To understand customer value, we must know customers, go to where they are, watch them, talk to them, build an understanding of what it's like to be them. Challenge our assumptions about what matters to them, how they behave, and what they need. This seems simple and it is. Second, our organizational problems. Sometimes the problem to solve is an organizational one, not a customer one. In this case is not a customer problem that we need to validate. Rather, it's a problem or inefficiency in the way we're solving customers problems. We need ways to evaluate how well our proposed solutions solve a given customer problem. It's the familiar ground of prototypes, analytics, and testing with customers. Let's quickly review five methods. Concept Prototype, low-fidelity throwaway sketches and mock-ups for rapidly exploring concepts with customers. Why IT S good, fast, low-cost participants are more comfortable to give critical feedback because sketches are low effort, high fidelity prototype, a detailed and interactive mockup of the product experience. Why IT S good, validates the nuts and bolts of the solution like interaction, design, content, look and feel. Easy to iterate and build upon based on feedback. Concierge, personalized service provided to a small cord early customers to learn what works before building an automated solution. Y IT S good, generate solution options through exploring the problem with customers. Working prototype, a limited implementation of a product, focusing on the happy path and tested with a pilot cohort of customers to measure how well the solution performs. Y IT S good, high confidence and results because it's real software with real customers. Multivariate split tests, testing multiple variants of a solution with cohorts of live customers to quantitatively learn which elements perform best. Y IT S good, particularly effective for optimizing an existing product or service with high volume of traffic, low cost to deploy working solutions of software. The solution evaluation will provide the expected learnings. Product success relies on a lot of stars lining up properly. We need a problem worth solving access to customers who need what we're offering, a solution that's technically feasible and commercially viable. A good sense of market timing and a measure of good luck. Developing solutions is an economic activity. Taking a lot of time, money and effort, and great products fail all the time for a wide range reasons. Our goal here is to learn quickly and fail fast. Design thinking helps put the customer into focus and brings empathy to problem solving. Along with creativity and innovation to solution exploration. Lean gives us a framework for scientific learning. We identify what to learn and run experiments that help us make decisions as we navigate uncertainty. Although a great deal of learning can happen faster, cheaper, and more effectively without writing a line of code. Agile software development still has a big role to play. The cost of creating software continues to decrease, meaning that many organizations are choosing to move to software as an experiment earlier. Software prototypes with real customers can be a great way to learn what really works, especially when building new products. When it's an existing product slash service, quantitative analytics and split slash multivariate testing. Create feedback loops that help Agile product delivery teams decide what to do next. 8. Leading Teams to Win: In this section, we'll look at ways to communicate vision and purpose, and how to align teams, achieve success, will explore the mechanics of autonomy with a protocol of coherent action, and introduce some methods that help teams to make decisions and prioritize along the way. Let's be honest. A lot of the work that goes on in modern businesses can seem void of meaning. Most of us aren't providing critical services, saving lives or curing diseases. Mostly we're building software products and services, and mostly we're doing it for commercial gain. People want to be self-directed, trusted, and empowered to do the right thing. We all aim a highly engaged, purpose-driven, and empowered workforce. But unless everything is coordinated and aligned, efforts easily become incoherent and potentially counterproductive. Sometimes it feels as if getting people on the same track is the most difficult thing facing any team, having a clear direction, getting everybody aligned, and taking coherent action is critical. Let's look at how to do that. In Dr. author Dan Pink makes a compelling case that incentives and bonuses are a bogus mechanism for getting people to perform at their best. In studies of human motivation, he finds that giving incentives leads to poor performance for tasks that require even just a little cognitive ability. Instead, he argues that autonomy, mastery, and purpose are key to motivation and engagement. Autonomy, the urge to direct our own lives, mastery, the desire to get better and better at something that matters. Purpose, the yearning to do what we do in the service of something larger than ourselves. Mastery in large part is about passion. You can't necessarily make someone passionate about something that's intrinsic. But we can do things to make work more purposeful and create an environment in which teams and individuals have autonomy to do their best work. We can communicate purpose in our vision. We can include everyone when defining desired outcomes. And we can give teams autonomy and accountability to determine their own strategy. Perhaps nowhere else is this so critical as it is in military operations. Armed forces have formalized their guide to action as military doctrine. Let's look at what we can learn from how they run operations. Mission command. Warfare is unpredictable and dynamic. Information is incomplete and situations unfold quickly. Agility and adaptation are critical to success and survival. The Army doctrine on mission command, AGRP 6-0 is fascinating and covers the principles of mission command in great detail. Fundamentally, mission command describes how Armed Forces due the following expected plans will change trained personnel to be agile and adaptive in any situation through disciplined initiative, communicate clearly the intent of the mission. Allow teams and individuals on the ground to pursue mission outcomes as they see fit, adjusting to the situation as it unfolds. The AARP says, mission command is the exercise of authority and direction by the commander using mission orders to enable disciplined initiative within the commander's intent to empower agile and adaptive leaders in the conduct of unified land operations. There's quite a lot in there. Let's unpack that. Mission command is how the US Army maintained centralised intent and dispersed execution through disciplined initiative is how it coordinates many teams performing complicated activities in dynamic environments all aligned to common goals that help teams achieve certain outcomes. Importantly, this is done without dictating how the mission should be executed. That is left to the judgment of subordinates. Those who are closer to the action are empowered to decide the best course of action within certain guidelines to respond and adapt to changing circumstances in order to achieve the desired end state. The commander's intent is a clear and concise expression of the purpose of the operation. Commanders provide subordinates with their intent, the purpose of the operation, the key tasks, the desired end state, and resources. Subordinates than exercise disciplined initiative to respond to unanticipated problems. Discipline Initiative is what combat personnel are trained so rigorously to do during tactical training. This is their deliberate practice, preparing them to perform an uncertain and dynamic circumstances with Initiative, disciplined initiative as action in the absence of orders. When existing orders no longer fit the situation where one unforeseen opportunities or threats arise. We can coordinate people in teams working on initiatives in a portfolio using the protocol of mission command. It's remarkable how well mission command aligns with the principles of Lean and Agile listed here. Learning and adapting over analysis and prediction. Responding to change over following a plan. Empowered people are happier and achieve better outcomes. Individuals and interactions over processes and tools and outcomes over outputs. Mission command expects the unexpected threshold of knowledge, trains people in the skill of responding. Deliberate practice sets clear outcomes with some guiding principles, the commander's intent and decentralizes control, relying on people that are closest to the action to make the right decision autonomy. Previously, we introduced four steps for defining actionable strategy and explored how design thinking, Lean, and Agile contribute along the way. And we discussed the skill of learning both as a way to solve problems and find opportunities, but also to explore uncertainty. Now let's consider ways to visualize strategy, coordinate action, and make decisions along the way. What follows are a range of techniques that helped to articulate the purpose of missions and communicate team's progress in achieving outcomes. Make anything visual and you make it much more comprehensible. Better yet, when people collaborate and visualize things, they build a shared understanding together. Visualizations help us to articulate a common purpose and teleconferencing story to persuade others to join our quest. They describe the commander's intent, but far from being directive, visual communication is democratic, inclusive and participatory. Product design Wall is an information radiators showing the product vision, strategic intent, and progress toward the desired end state. He combined strategy, design, and engineering into one shared view that everyone can relate to. It draws people in, stimulates collaboration and generate shared points of reference. Such visualizations describe an understanding and anchor teams. Let's discuss some techniques for prioritizing value. It's an awesome thing to have a shared vision and initial strategy about how you're going to get there and the right people and resources to make it happen. Teams now face three critical questions. What shall we do first? How will we know if it's working? What do we do next? Simple as these questions sound, the answers aren't always obvious or straightforward, especially when there are many options and limited capacity to do them. Those conditions seem true for every product team ever. This problem is universal. There aren't enough people and never enough money for organizations to do all the things they want. They must choose and decide. In our personal lives, we make decisions continuously about what our goals are and how we'll spend our time and resources in pursuit of them. At the park, a thirsty puppy chooses between slurp of water, biological needs, and playing with his pals social needs during his morning walk. But acting on instinct is dangerous. Buster Benson, John Moon again and others highlight all the ways we let our biases get in the way the themes they describe here don't help us to make objective choices. To get things done. We tend to complete things. We've invested time and energy in. To stay focused. We favor the immediate relatable thing in front of us. We simplify probabilities and numbers to make them easier to think about. We favor simple-looking options and complete information over complex, ambiguous options. Let's look at some ways to make better decisions. Dimensions of success. To know that you're being successful, you need to know what success looks like. The dimensions of success you define ought to have direct correlation with your vision and strategy. Ask specific questions. What ways might have activity contribute to a strategic outcome? This kind of subjective reasoning can be useful for initial prioritization of what to do first. At this stage, our threshold of knowledge is often pretty low, mostly because meaningful action is yet to be taken. It's okay to use our intuition and any empirical data that's available to make initial judgments about the potential of a set of options to deliver on the desired outcome. Making success measurable. We measure things so that we can make better decisions. And measurement is the only way we can answer the question. Is it working? Douglas W. Hubbard has said, if a measurement matters at all, it has because it must have some conceivable effect on decisions and behavior. If we can't identify a decision that could be affected by a proposed measurement and out could change those decisions than the measurements simply has no value. We need to consider how valuable a piece of information will be in the future, will help us to make decision. If we hit the number or reach a specific target by we then stop further work because we've done enough. What if it moves in the wrong way? What will that mean? And what might we do about it? We need to consider how valuable a piece of information will be in the future, will help us to make decision. If we hit the number or reach a specific target by we then stop further work because we've done enough. What if it moves the wrong way? What will that mean? And what might we do about it? It's not that we need to predict all potential possibilities for put in place a precise system of measures that automates our decisions. Rather, we need to think about the indicators that will be useful for making some sense or meeting. But can we observe that will help in making decisions? Suppose that you're operating an online electronics business, selling everything from $5 Arduino breadboard kits to high school students to $50 thousand control system components to avionics engineers. You want to make it the best experience possible for customers. And you believe from talking with him that easily finding what they're looking for is the most important thing to them. You have a range of initiatives in place aimed at improving things for customers. What measurements will you take and how will you use those to determine what's occurring and what to do about it. This table illustrates how to break down goals into useful measures of success. The first three are not good enough because they're too vague or they have no outcome. On the other hand, the last three are good. The goal level metrics are specifics and focused on the outcome with a clear understanding of what success looks like and how it will be measured. Now it's time to choose initiatives that we believe are most likely to achieve the outcomes. We are considering a fast ways to compare initiatives relative to one another using the CD3 slash ws j f method. Cd3 stands for cost of delay divided by duration. This method is also known as ws j f, meaning weighted shortest job first, cost of delay is about what an organization stands to lose until the work can be completed and value capitalised. For all intents and purposes, cost of delay is about business value and time for a given initiative. This kind of prioritization is a hunt for the smallest, highest value initiatives. Small is critical. We know from lean manufacturing and theory of queuing that small batch sizes are fundamental for optimizing flow. In product development, we make initiatives as small as we can while still having value. This reduces cycle time, allowing value to flow more continuously. Smaller chunks of work also equate to more flexibility because small commitments mean small losses if an initiative is failing or needs to be abandoned for some reason. This all makes diversification of investments or optionality easier to achieve. So we need to understand something about the relative size or duration of an initiative and its potential value. Then we're able to calculate a CD3 score and compare it with others to identify the smallest, highest value candidates. Back to our example. This table shows how CD3 is calculated. In this case, Initiative B is ranked the highest. It has a moderate cost of delay and a short estimated duration, meaning we could achieve value quickest by doing this work first, all of these prioritization techniques help us to select high-value work and get it done quickly. It's not just about time, and it's not just about value. How much we do batch size when we do it sequence, and how much work is happening at the same time, concurrent Work in Progress matters to the figure on the right shows how limiting work in progress, sequencing work and reducing batch size can result in earlier realization of value given the same constraints of time and effort. Let's do a quick recap. When people are empowered with true autonomy and aligned to purposeful missions, there not only more motivated, but also able to overcome challenges and achieve outcomes in ever-changing situations. Mission command is a protocol for leading teams in this way. And it melts beautifully with scientific thinking and deliberate practice of a lean mindset. To do this well, clarity of purpose and an understanding of success and how it's measured is paramount. Visual management techniques offer a variety of ways to align to purpose. Whether it's an entire organization, a portfolio of initiatives, or one product team on a mission. Even though purpose gives direction, teams need to prioritize value and measure success to find their way. Measurements are the signposts of progress that we use to decide what to do next. This, along with value-based prioritization, helps teams to maximize outcomes within the constraints of a given system. Predominantly as the lean mindset influencing our decisions as to what to do, when and how to adapt our strategy. The ever adapting nature of agile delivery plays a supporting role by being an enabler, not a constraint to change. Where lean has scientific and critical thinking covered. Design thinking provides the creativity needed when exploring new challenges as the situation changes. 9. Wrapping Up: The mindsets of design thinking, Lean, and Agile have different origins, helping us to think in different ways into solve different problems. We've explored how these come together, compliment, and overlap one another. Design thinking brings discipline to how we frame problems, consider the customer, and explore creative solutions. Lean thinking brings discipline to how we learn to make decisions and coordinate efforts on our quest to achieve our goals. Agile is how we build technology solutions that evolve and adapt as we learn and respond to changing needs that emerge from taking action. The four steps of actionable strategy describe how these mindsets come together in practice. It's the scaffolding that frames the work we do. The glue that brings many ways of thinking together as one. Although we've included some guidance about how we think and act, making it work is about people. Instead of focusing on process, we ought to challenge how we think. Try new ways of doing, adopt the things that work and learn from the things that don't. This will be different for everyone. Success is about how we develop new ability, learn by doing and adapt to what is learned. At the end of the day, there is no one correct way, nor is one single mindset enough. But altogether, elements of each mindset help us to find our way forward. Each approach is meant to solve a particular problem and elements of each may be useful. So you'll have to find what works for your team. If there's one thing to do after you finish this class, let it be something new. The best way to build new ability is to try something, see what happens, and adapt as you learn. Enjoy experimenting.