Posted on

Pre-Mortem in action

Over on the inevitable blog, Cara Turner gives a great description of a Pre-Mortem exercise she conducted with an Agile development team.

Excerpt:

Introduction to the team:

This is a slightly different retrospective activity, that looks forward not back, but as if we’re looking backward. We’re going to pretend we’ve come to the end of the next sprint, and it’s been a miserable failure – everything that could have gone wrong did.

At this point the team flinched a bit – I had to emphasise that the idea is to find out what went wrong, so not to focus on the feeling so much as the causes.

 

Read the post here.

Posted on 5 Comments

Pre-Mortem

Spooky!

Object of Play

Often in projects, the learning is all at the wrong end. Usually after things have already gone horribly wrong or off-track, members of the team gather in a “postmortem” to sagely reflect on what bad assumptions and courses of action added up to disaster. What makes this doubly unfortunate is that those same team members, somewhere in their collective experience, may have seen it coming.

A pre-mortem is a way to open a space in a project at its inception to directly address its risks. Unlike a more formal risk analysis, the pre-mortem asks team members to directly tap into their experience and intuition, at a time when it is needed most, and is potentially the most useful.

Number of Players

Any, but typically small teams will have the most open dialogue

Duration of Play

Depends on the scope of an effort; allow up to five minutes for each participant

How to Play

A pre-mortem is best conducted at the project’s kickoff, with all key team members present and after the goals and plan have been laid out and understood. The exercise starts with a simple question: “What will go wrong?” though it may be elevated in phrasing to “How will this end in disaster?”

This is an opportunity for the team to reflect on their collective experience and directlyname risks or elephants lurking in the room. It’s a chance to voice concerns that mightotherwise go unaddressed until it’s too late. A simple discussion may be enough to surfacethese items among a small team; in a larger group, Post-Up or list generation maybe needed.

To close the exercise, the list of concerns and risks may be ranked or voted on to determine priority. The group then decides what actions need to be taken to address these risks; they may bring these up as a part of ongoing meetings as the project progresses.

Strategy

Conducting a pre-mortem is deceptively simple. At the beginning of a project, the forward momentum and enthusiasm are often at their highest; these conditions do not naturally lend themselves to sharing notions of failure. By conducting a pre-mortem, a group deliberately creates a space to share their past learning, at a time when they can best act on it.

The source of  the Pre-Mortem game is unknown. It’s similar, and related to, the Innovation Game: “Remember the Future” designed by Luke Hohmann.

Posted on

What could go wrong?

This post written by guest author Clifton B. 

A while back I was working with a friend’s startup, building a web app that helps small businesses connect with their customers without having to pay for dedicated customer service teams. Still in the proof-of-concept stage, the developers had been wondering whether to introduce a handful of premium services to their product for a some time, but didn’t know how they should decide whether or not to take that leap.

(Because this startup is still a little stealth, I’m not allowed to say who it is, or much more than the description above. But that should be enough for this article.)

I tackled this problem by combining two activities I’d recently learned about, one from Gamestorming, which had just left the presses, and one my friends Barbara Holmes and Jeanne Turner at ISITE Design had been polishing and presenting at various meetings and IxDA events: user journeys.

Walking EVERY mile  in your user’s shoes

Considering each step your users will take toward a desired outcome—from awareness of the product or service to becoming a loyal customer—is instrumental in design a pleasant experience, as Barb points out in her article, Mapping the Customer Journey. The customer (or user) journey is a great way to visualize real-life scenarios that could potentially stand in the way between winning and losing a potential user.

But this wasn’t just about designing a great experience. It was about determining whether we should even start building a premium tier to validate a paid service. So I turned to Gamestorming, and found the Pre-Mortem game, a clever twist on the post-mortem summaries we’re all used to seeing at the end of a project.

Pre-Mortem is a simple, straightforward activity meant to identify potential problems before they happen, and start thinking about how they can be avoided. I decide to combine the concept with the user journey, and came up with something I’m actually pretty proud of.

The cyclical user journey

