“Lean Design Patterns” in 5 minutes

4 steps, 1 cornerstone

Here are the 4 steps and the cornerstone we use to create the right product.

lean design 4 steps and cornerstone

Suppose you have a great Idea and you want to make it real. You’ll start with the cornerstone which is “Leadership and Teamwork”. You need to be passionate about your idea and bring around you people that will have skills and co-create with you.

Then you can start the first step: understanding deeply the problem you try to address and propose solutions. You’ll need to know the big picture, identify your assumptions, go out of the building to identify the pain points of your potential (or existing) users (even if they don’t know yet they have a problem :) . This is “See the Whole”.

You’ll have a lot of information after this step and you’ll have to challenge options, focus, simplify and find a consensus to concentrate on what is the right product. This is the “Find Trade-Offs” step.

Since you have simplified your design, you’ll be able to “Deliver Fast” with an iterative and incremental approach. Design is about knowledge creation, you’ll have to “(L)earn Often” to remove the major waste we are fighting: “working on the wrong product”. This is a wheel, so of course you’ll start again “See the whole” step.

What about Patterns?

We have defined 4 patterns for each step and the cornerstone. A good pattern appears when someone says “that’s exactly what I am already doing and it works!” (we have not created anything, we have just integrated what was working for us and gave it a name). Here are the patterns we have defined:

Lean design patterns

You might not use ALL the patterns and the practices you’ll use for the patterns will differ depending on your context. A pattern is there to be implemented in different ways, but the objectives stay the same. They are also there to be combined between them.

How to remember those 25 patterns: 5 acronyms

We created “Lean Design Patterns” to better communicate about creating the right product. The problem of Lean is that it’s a complex system and hard to memorize. We are using 5 acronyms that works as checklists to remember easily if you have not missed anything (you’ll see the link with the patterns already listed).

 lean design acronyms

What about Practices?

Principles are good, patterns are great, but practices are even better, because one of the objective of this initiative is to be able to start creating the right product next Monday. Each practice we detail can be explained in 2 minutes, only need a sheet of paper and a pen and are collaborative. They have been created and tested to leverage the teamwork. The most important ones are:

  • See the whole: Root Cause Analysis, Impact Mapping, Story Mapping, Collaborative Games, Canvas
  • Find Trade-Offs: ODAS (Outcome, Desirability, Assumptions, System qualities), MoSCoW (Must, Should, Could, Wish), Relative estimation, specification by example
  • Deliver Fast: Iterative and Incremental Development, Scrum, Concurrent Engineering
  • (L)earn often: Actionnable Metrics, Split testing, A3 Process, Assumptions backlog, Real options

Lean Design works as a System

The 4 steps works together. You can read “See the whole, in order to Find trade-offs, in order to Deliver Fast in order to Learn and earn often, in order to See the whole, …”.

Simplest way for a Lean Design: use Scrum (without but…)

Rugby3With “Lean Design”, we try to build the right thing and maximize the innovation-value. If you look at the scrum guide we can see:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Seems like the Holy Grail we are all looking for, no? I really think Scrum helps to build the right thing if you manage to master it. In a team I coach, we have agreed on a really strong definition of Done for the Scrum. It’s only one sentence: “DoD = the CEO can demo this feature to the customers”. And that’s all. Of course, it’s in a startup with 10 employees. The stronger your definition of Done is, sooner and better your feedback will be. You should measure your lead time between the idea you have and the validated feedback you have with real customers. If it’s the length of your sprint (let’s say 2 sprints to be realistic), Scrum will be powerfull to build the right thing and I am pretty sure you’ll have a Lean Design.

If not, you should be careful. Scrum might help you to build the wrong thing with great efficiency. Of course, you’ll rely on a Product Owner (in the Scrum Guide, we read “The Product Owner is responsible for maximizing the value of the product”). And that’s great because as Toyota is saying: “First, build great people, then build great products”. But don’t forget that each time you’ll strenghten your DoD you’ll approach a great product. It should be one of the top priority of the Scrum Master. A lot of DoD are too cosy in my opinion.

 

When Design To Cost becomes Design To Value

A_Witch_vs_a_Duck_by_KaduntaDesign To Cost (DTC) means defining a target cost and designing a solution to reach that goal. That’s a Lean principle and can be applied to Software. I like the idea and I prefer a team fixing the budget, the delay and have a variable scope, but in Software we should be more focused on Value than on Cost.

Value is not the same as Cost. DTC is good for manufacturing because you’ll produce 1000 units of the same item per minute. In Software, most of the time you’ll create a unique product. We should focus on Design To Value (DTV).

