Month / November 2015

by Frederik

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 →

by Frederik

Assumption-driven development: hypothesis writing

THINK: assumptions and hypothesis

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.

Hypothesis statement

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:

Hypothesis
Hypothesis

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.

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

Resources

Lean UX book

Materials in this post are based upon readings on the Lean UX approach.

Lean UX (Jeff Gothelf)
Lean UX (Jeff Gothelf)

Lean UX book by Jeff Gothelf.

Read more about the Lean UX cycle.

Read more about the Lean UX book.

Lean UX (Jeff Gothelf)
by Frederik

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)

[youtube https://youtu.be/F4Mry7L-vwM]

by Frederik

Objective Key-Results

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.

Objective Key Results
Objective Key Results

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.

How Google sets goals

 

by Frederik

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 is simulations / (serious) games/workshops, simply because 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 problems. Some of those practices do originate in agile/lean; others have been recognised as agile/lean because agile/lean people often use these 🙂 Some of the practices have existed for a long time! 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 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, and budget are the product owner’s responsibility. Specific team impediments should be reflected in 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. The team itself must take on some actions, 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. Also, You should carefully choose words 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

Resources:

Causal-loop diagrams (by co-learning)

A causal loop diagram is a causal diagram that aids in visualising how different variables in a system are interrelated. (wikipedia.org)

You can use Causal-loop diagrams to analyse how the system will behave when changing variables or 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