Recruitment met Lego blokjes

Dat Lego (razend) populair is bij mensen van alle leeftijden, is nogmaals geïllustreerd. Dat Lego heel nuttig kan zijn op verschillende wijzen is ook nogmaals geïllustreerd! 🙂

Heel veel mensen hebben in hun kindertijd met Lego gespeeld (en jawel ik ook!). En heel veel mensen hebben nog een grote verzameling Lego bewaard voor de volgende generatie (nogmaals schuldig). Maar naast het plezier bij kinderen, is er ook een aanpak om Lego te gebruiken voor allerlei doeleinden: educationeel, teambuilding, en ook … recruiting!

(ter info: er bestaat in Lego een reeks speciale blokjes, genaamd “Lego Serious Play“, specifiek voor facilitatie in groepen).

De opzet van deze oefening is een sollicitatie gesprek waarbij de kandidaat iets moet bouwen met Lego blokjes. Het idee is dat tijdens deze oefeningen de “interviewers” de persoonlijkheid, de manier van werken, de manier van communiceren kunnen ontdekken van de kandidaat.

In deze oefening was de opdracht:

  • bouwen van een auto
  • bouwen van een garage
  • bouwen van een terras

Continue reading →


Assumption-driven development: hypothesis writing

THINK: assumptions and hypothesis

Instead of expressing “requirements” we consider assumptions and we 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 services are not sure what a user actually needs or wants, or how it should work, with regard to the user experience. But quite often organizations, or companies simply 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 which 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.

Hypothesis statement

A hypothesis statement will require experiments to find out if which assumptions are right or wrong.

A 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 actually 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 ones that are the most uncertain.

A main principle of Lean Startup is to expose the highest risk first, so we can learn. The exercise of listing assumptions and hypothesis should be done with the whole team: everyone involved, so 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, what kind of 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 be able to measure, you need to define a set of metrics. A good approach to this, is Objective-Key-Results.

Features (functionalities, stories, …)

Features exist to serve the needs that have been identified. To fulfill an outcome, you think about creating a certain feature (solution, functionality, story). It’s important to have the outcome first defined, and next think about possible features.

User assumptions

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 like 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 as to who is using the product and why. A proto-persona contains the information (demographics, behaviours and needs) of a certain 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 topic of Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

Read more about the Lean UX cycle.

Read more about the Lean UX book.

Lean UX (Jeff Gothelf)

Lean UX book (by Jeff Gothelf)

Jeff Gothelf’s Lean UX book is about applying the principles of lean (startup) to User eXperience.

Lean UX (Jeff Gothelf)

Lean UX (Jeff Gothelf)

“Lean UX” is part of the Lean Series: a series of books applying the principles of Eric Ries’ Lean Startup to several domains.

Lean UX applies the principles of both agile, lean, design thinking and lean startup to the process of creating and design any user experience of any product or a service.

“Lean UX” is well-written and has enjoyed attention by many in the UX and lean/agile community. The first edition of the book was published in March, 2013.

Not familiar with agile, lean, lean startup or any of these?

Well, let’s shortly define:

Agile development is a mindset, an approach to product development (and yes, not only software). Agile focuses on delivering what’s valuable for the customer, and makes us work in short time periods. The product is built in small increments, and in an iterative way; meaning we revise, expand and improve the product iteration by iteration.

Moreover, agile stands for a way of working: cross-functional collaboration: all people in 1 team, no distinction between roles. An agile team cultivates and thrives on the mix of everyone’s expertise, open communication, trust, … in other words: real collaborative team work. When needed, an agile organization or company is able to immediately change direction in development (or any other area) at any time, with very low or even no cost.

Learn about the agile values and principles, and check for yourself if you’re really working in agile way.

So, what’s wrong with the way that products (software) are being designed?

Well, in a traditional way of working there exists the waterfall approach: meaning the assumption that upfront work (analysis, specification, design, etc) is required before we can start any construction.

Makes sense, doesn’t it? Let’s be sure and figure out all the details before investing money in construction. The reality proves to be different: most importantly, only when actually using the product or service constructed, you really know and can evaluate its use, its experience. Most of any upfront work done will largely turn out to be waste, because the product or service constructed will require changes to meet the “new” (actual) user needs, meet new market conditions, etc. When using the product (or service), the user finds out what he needs. Hence the plea for an incremental and iterative approach.

The traditional approach to designing a product and its user experience will output many deliverables: wireframes, prototypes, visual designs, style-guides, screen-flows, workflows, etc. Reality shows that many of those ideas and features designed will not make it to the actual final product; and many of those experiences designed (on paper, or even interactively) will require changes when end-users start using the product; or when any constraints arise.

The assumption that the user experience / user interface of a product should be designed upfront (away from construction) in a perfect way is an approach which originates from old habits and a traditional product development thinking. Looking from a lean perspective, this kind of process contains a lot of waste.

The Lean UX book

The Lean UX book shortly explains why Lean UX is needed. Lean UX (likewise agile and lean) itself is a mindset, a philosophy, an approach, an attitude, a way of thinking, a way of working. It defines a cycle, and offers a set of techniques and tactics. For UX people working the traditional way, it will be a considerable change in process and working attitude.