We decided to walk through the four phases of the user journey we’d identified, Awareness, Consideration, Purchase and Renewal, and came up with reasons throughout our personas’ journeys that might prevent them from becoming happy, loyal customers. We wrote short user stories to illustrate our customers’ desires and concerns along the way.

Cyclical User Journey

Why cyclical? Since this would be a recurring cost to our customer, we would need to make sure we’re addressing her needs even after she decides to start paying for the service. So after the Renewal phase, we revisit Awareness, considering not only new features we’d be implementing, but a shifting roster of competitors as well. You’re never finished selling to your users, even after they’ve paid.

Paving the way to engagement

After laying out the phases of the journey, we came up with reasons why the user would abandon the product at any time. Each cause for lost customers was countered with possible actions we could take to keep them around. While the cyclical journey implies all four phases cycle endlessly, with this diagram we treated the Renewal phase as the point where recurring payments come in, abandoning the cyclical approach for a step-by-step analysis of each phase.

Projected User journey

A quick illustration at each phase shows the path of a happy customer, who decides to stick with the product, and that of a customer who decides to leave before the next phase starts. Every destination has its story, and pinning down the stories that lead to abandonment is the first step in discussing how to better serve your users.

Sticking a fork in it

After determining how much work it would take to keep customers around, the team decided not to go through with this feature set, at least not for now. The service is still young, and while it seemed like an attractive option to have a premium tier with lots of extra features, this exercise convinced us that it wouldn’t be worth the initial investment.

While there’s a chance we could have been the next big thing with this premium tier, I like to think I saved the company a lot of time and money which might have other wise been wasted on this effort. We’re still on the lookout for a feature set that will be worth the effort and might pay off in the long run, but it’s good to know that we haven’t sunk a bunch of time and money into one with such a low chance of success.

Now that I’m running my own startup, Revisu, it’s important to me and my co-founder that we see as far as we can down the journey our users will take in becoming loyal customers, identify potential roadblocks, and deal with them before anyone actually reaches them. Hopefully, if we smooth that road out ahead of time, we’ll have much happier customers in the long run.

Posted on 1 Comment

Gamestorming for Distributed Teams

Gamestorming is an amazing way to improve the performance of teams. Unfortunately, Gamestorming doesn’t work too well when your team is distributed. In this guest post, written by Luke Hohmann (who also wrote the foreword to Gamestorming and his own nifty book, Innovation Games), Luke will describe some of the tools his company has created to enable distributed teams to gain the benefits of serious, collaborative play.

Framing the Games: Computer Supported Cooperative Work

Researchers in the field of Computer Supported Cooperative Work (CSCW) typically organize work as a grid in two dimensions. The first is time: either your doing work at the same time or at different times. The second is the physical structure of the participants: you’re either co-located, standing or sitting next to each other; or distributed, in different offices, buildings, or continents.

Here’s a sample picture. Happy gamestormers in the top left playing Prune the Future. The games described in our respective books occupy this quadrant as they are same-time, same place games. A Scrum team’s taskboard is shown in the lower left. In the lower right, we have a standard mailbox. And in the top right? Well now, that’s a problem for the our intrepid Gamestormer: you can’t easily put a sticky note or index card on your monitor and play games with other people.

But My Team Is Distributed!

Yup. The realities of the modern workforce means that you’re likely to be working in a distributed team. And while it is trivial to say that we’re working in an increasingly global set of team, it is not trivial to say that we’re working with a pretty crude set of tools to help us accomplish our goals. Unfortunately, that leaves people who want to Gamestorm in distributed teams with a lot of questions and not enough answers.

Consider, for example, this post that Dave and Luke wrote together. We agreed to write this together through a combination of email and tweets. Luke then wrote the first draft directly in WordPress. Dave edited this. And this cycle continued until we published it. According to the CSCW grid, we used  a different time/different place technology. And it worked well enough.

But what if we had wanted to work together on the same document at the same time? CSCW researchers have been working on this for quite some time. For example, in 1968 Doug Engelbart gave an amazing demonstration of shared, collaborative editing over a wide area network (see a great presentation on this, including cool videos, here). In the early 90’s researchers at the University of Michigan created ShrEdit, a shared (collaborative) document editing platform. A more recent example is EtherPad. These systems, and many others like them, provide excellent platforms for one kind of collaborative work – collaborative text editing.