Seems a good idea, but hard to put in practice. It’s quite easy to evaluate Cost, but really hard to evaluate Value. You’ll find a lot of books on this topic, I can just explain what we are doing during our Design workshop. One of the guideline we follow is to have the “tool as simple as possible but not simpler”.

albert-einstein-simple-quote-670x502

Here is how we proceed:
Facilitator: Well, Product Manager how do you think you’ll prioritize the Features. Suppose I ask you “Should we do Feature X or Feature Y?”. What would you think about ?
Product Manager: I would consider the outcome I expect. Will this feature bring more money, help me achieve my Business objectives. I’ll also consider the perception by the users and all the stakeholders. And you know I have an obsession with this feature, I would be really relieved if it can confirm the idea I had at the beginning of the project.
Facilitator: I suppose you also want the system to be available every day, no failures :)
Product Manager: Of course, and I hope it won’t be like last version with the bad performance, I need it to improve, customers are becoming crazy with Screen Y.

The idea here is to identify the attributes, the characteristics the product manager is using to describe the product. Of course he’ll most of the time forget the “Must Be” features which are implicit, so we need to help him to understand there is also some value for those features.

I prefer to limit to 4 to 7 attributes to describe the Value of each feature.

This is the typical set of attributes I use (but don’t hesitate to discuss this with the whole Team). I call this “ODAS”:
- Outcome
- Desirability
- Assumptions
- System Qualities (= non-functional requirements)

The idea is close to what Brandon Carlson describes in Story prioritization at the “Blink” of an eye. In critical decision-making process, experts just use few attributes to prioritize. Why should we have a more complex model in software?

In next post, we’ll see in detail how to use a “Value Matrix” with ODAS attributes.

Caution: The risk when you start to evaluate value is the “Monty Python – Witch Evaluation” effect. When seeking the Holy Grail, the Knights help peasants to evaluate if a woman is a witch or not.

Knight: There are ways of telling whether she is a witch.
Peasant: Are there? Well then tell us!
Knight: What do you burn apart from witches?
Peasant: Wood!

Knight: So, why do witches burn?
Peasant: Cuz they’re made of… wood?
Knight: Gooood. So, how do we tell if she is made of wood?
Peasant: It floats!
Knight: What also floats in water?
Peasant: A Duck!
Knight: Exactly! So, logically…
Peasant: If she weighs the same as a duck… she’s made of wood!

Then, they ensure the woman weighs the same as a duck and… they just burn her.

YouTube Preview Image

So, be carefull with estimation and evaluation. We know they are wrong but they help for collaboration, prioritization, identify risks and focus, nothing more.

 

Howto… Keep Value Traceability in Lean Design

In Software, we are very proud of traceability. If there is a bug, we know which test scenario it corresponds, we know which requirement, the history of the document, the person that made some changes…

One traceability we consider less is “Value Traceability”. What is the outcome of a feature, piece of code or document?

First thing to do is to ensure the whole team has a shared Vision. Why are we doing this product?

Three stonecutters who don’t share the same Vision

This is the story of the three stonecutters that Mary Poppendieck tells:

stonecutters-cathedral

Our first step is to understand that we are building a cathedral. Second step is to keep Traceability between the Cathedral (Value, Goal, Outcome) and the stone (your feature, piece of code, documentation).

First, Share the Vision of the Cathedral with an Impact Mapping

Since few weeks, to define the Cathedral I use Impact Mapping tool from Gojko Adzic. It’s a simple MindMap representation of “Why, Who, How” we are doing a product. It’s also a good way to keep the link with the “What” (features of a product).

impact-mapping-gojko-adzic

I like to start defining the Vision like that:
Facilitator: Remind me, what is the Goal of the Goal of your project
Product Manager: Earn some money, be the best, … (sometimes some Goals linked to outcomes for the company)
Facilitator (I draw money, being the best, …): Ok, those are high level goals, let’s be more specific. What are the objectives to reach this goal?
Product Manager: Well, first we need to increase our Customer quality of service, reduce the time to deliver the product, … (you can see some words like “increase”, “reduce”)
Facilitator (I draw arrows in a MindMap style between Goal and Objectives)

For the “Why” part of the Mapping, I like to have some specific, measurable objectives. After the “Why” part, you’ll list all the Actors and the Processes to achieve those objectives. Your result will look like this example:

impact-mapping-example-description

Next step: Keep the end to end Traceability with your Features

Then, you can prioritize your Objectives and take Actors and Processes to create a Story Mapping. Since the features are linked to Activities which are linked to a Process, you keep a “Value Traceability”. During your workshop, you’ll go back and forth from you “Goal of the Goal” to a low level “Feature or User Story” in your Story Mapping.