The Lean UX book enumerates the foundations and principles of Lean UX. With design thinking, agile, lean and lean startup in mind, the principles of Lean UX are familiar:

  • Small, dedicated, co-located cross-functional teams
  • Shared understanding throughout the process
  • No gurus, lonely experts; but a whole team approach
  • Progress is measured by outcomes, not by output (deliverables)
  • Focus on problems and solutions, instead of a set of features
  • Remove waste, by minimizing anything in the process that doesn’t directly contribute to value delivery
  • Work in small batch sizes, small increments. Avoiding large quantities of work-in-progress
  • Continuous discovery
  • Interact with your customer, your end-user to get feedback (and to achieve this, you need to get our of the building, get out of your office)
  • Externalize the work: show and tell as much as possible
  • Value making over analysis
  • Value learning over growth
  • Permission to fail
  • Getting out of the deliverables business: less focus on deliverables, more focus on constructing the product (cf. The agile manifesto)

Lean UX cycle

The Lean UX book describes the basic cycle:

Lean UX cycle

Lean UX cycle

THINK: Declaring assumptions and creating a hypothesis statement

How to start from a problem statement, declaring business and user assumptions and writing hypothesis statements.

MAKE: Creating and running an experiment

How to create and run an experiment with end-users. Experiments can take any form: prototypes or non-prototypes.

CHECK: Get feedback and research

How to organize user tests, and how to learn from feedback.

Lean UX and iterative development

In the last section, the Lean UX book describes how to the steps of Lean UX can be integrated in iterations of agile development. The book also describes what kind of organizational transformation and change in mindset are needed to be effective with Lean UX in your project or organization.

Great into video on Lean UX (at BBC)


Objective Key-Results

In any context, objectives (or outcomes) are important as they give guidance or direction; instead of only focusing on solutions.

(Solutions in the broad meaning: a product or service, an improvement, a feature, a functionality, …)

Quite often, solutions are proposed or defined without an objective in mind. To reach a certain objective, multiple solutions are possible. We want to track progress with respect to objectives, not only solutions.

When teams are given an objective, teams have the possibility to think for themselves what are 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, more focused, more creative, as they feel ownership.

Objective Key Results

Objective Key Results

OKRs = Objectives + Key Results

It is a method of defining and tracking objectives and their outcomes.

  • 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.

How Google sets goals

Agile Tour Brussels 2015

Agile Tour Brussels has been a great event, likewise previous editions.

The sessions I’ve attended:

  • Solving impediments with agile/lean techniques (by Ben Linders)
  • Poet’s guide to acceptance testing (by George Dinwiddie)
  • Causal-loop diagrams (by co-learning)

Solving impediments with agile/lean techniques (by Ben Linders)

My preference are simulations / (serious) games / workshops, simply because by ‘doing’ you learn a lot more (and it sticks).

Agile Tour Brussels 2015 impediments game 3  Agile Tour Brussels 2015 impediments game 2

This simulation involves a list of issues (impediments) of different kinds and a list of tools / techniques / practices to tackle issues. Some of those practices do really originate in agile / lean, other have been simply recognised as agile / lean because these are often used by agile / lean people 🙂 Some of the practices exist for long time! Actually, any self-respecting ‘real’ manager should know and apply those practices!

Agile Tour Brussels 2015 impediments game

The goal of the simulation is to discuss the given impediment and to find (one or more) practices best suitable to start solving the impediment. As well, the discussion evolves of who is supposed to take action. Typical areas such as requirements, priorities, budget are the responsibility of the product owner. Typical team impediments should be reflected back to the team by (for example) the Scrum Master (in a Scrum team), and the Scrum Master can assist in exploring how to tackle the issue. It’s important that some actions are taken on by the team itself, so the team learns how to deal with problems in the future.

Poet’s guide to acceptance testing (by George Dinwiddie)

The Given-When-Then format is a style to represent tests and is part of Behaviour Driven Development. The goal of the exercise was to evaluate the level of clearness, (un)ambiguousness of given tests. Frequently tests are filled with clutter, pre-conditions, post-conditions, and other irrelevant information. As well, words should be carefully chosen, to have the correct meaning in the tests. Hence the link with poetry 😉

Agile Tour Brussels 2015 acceptance testing

Smells (warnings) regarding test scenarios:

Agile Tour Brussels 2015 acceptance testing 2


Causal-loop diagrams (by co-learning)

A causal-loop diagram is a causal diagram that aids in visualizing how different variables in a system are interrelated. (

Causal-loop diagrams can be used to analyse how the system will behave when changing variables, or when we are adding a ‘solution’ (or ‘quick-fix’).

The exercise involved the creation of a causal-loop diagram regarding the change of having individual versus shared ownership of a system component. See the example below.

Agile Tour Brussels 2015 causal loop diagram

The variables identified:

  • Quality of the component
  • Quality of the product
  • Level of coherence (holistic view)
  • (number of) Integration issues
  • Level of knowledge sharing / knowledge availability
  • (number of) Organisational silos
  • Level of reusability (maintainability) of the component
  • (number of) different technologies

Lean UX workshop

Creation of proto-personas and hypothesis statements

Agile Tour Brussels 2015 proto-personas Agile Tour Brussels 2015 proto persona Google Glass Agile Tour Brussels 2015 hypothesis statement