Unfortunately, shared document editing is not the right kind of solution for distributed Gamestorming teams because each of the games has a unique set of goals, rules, and contexts. However, by understanding the kinds of collaborative goals that motivate Gamestorming, we can design a solution that meets their needs.

Visual Collaboration Games

Let’s focus on one class of Gamestorming games: Visual Collaboration Games. These are any game that:

  • leverage visual metaphors to serve as the “game board”, a guide to participants on the goals / objectives of the game, and a way to provide real-time feedback on the game;
  • use simple rules for structuring the placement “game tokens” (such as post-it notes), including how many tokens can be placed, the meaning of the tokens, and where and/or how the tokens can be placed.

This is an abstract definition, so let’s use two games to illustrate these concepts.

Empathy Map

Empathy Map

In this game, the visual metaphor is a stylized head that helps player develop a deeper, more empathetic, and more personal understanding of stakeholder’s experiences in a business ecosystem. The head is divided into sections based on aspects of that person’s sensory experiences, such as what they are thinking, feeling, saying, doing, and hearing.

Tokens are post-its or other artifacts that are placed on this visual metaphor represent the players best understanding of the person’s real, tangible, sensory experiences. For example, anything placed in the “hearing” section represents what that person might hear and how might hear it. While it is common to use Post-Its for this game, Luke has encouraged in-person players to add physical objects to the “empathy map game board” as a way to capture as much “empathy” as possible.

Prune the Product Tree (also known as Prune the Future)

Empathy Map

In this game, the visual metaphor of a tree is used to represent traditional product and/or service roadmaps. The evolutionary growth of the product or service is captured in the tree, with branches representing broad product capabilities or areas of service, and apples and leaves representing discrete roadmap items. Trees can be identified via various growth areas – “sooner” and “later” or “this year” or “next year”. The physical metaphor of pruning a tree to ensure healthy growth enables players to “prune” unnecessary features from a product or offers from a service portfolio.

No End In Sight To Visual Collaboration

Visual Collaboration Games are one of the most powerful classes of games that exist. And the supply of these games is inexhaustible: every visual image that we use in business can serve as the foundation of a visual collaboration game. Some examples:

Disappointed that your favorite game isn’t listed? Don’t be. While we’re trying to collect all of the games that we can into the Gamestorming wiki, the reality is that if you’re a good gamestormer or Innovation Gamer, you’re going to be inventing visual games as needed for special circumstances. And once you play them in-person, chances are pretty good that you’ll want to play them online.

Sounds Great! I Want To Play ONLINE Right Now!

Empathy MapExcellent! We were hoping you’d say that! Here is another image of the Empathy Map. But this one is special – clicking on this image will start an “instant play” game at www.innovationgames.com. In this game, there will be three icons that you can drag on your online Empathy Map:

  • Smiley Faces: Use smiley faces to indicate what would make your persona happy.
  • Grim Faces: Use grim faces to indicate what would make your persona concerned.
  • Frowns: Use frown faces to indicate what would make your persona unhappy.

Keep in mind that that this is a collaborative game. This means that you can invite other players to play. And when they drag something around – you’ll see it in real time!

Playing Visual Collaboration Games

The benefits of playing in-person, co-located visual collaboration games are considerable. The visual metaphor guides the group in solving a critical problem. You have a shared artifact that captures key aspects of your collective understanding. The results of the game play can be used and shared with others. And many times you don’t have to tell the participants that they’re playing a game, which can be important when introducing serious games to organizations who might be resistant to change. Players can just smile and compliment themselves on having a good time solving a problem.

And now, the power of online games means that we can use the same visual metaphors to enable distributed teams to solve complex problems. We can add semantics to the images so that we know where items are placed. The system acts as a perfect Observer, silently recording every event, so that we can analyze the results of multiple game plays with many distributed teams. And the flexibility of online, visual collaboration means that we’re only limited by what we want to try.

We’re going to be adding more instant play, online collaborative games to the Gamestorming wiki over the next few weeks.

To learn more about how to convert any Doodle or image into an online, collaborative game, read this post.