value-traceability-impact-and-story-mapping

That’s the first part of “See the Whole”. Next step is finding Tradeoffs on this whole chain to be able to define a Roadmap and MVPs.

We need a NEW NEW NEW Product Development Game

A not so long time ago, in a galaxy not so far… I heard this conversation:
Top Manager: How is the project going?
Project Manager: On track boss, 40% is done, we have requirements, specification and test plan

Nowadays, I hear:
Servant Leader: How is the product my dear colleague and how can I help you?
Scrum Master: I am glad you ask. 40% of the product is done

It seems better, but “40% of the wrong thing is still… WRONG”.

roots-of-scrum

 We stopped running the relay race and took up rugby. But still missing something. By the way, always a pleasure the read, read and re-read the Roots of Scrum: the NEW NEW Product Development Game.

Don’t divorce designers, implementers, users, stakeholders, … In short, Don’t Divorce

everyday-things

Look at this teapot (from Donald A. Norman): what happened? Maybe nobody has really used it before the end of the project. Maybe requirements, design, specifications, testing of the scenarios, qualities, non-functional requirements were done. I am pretty sure the project was also on time, on budget and on scope.

Gerald Weinberg says “the three causes of software projects failure are peoplepeople, and people.”. In lean design we define failure as a product that doesn’t bring value (outcomes, learning, money, traction, …). The “people, people, people” cause is still there. Maybe people don’t care and don’t have a shared vision of the value. Maybe they dont’ “See the Whole” (and have not considered the teacup in their design). In my opinion, it comes from the divorce between people. Having specialities such as “Designer”, “Implementer”, “Tester” cause many silly situations.

“Cross functional team with a shared vision” is in my opinion the only principle to remember.

 

Build the Right Thing: The Holy Grail

It seems that we are all looking for the Holy Grail nowadays in software industry: “Building the Right Thing”.
Look at Gojko Adzic initiative, Henrik Kniberg contribution, Mary Poppendieck gave a great presentation on this,

That’s a key success factor of our industry, because if “with 20% of the scope you bring 80% of value” that means you found the Holy Grail.

The problem we have today is: how to do that? We need to measure value, hear the voice of the customer, validate learning, co-create (designers and implementers). We need some principles, practices, thinking tools, collaboration tools. Sounds like the Holy Grail,no?

I am still seeking for what could be Lean Design to build right thing. In this post, I want to share a checklist I like to use during Design workshop for the team to have great ideas. I display this as a poster and a typical conversation looks like:
Facilitator: Hey, Team we have one hour left in our workshop, what should we focus on ?
Team member: I see we could “Split complex items”, maybe we could try a quick relative estimation and slide the big ones.
Team: Ok, let’s slice the elephant

lean-design-checklist

Pros of a checklist: it’s simple, you just need to ask some questions.

BIG CONS: sometimes we get stupid with that. Remember the Monthy Python and Holy Grail ?
YouTube Preview Image

 

Try this Story Mapping template: See the Whole to define your MVPs

Jeff Patton introduced Story Mapping for Agile development.
The idea is to describe your User activities end to end and to map the features of your product. It looks like this:

story-mapping-theory

There are many advantages to have this two dimensional set of requirements. In Lean Design (“See the Whole” is one of the principle of Lean), Story Mapping will be a central tool to collaborate and find the best trade-offs to increase value that each MVP will bring.

Here is a template I like to use:
story-mapping-template

I attach the original pptx file.

The best way I have found is to create this story mapping on the wall for the team to “See the Whole” to be able to prioritize based on the end-to-end value. The major risk when designing is to create local optimization on one specific component. Look at this picture of a Design workshop:

story-mapping-from-the-trenches

Story Mapping is not a silver bullet and sometimes you won’t be able to work in this way. But I have found it very useful to find trade-offs and define Minimum Viable Product.

A checklist for Trade-Offs

A checklist I like to use is focused on the trade-offs. You can use it during a Design workshop:
Facilitator: This requirement is a big one, do you think we can simplify it?
Team: I see in the checklist we have listed 100% of the scenarios, maybe we could concentrate on the 80% cases that will happen and decrease the priority for the 20% that might never happen (let’s add the exceptions in MVP2).
Facilitator: Ok, let’s split this requirement and refine priorities

lean-design-trade-offs-checklist I have identified those 5 trade-offs. Do you use others when you are designing your product ?

I also provide the powerpoint source file if you want to modify it: checklist-tradeoffs.pptx