Playing Lean is a business simulation in a board game format to learn about lean startup principles and practices.
The following facilitator tips are based upon those experiences. Some of the tips are more advanced (meaning these take time to prepare). You might not agree with all recommendations, but hey, it’s up to you to try 😉 (as an experiment)
Lean Startup is a method for developing businesses, products, or services. The technique has been developed and made famous by Eric Ries. In September 2008, Ries first coined the term on his blog, Startup Lessons Learned, in “The lean startup“. His book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses” was published in September 2011.
Instead of expressing “requirements, ” we consider assumptions and declare hypothesis statements. A hypothesis statement is a way of expressing assumptions in a testable form.
Reality often shows that the creators of a product or service are not sure what a user needs or wants or how it should work concerning the user experience. But quite often, organizations or companies proceed with their idea for functionality or user experience without input what the user needs (or what the user thinks about it) and without checking (testing) with the end-user throughout the development process.
Quite frankly, organizations that have been in business for many years (decades) think (with some level of arrogance) to know what the customer wants and how the experience should be – but this arrogance will bounce back with failure: an unhappy end-user will trash the product and its experience if it deemed to be unfit.
A hypothesis statement will require experiments to determine which assumptions are right or wrong.
The first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not considered a requirement until we have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to start listing assumptions is to start from a problem statement. Problem statements are full of assumptions. When assumptions are listed, it’s crucial to select the most uncertain ones.
The main principle of Lean Startup is to expose the highest risk first to learn. The whole team should do the exercise of listing assumptions and hypotheses with the whole team: everyone involved so that you can create a shared understanding from the start.
A hypothesis statement has the following format:
Note: This is a possible format, and there’s no obligation to follow this blindly, as long you understand the purpose, and you have the different elements.
Outcomes (objectives) and metrics
It is essential to focus on outcomes first: what are we trying to achieve and what objectives? What kind of user needs? Instead of directly thinking about features (solutions), we focus on outcomes. When creating the product, the progress will be measured against the outcomes. To measure, you need to define a set of metrics. An excellent approach to this is Objective-Key-Results.
Features (functionalities, stories, …)
Features exist to serve the needs that have been identified. You create a particular feature (solution, functionality, story). It’s essential to have the outcome first defined and think about possible features.
It is essential to know something about the customer, the end-user you’re creating the product for. Personas are a well-known technique to make the end-user visible.
The clue is to approach the creation and validation of personas the lean way: personas are not the output of great research upfront but are created and evolve as the product evolves. Personas created with lots of work upfront and not updated afterwards are essentially throw-away personas: they become useless as soon as they are outdated, and concern a source of waste.
We prefer to create “ad-hoc” or “proto”-personas: these represent the best guess of who is using the product and why. A proto-persona contains the information (demographics, behaviours and needs) of a specific type or segment of end-user relevant to the product being designed.
Lean UX book
Materials in this post are based upon readings on the Lean UX approach.
In any context, objectives (or outcomes) are essential as they give guidance or direction; instead of focusing on solutions.
(Solutions in the broad meaning: a product or service, an improvement, a feature, a functionality, …)
We want to track progress concerning objectives, not only solutions. Quite often, solutions are proposed or defined without an objective in mind. To reach a specific objective, multiple solutions are possible.
When teams are given an objective, they can think for themselves about possible solutions and which solutions fit the best in the current environment (system, product, service, …). In general, teams who own part of the problem statement and the solution space are more motivated, focused, and creative, as they feel ownership.
OKRs = Objectives + Key Results
It is a method of defining and tracking objectives and their outcomes. [Source: wikipedia.org]
Objectives are what the organization or individual want to accomplish, and are typically subjective, qualitative. Objectives can be ambitious, can be challenging.
Key results are concrete, specific, and measurable. They describe how you will accomplish the related objective, and measure whether you accomplished the objective or not.
The clue is that Objectives Key Results can be defined on several levels in the organization: for example, executive management, departments, products or services, teams.
Lean UX = applying Lean and Lean Startup principles to User eXperience.
Remove waste from the UxD process
Too much too often product (software) design and development is document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback, in order to improve our products (software) iteratively and incrementally.
Forget about the overload of UxD deliverables that are created to communicate “specifications” to “developers”. Re-consider and only create those deliverables that truly serve a purpose. We value “making” over “analysis“; we value “building” over “specification“. Lean helps us to focus on flow and to reduce non-value creation (waste).
What do I mean?
Useful deliverables (depending upon your context):
Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
Low-cost prototypes used in user testing
Low-cost sketches, mock-ups, designs, etc
Detailed User Interface specifications (for example including annotations of every screen)
Wireframes of every screen, every screen size
Visual designs of every screen
High-fidelity mockups (not reused in development)
Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true cross-functional collaboration.
True cross-functional collaboration (including designers, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development / release cycles. Agile re-focuses product (software) development on value creation and working products (software).
In every step of the cycle, and from the very beginning, the whole team is involved. The whole team approach aims to create a shared understanding with everyone, all the time. Knowledge, user feedback can be quickly spread and shared, and the team minimises the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).
Apply the scientific method
BUILD > MEASURE > LEARN
MAKE > CHECK > THINK
The scientific method exists for centuries and we are simply applying it to nowadays product (software) development.
“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg
In Lean Startup this is known as the build > measure > learn cycle. This is an on-going process, it obviously doesn’t stop with 1 iteration. We also call this make > check > think.
Lean UX cycle basic
The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:
by first focusing on outcomes (objectives) and next on features (solutions)
by getting in touch with your end-users, observe and measure how they use your products
by focusing on creating valuable experiments to expose risks and uncertainty
by improving whatever you’re making based upon that feedback
by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
by creating products iteratively and not only incrementally
by minimising the total time going through this process
by creating an environment of continuous learning
Learn more about Lean, Lean UX and product development with experiments in follow-up posts!
Techniques to bring UxD and development closer together, why collaboration matters.
The scientific method and product development with experiments
How to organise user testing
How to incorporate validated learnings
Lean UX book
Materials in this post are based upon readings on the topic of Lean UX.
Lean UX is about apply lean principles to User eXperience.
There are 2 main observations:
Bad UX. Failed products.
Unfortunately, there are still too many (software) products and services built and released on the market, that do not fit the customers’ needs. This is a long lasting pain in software development. Nowadays thanks to modern web & mobile technologies, possibilities are endless. But than again there are still too many useless, badly designed, wrongly understood, misfit products with failed UX.
Search the web for “failed products” and you get a few examples.
Creation of software by writing documents.
The purpose of creating software is to serve the users’ need, to solve their problem, to automate their work, to meet their goal, to be convenient in use. Software is an end, not a goal. The experience has to be right, it must properly function, the experience should be neat and crisp.
Unfortunately, when creating user experiences, many product (software) development teams are organised in a way so that:
UX people “produce” the “UX” and create a document, a deliverable (“the UI/UX spec“). “The spec” is delivered to the developers who will make the wonderful UX real.
Documents do not solve users’ problems; software does.
With the agile manifesto in mind:
Working software over comprehensive documentation
We know and we owe it to ourselves to focus on delivering a working product, to collaborate and to work to the highest standards, and to minimise any unnecessary intermediates (such as “the spec“). So why do still so many teams (agile or non-agile) keep on focussing on “big UX design upfront”?
Applying Lean principles to product creation and UX will help us to focus on creating a right product fit, by creating value, and by minimizing any waste in the process. Likewise agile, likewise lean, Lean UX is a mindset, a process change and a way of thinking how to create the right product in the right way.
The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.
A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.
UX or User eXperience is about the user experience, but also the whole customer experience. It’s more than design aesthetics. It’s the result of the combination of design, interactions, architecture, technology, business goals, etc.
Once upon a time, there was a marketing person with great ideas for a new software application.
He hired a business analyst, who described all those ideas in formal specifications fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created a detailed User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to an available specification and tried to figure out how to connect them to existing infrastructure and systems.
Given the functional specification, a technical analyst created a technical specification and application design to capture all the given information in a deliverable that would make sense as input for development. Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect graphic designs for every screen of the application. A copywriter was sometimes assigned to write on-screen text labels and copy based on the wireframes. And even sometime later, a tester was given the assignment to understand the requirements and write test scenarios.
Development was about to get started!
Sometime later, during development, some concerns arose about the application’s User Interface, and a usability engineer reviewed the User Interface specification to give some advice and remarks.
So, what do we observe?
The work goes sequential
Individuals doing their own thing, producing output: deliverables, documents!
Time passes by
Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation
The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?
Focus on outputs, not outcomes. People are appreciated for their output: mainly documents and the quality of those documents.
Those documents are written by an individual or a group of individuals of the same expertise – documents are passed on (with or without explanation). The output of one phase is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each needs to re-interpret the previous work—no real sense of ownership.
It’s a very time-consuming process. From inception to the actual start of development, it can take months – depending upon the size of the project.
Assumptions, lots of assumptions! Hypotheses based on those assumptions. As great as it might be, a requirement spoken by the guy from marketing remains an assumption until proven by the market: feedback from actual end-users: the customer.
There is little to no opportunity to react and correct the design of the new software application when new insights or market conditions come up meanwhile developing.
Probably the whole process is overseen and controlled by a commanding officer.
Where’s our marketing person? Out of sight
A chain is only as strong as its weakest link.
Teams used to a sequential process have become accustomed to handoffs between specialists. Each group passes off their work to the next group. These handoffs include overhead in meetings, documents to review and approve, waiting time, etc. Anything that does not directly contribute to the project’s goal: creating software is waste.
Once upon a time, a marketing person had a great idea for a new software application.
The sponsor gathered a team with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team formulated the new application’s business goal and desired business outcome with the marketing guy. Together, the team made this set of skills, not an individual, for each required expertise.
The team focused on the outcomes that would address the primary customer need of our application. The idea was conceptualised lightweight: the team formulated some hypotheses: valuable features that they considered a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next, the team draw some UI sketches on paper. The team set out a test by linking the UI sketches to an “interactive” prototype for internal validation. Considering the received feedback, the team refined that small set of features to a user story level with the main acceptance criteria.
The team decided to prototype directly in HTML/CSS as this was the preference of the web developers. The team organised a user test with key customers and external (non-customer) people. These tests and the earlier defined metrics concluded and prioritised several improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed-upon decisions), They improved the prototype and discussed a subsequent set of functionality.
Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with actual back-end data.
Over time, the team improved the product with customer feedback. They included new insights, dropped a few – previously considered “must-have” – features, and integrated a new online service that appeared to be an excellent fit for the solution.
So, what do we observe?
The focus is on creating working software; that’s what we care for!
Documents do no solve user’s problems, working software does.
The focus is the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs, and in that problem space, possible solutions (hypothesises) to address those user needs are presented and challenged.
Feature development is prioritised. There’s no all-inclusive upfront analysis, and there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges, or instead, there’s a good design upfront.
We eat the elephant in small chunks, but we prioritize the chunks.
The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected, and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.
Instead of an open-loop system, the project is organised as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.
What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are established and are self-explanatory in terms of logic.
Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery iteratively and incrementally.
getKanban is a board game that enables you to learn and practice Kanban in software development.
Kanban is Japanese. “Kan” translates visual and “ban” means card
Kanban is a process tool
Kanban works as a pull mechanism (as opposite to a push mechanism)
Kanban visualizes flow
Kanban limits work-in-progress
By limiting work-in-progress, bottlenecks in the flow will become visible
By visualizing bottlenecks, there’s an opportunity to improve the process flow (to remove the blockages, to remove waste, and as a consequence, to better match capacity with demand in the different stages of the flow)
Kanban applies control by measuring lead and cycle times – by improving the flow, you can enhance those lead and cycle times and optimize the flow to get work at a higher rate through the flow.
Kanban originates from lean manufacturing. A kanban card is a message it signals the depletion of goods (products, parts, inventory) to an upstream part of the process.
Conceptual diagram of a Kanban system; http://files.iquijada.webnode.es/200000139-034270535c/Kanban4.png
When received, the kanban card triggers the production requests of those goods. Therefore, the consumption of goods drives the demand for more needed goods – so kanban enables a demand-driven system (a pull system). A demand-driven system aims to minimize (or even eliminate) inventory, just-in-time production, higher flow throughput, and therefore aims companies to become more efficient. Lean manufacturing specifies the number of forms of waste and origins of waste.
Kanban comprises a set of straightforward rules, but (by years of application in lean manufacturing and almost a decade in software development) it has demonstrated its powerful ability to trigger self-reflection, collaboration, and process improvements. It has its roots in lean. Lean thinking’s pillars are respected for people and Kaizen.
The game setup consists of a board, a stack of cards (backlog items with a specific value and effort to complete for analysis, development and test), several workers (analysts, developers, testers), and the necessary charts (financials and Cumulative Flow Diagram).
When playing the game, you quickly learn about the pull mechanism, the effect of limiting work-in-progress and use of the fast-track (expedite) lane and specific impediments (problems, interruptions …).
The start of the game is on day 9 of a project (the context is a web application development with a customer-subscription based revenue model) – so you enter the game with some items in progress. The game can be played in quick play (till day 15), standard mode (till day 21) and advanced mode (till day 24).
The initial state looks like this:
As you see, the work-in-progress limits are respected:
Maximum 4 cards (items) in the ready column (stage of the flow)
Maximum 2 cards in analysis
Maximum 4 cards in development
Maximum 3 cards in test
No maximum in ready to deploy
No maximum in deployed (which basically means “finished”)
Now it’s up to the team to evaluate the state of the board; the game is played as follows:
Assign workers to the different phases (analysis, development, test) – dice represent the workers. The number you throw with the dice gives you the number of effort units you can do for a particular phase, and you consume these on the items on that respective column on the board.
Items are pulled through the flow starting at the end of the flow (so from the far-right column: deployed). As you spend your effort points (dice points) on items, you will subsequently pull items through the flow, but pay attention to respect the work-in-progress limits.
At the end of the day:
Read the event card (the event may be positive or negative)
Add the numbers of the Cumulative Flow Diagram (CFD)
Tick off end of the day
Cumulative Flow Diagram
A Cumulative Flow Diagram is a tool used in queuing theory. It shows the evolution of the flow in its different stages and the queue of items built up before each step. It shows the size of the queue (vertical line) and the lead time (horizontal line). Lead time indicates the time from request till delivery. Cycle time starts when actual work begins on the request and when the item is ready for delivery.
Every 3rth day (day 9, day 12 …) it’s billing time.
You deploy read-to-deploy items
You cash-in your newly earned user-subscriptions (newly deployed features attract new customers) (new subscriptions gained are written on the back of each card)
You replenish the ready column with items from the backlog (respecting the work-in-progress limit) (because only every 3 days the product owner is available)
The expedite lane is used to fast-track an item to delivery.
This lane has a work-in-progress limit of its own – an item in this lane does not count for the regular column work-in-progress limits.
Only items with a fixed delivery date flow through this lane
Delivering such an item too late results in a fine
!!! SPOILER ALERT !!!
You have several manipulations at hand:
Assign the workers (dices) – for example you can decide to assign a work outside his speciality (e.g. a developer to analysis or test); as in real life, a person working outside his expertise will be less productive.
Decide upon the number of items in the flow (the work-in-progress limit is an upper limit) (take care you cannot as such change the limit itself)
Prioritize the items in the backlog
Look at the effort required to complete of each item
Look at your metrics and use this data
And as such limit the work in progress, try to avoid bottlenecks, try to reduce lead times
Decide to deliver any fixed-delivery date items or not, if yes, decide the right time to handle these
A blocker might occur (via an event card). This will influence the flow. For example, it might break the work-in-progress limit (because a team has decided to do so). It might black a specific item (in the form of a block that must be resolved first).
“Kanban for skeptics” is a book describing the purpose of Kanban and withdrawing any arguments against or any misconceptions. In general, folks regularly have misunderstandings regarding concepts, frameworks, and methodologies… in that perspective I like the intention of the book.
Some might say the book is not a traditional explanation to a subject, which is the case – on the other hand that was not the intention of the book. If you’re new to Kanban, I do think you learn quite a lot by reading this book. I also think the arguments and explanations given are quite useful and make sense (at least to me). It does show the power of Kanban as a process improvement and change management tool.
In summary and my key take-away: Kanban is in essence a change management approach and vehicle (I don’t like saying a “tool”).
Kanban leads to establishing a continuous flow based on a pull system, by limiting the number of items in progress and subsequently forcing an organization to implement sustainable process improvements. Limiting the work-in-progress surfaces the obstacles in a current progress (cf. the powerful lean metaphor of rocks in the lake).
The goal of Kanban is to maximize end-to-end flow efficiency by removing bottlenecks, redesigning the process flow when necessary and focusing on delivering work fully completed. The aim is to make the flow well-balanced, so that the stages in the flow are close to the defined throughput limits. Control is exercised by an approach of monitoring and measuring throughput times (lead and cycle times) (and not estimations). Delivering steady business value occurs when a continuous flow is in place that consistently delivers work items finished on a regular basis at a speed that matches the needs of the organization.
I’ve noticed clear similarities between Kanban with other agile frameworks (i.e. Scrum):
The goal is to deliver business value, based upon customer demand (in Scrum: value is managed by the product owner)
The team pulls work from a single source: a list of work items (i.e. a backlog or queue).
One defines a set of rules to define when an item is considered ready to be pulled into the flow (definition of ready): in Kanban: you can set the rules per stage of the workflow
Transparent way of tracking progress
Lean rocks-and-lake principle: impediments and obstacles in processes will become painfully visible – this triggers the need for change and facilitates organizational change
It leads to better processes, by incorporating feedback and by building upon a momentum to improve a process (as in a Scrum’s retrospective)
It leads to better collaboration in an organization (if you want to improve, you’ll need to break out of your organizational unit/silo) (Scrum: resolving organizational impediments + cross-functional team work)
Kanban limits work-in-progress by process step, by lane. Scrum limits work-in-progress by sprint.
I’ve noticed differences Kanban with other agile frameworks (i.e. Scrum):
Kanban works with measurements – no estimates (note: in agile there is a stream of thinking to work without estimations: on the contrary, the Scrum guide does specify that a product backlog item must have an estimate)
A flow in Kanban is measured by lead / cycle times; in Scrum you measure by done work compared to planned work (velocity of a team)
Kanban is less prescriptive compared to Scrum (not that Scrum is very prescriptive, in my humble opinion; at least compared with traditionally project/process management methodologies…)
Kanban focuses on fully done work (due to the work-in-progress limits); in Scrum the teams defines itself their meaning of work done (note in Scrum the goal is to deliver actual working software at the end of the sprint)
Kanban starts from the existing process; Scrum does pre-scribe a specific process with specific roles and responsibilities. Kanban does not require you to change your organizational way of working to get started.
I’ve noticed that you can incorporate many agile techniques into Kanban – although Kanban does not prescribe it – this is optional and depending what fits the needs and the context:
Prioritizing the input queue (Scrum: product backlog) – this is a good practice as it enforces the stakeholders on focusing on the value of items in the queue
Planning with relative estimates (estimate by comparing items)
Planning by having relatively well-sized features (INVEST)
Introduce iterations > regular cadence (iteration as a heartbeat)
Daily scrum > team coordination
Cross-functional team (instead of silo-teams) – by defacto in Scrum
Build a minimal viable product (to start learning as fast as possible and to improve your product based upon real user feedback) – this is a lean concept; but anyhow considered a recommended practice for product development
Any choice of adding a particular practice is situation and context dependent and must be done with consideration.
All this confirms for me that Agile and Lean are blending philosophies.
The questions and reflections I had after reading this book:
To enforce work-in-progress limits in Scrum (when necessary)
Some general recommendations how to reach a steady continuous flow?
When precisely to adjust the work-in-progress limits?
Small notes: since the writing of this book, some minor, but important modifications have been done to Scrum:
– a team forecasts the amount of work it can do in the next sprint (it does not commit anymore)
– a burndown (or burnup) chart has become optional
“Lean coffee” is een meet-up format waarbij de agenda door de aanwezigen bepaald wordt:
elke participant kan items voorstellen om te bespreken
elke participant kan stemmen op de items; de items komen aan bod in de volgorde volgens de meeste stemmen
de discussie tijd is beperkt (vb. initieel 8 minuten)
stemmen: nadat de tijdspanne voorbij is, kan elke participant aangeven wat hij er van vindt (goed => verder gaan met de discussie, middelmatig, of slecht)
als er consensus is om hetzelfde item verder te bespreken, kan dit, maar met een kortere tijdspanne (vb. extra 5 minuten); anders gaat de discussie over tot het volgende item
in een kanban (in zijn meest eenvoudige vorm: “to discuss”, “discussing”, “discussed”) hou je een overzicht bij van de flow van de items
de aanwezigen kunnen notities nemen, indien gewenst
(optioneel) op het einde van de lean coffee, kan je de belangrijkste bevindingen distilleren
Lean coffee kanban
Voor meer info over de “antwerp lean coffee” (georganiseerd door Patrick Steyaert en Arlette Vercammen), bezoek antwerp.leancoffee.org (in tegenstelling wat de naam doet vermoeden, gaat dit op verschillende locaties door en niet enkel in Antwerpen).