Valuable failures
SCRUM & LEAN UX | Episode 11
The ‘Scrum and Lean UX’ series discusses the appliance of Lean UX principles and practices in Scrum. All its articles have this theme and can be read on their own.
To those familiar with the game of poker: when beginner players are invested in a hand, they are not inclined to fold when the flop turns out to be a flop. They don’t want to face the loss of their initial investment when there is still a chance, however small, it might return.
Fearing they have made a bad bet, rather than fold and try again, they often do something far riskier: They hope that the turn or river will yet yield something. Alternatively, they hope to bluff their way, hoping it won’t come to a showdown. Out of fear of wasting money, they’ll risk wasting even more.
LEAN UX helps organizations avoid this trap or escape Sunk Cost fallacies. Failing and adapting early is a lot less expensive than failing late when opportunities to adapt have passed. Small experiments that validate (or debunk) hypotheses equals small valuable bets. A big unsubstantiated budgeted project equals a large risky bet. When you ended up in the wrong place when a lot of time has passed and the budget has been spent… boy oh boy…
Failing early is valuable. Pretentiously succeeding is wasteful.
Figuring out the least complex ways to validating those risky assumptions enable teams to pivot timely. This way teams can identify triggers that fail and expand on triggers that work.
It’s unfortunately very common to complete products get build before organizations figure out how to market them. They struggle with how to position the product in the market.
We all experience a mental resistance in throwing things away that have cost a lot of effort, time, and money. Lean UX embraces a mindset where Scrum Teams learn to work on things small enough, requiring only little effort, so that they can easily be thrown away. They learn to expand (iterate) on that which works.
The other tendency we learn to depart from is this: We generally limit our problem-solving capabilities to that which requires the application of our skills as described in our job profile. A software developer will try to solve problems through developing software, a web designer through designing a web page, a marketing specialist through market research.
Creating an environment that’s safe and valuable to fail.
Having tried a few collaborative creative workshops myself I was surprised to learn how easy it can be to validate hypotheses. I experienced that learning what triggers can be achieved without any digital design or development, elaborate market research, or worn out pre-studies, discovery, or design phases.
So rather than creating rich marketing personas, write a few proto-personas together on the back of beer coasters. Draw lots of paper wireframes or paper prototypes together. Setup a one-pager with a style-guide over an exhaustive interactive design phase. Conduct real in-person customer, user, stakeholder interviews and involve them in this process. Create fake doors (aka ‘feature-fakes’).
All this goes against yet another one of our natures. We feel like scribbles, quick sketches and fake features feel imperfect and amateurish. We feel like the very act of having to throw something out is wasteful. We forget these are great ways to learn and adapt fast and there is value to it. What might start as a rough scribble could develop into a rich evidence-based persona as more is learned?
Here is how our Scrum Team approached creating an environment where it is safe to fail through an adaptation of a Design Studio where the whole team is involved. It doesn’t just make failure fun, it makes it worthwhile.
- Pitch! the goal, business problem, mission, or vision statement is phrased.
- Dream & explore. Determine the format. For example proto personas, hypotheses, user stories, drawing wireframes, drawing paper-prototypes, mood boards, storyboards, interviews. Members have time to work out their approach. Look stuff up, steal good ideas from the internet, ask questions, whatever.
- Sketch! This is when members either themselves or by teaming up create drafts of the format agreed upfront.
- Assign ‘hats’. During the ‘hats’ round, each person or group is given a short time-box where they ask questions and provide feedback on others’ sketches from a certain stance/perspective. We used smiley stickers that represented a personality.
- Polish or trash. During these rounds the group either polishes and/or votes to trash drafts.
- Continue? The team votes/decides if it has (good) enough input to end the session or to run another round.
To facilitate this session, some special rules apply. The facilitator should coach participants to adhere to some dos and don’ts:
Do…
- Time-box.
- Stay on-topic (goal/business-problem).
- Yes, and!
- Use an imaginary remote control: pause, play, rewind, record, etc.
- Ask lots of why’s.
- Expand on others ideas.
- Make something crazy even crazier.
- Be respectful.
- Listen.
- Encourage.
- Agree to disagree.
- Thank each-other for feedback.
Don’t…
- Criticize a person.
- Say something is a ‘bad/stupid/dumb/boring’ (etc).
- Let only the ‘creatives’ sketch and pitch.
- Follow the ‘HIPPO’ (highest paid / most important person in the room).
- Actually throw away the ‘thrashed’ drafts. As more is learned, something could be revisited.
- Try to make it perfect.
- Get distracted.
This can also make for an excellent Sprint Review. Try running this together with Stakeholders where the increment is demonstrated/pitched and new stories are written/drawn/discussed.
The same format can be applied at a larger scale. Moving from one hour to half-a-day > day > week… from paper versions to an actual working increment. Build… Measure…. Learn!
tip: Apply 1-2–4-all liberating structure format: moving from individuals to pairs to fours to all.
Rainy Days
Such creative collaborative events can also be setup so the Scrum Team can discover the ‘rainy day’ scenario’s.
We can’t always prevent the rain, but we may be able to turn a user’s frown into a smile.
A somewhat similar example of turning a frown into a smile (what many of us internet-geeks are familiar with) is Googles ‘unable to connect’ t-rex game.
Conclusion
Lean UX helps Scrum Teams to be more creative to discover spectacular ways to fail fast. It also helps teams convert failure to a fun experience. Small failures help us move from terrible assumptions to better experiences. It requires the facilitation of a safe environment where rough ideas and drafts are valued and it’s easy to throw stuff out. It requires the ability to run ‘small controlled experiments’ as a team.
Next up:
