Kudo Cards – Management 3.0

A thank you is great, but showing appreciation to colleagues, friends, and family for something they’ve done for you is even more satisfying! In a professional context, showing gratitude is happening too little for different reasons: it’s uncommon (regarded as not done, not part of the culture, etc.). Although said and proven in research, showing gratitude is a tremendous intrinsic incentive: this is essential to keep your employees motivated! Organizations should be as aware of intrinsic motivators as extrinsic motivators.

How can we achieve this?

Continue reading →

Open space

Een “open space” is een format om een bijeenkomst te laten doorgaan.

Kenmerkend voor een open space is dat er op voorhand geen agenda bepaald is, en geen specifieke doelstellingen. Een algemeen thema, onderwerp of context is er meestal wel.  Een kader bepaalt de richting, maar is op zich zeker geen beperking voor de onderwerpen die aan bod kunnen komen. Initieel is er dus geen agenda. Een gedetailleerde agenda wordt als contraproductief aanzien. Bij aanvang kan iedereen wel een onderwerp suggereren.

Een open space kan men toepassen voor verschillende soorten bijeenkomsten: tijdens een conferentie, een congres, community evenement, eigenlijk voor gelijk welke meeting –  zowel in een professionele of niet-professionele context.

De mogelijkheid om een open space te organiseren is er altijd, maar veel zal afhangen van de cultuur. Sommigen doen soms smalend over “meetings zonder agenda”, echter onder de juiste condities is het een krachtige techniek voor samenwerking en discussie.

Harrison Owen beschreef begin jaren 1980 de “Open space” technologie.

Hoe een open space organiseren?

Continue reading →

Lean Startup – Playing Lean

Lean Startup

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.

Continue reading →

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 the 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 right or wrong assumptions.

The first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not a requirement until we have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to list assumptions is to start with a problem statement. Problem statements are complete with beliefs. When assumptions are listed, selecting the most uncertain ones is crucial.

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 entire 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; there’s no obligation to follow this mindlessly as long you understand the purpose and 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 define the outcome first and think about possible features.

User assumptions

It is essential to know something about the customer, the end-user for whom you’re creating the product. 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 made with lots of work upfront and not updated afterward are essentially throw-away personas: they become useless as soon as they are outdated and are a source of waste.

We prefer to create “ad-hoc” or “proto“-personas representing the best guess of who uses the product and why. A proto-persona contains the information (demographics, behaviors, 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.

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. Multiple solutions are possible to reach a specific objective.

When teams are given an objective, they can think about possible solutions and which fit best in the current environment (system, product, service, etc.). 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 wants to accomplish, typically subjective and 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 achieved it.

The clue is that Objectives and Key Results can be defined on several levels in the organization: for example, executive management, departments, products or services, and teams.

How Google sets goals

 

Lean UX cycle

Lean UX cycle

Lean UX = applying Lean and Lean Startup principles to User eXperience.

 

Remove waste from the UxD process.

Too often, product (software) design and development are 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 to improve our products (software) iteratively and incrementally.

Forget about the overload of UxD deliverables created to communicate “specifications” to “developers.” Re-consider and only create those deliverables that genuinely serve a purpose. We value “making” over “analysis“; we value “building” over “specification.” Lean helps us focus on flow and reduce non-value creation (waste).

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and style guide (by preference a living style guide, to minimize maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mockups, designs, etc

Overhead deliverables:

  • 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 minimize the “upfront” creation of large UxD deliverables to be handed over to developers; instead rely on true cross-functional collaboration.

Cross-functional collaboration

True cross-functional collaboration (including designers, UX people, usability engineers, developers, product owners, business stakeholders, marketers, 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).

The whole team is involved in every step of the cycle from the very beginning. The entire 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 minimizes the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).

Apply the scientific method.

BUILD > MEASURE > LEARN

or

MAKE > CHECK > THINK

The scientific method has existed for centuries, and we apply it to modern 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
“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 ongoing process that obviously doesn’t stop with 1 iteration. We also call this make > check > think.

Lean UX cycle basic
Lean UX cycle basic

The only way to create products (software) that matter for your end-users, which means a difference, that serves their needs is:

  • by first focusing on outcomes (objectives) and following 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 on that feedback
  • by building upon collective knowledge and wisdom and letting the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimizing 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 organize user testing
  • How to incorporate validated learnings

Resources

Lean UX book

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

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

A few articles

True cross-functional product development

Cross-functional” collaboration in (agile) product development means that the whole (complete) product “development” team is participating. Scrum talks about a “development” team without distinction of role. As such, “developer” means any competence or skill required to create the product or service, not limited to “programming” (writing code).

Lean UX heavily promotes the whole product development team participating during the complete product development cycle from the very beginning. The entire team approach aims to create a shared understanding with everyone (all team roles) from the start and to minimize any waste originating from working in sub-teams or silos (hand-overs, intermediate deliverables, re-discussing the same topic with people who didn’t participate, etc.).

Shared understanding
Shared understanding

True agile teams (feature teams) are product-oriented and can implement product features end to end, creating value pieces with every item done. Collaboration with all team members is an excellent source of creativity, new ideas, and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, participate in work outside their main domain, and help create that necessary shared understanding to deliver value within an iteration.

Teams working in a phased approach (the so-called staggered sprints) face several worries – this should not be accepted as standard, and such teams should strive for a better working method. A phased approach is some work done in a sprint before the “development” sprint (or, even worse, acceptance or testing after the” development” sprint).

Staggered sprints
Staggered sprints

The challenges with this phased approach are:

  • Sprints become out of sync
  • Iteration without agility
  • Lack of ownership among the developers
  • Groupthink
  • Waste (hand-overs, intermediate deliverables, etc.)

The (single) (proper) Scrum team approach has numerous benefits:

  • Understanding of concepts and users’ needs among all team members
  • Improved time to deliver (precondition is to provide chunks of value you are able to implement within a sprint)
  • Less re-work, less waste
  • Improved definition of done
  • Sense of ownership amongst all team members

And so, we urge you to reconsider any extensive upfront work (before “construction”) and try to create a shared understanding with the whole team. That shared understanding will lead to a willingness to collaborate within the same sprint. You foresee a regular cadence of user tests in the Lean UX approach. The aim is to create a “test everything” culture: we test what’s available, and given the users’ feedback, we improve (we iterate).

Real sprints
Real sprints

Sources: