The Proposal

It’s happened to all of us. The first thing we think of…ain’t the best we can do. It doesn’t address all the needs, or it’s overly complex, or it performs poorly, or any of a number of things. The Devising Game is an attempt to get through three options quickly and collaboratively, to improve the quality of our solutions.

Here’s the gist:

The Roles

• The Director (or Captain, or Navigator, or…): Develops the initial requirements, and selects the solution. The Director must also be available to answer questions while the Collaborators are devising.
• The Collaborators (or Team, or Mob, or…): Devise a set of three solutions meeting the requirements, and present them to the Director. This should be a cross-functional group with all the skills needed to devise the proposed solutions.

The Process

• Craft the Requirements: The Director crafts the first draft of the requirements.
• Requirements Review: The Director presents the draft requirements to the Collaborators, answers questions, and uses feedback to adjust the requirements as necessary.
• Devising: The Collaborators sketch out three separate solutions meeting the requirements. During this process, they can ask further questions of the Director and suggest additions/modifications to the requirements.
• Solution Selection: The Collaborators present the three solutions to the Director. The Director then selects a go-forward solution. It can be one of the three options presented by the Collaborators, or it could be a melding of elements from multiple options.

The Requirements

• Title: This should express the problem to be solved. It might be written in the standard user story format: “As a < type of user >, I want < some goal > so that < some reason >”
• Intangibles: Soft requirements that are difficult to measure. “The user will be wowed by the ease of use.” “Developers will be relieved to discover how maintainable and extensible it is.” “A salesperson can demonstrate it and quickly communicate the value to the customer.”
• Tangibles: Hard requirements that are verifiable. “The user must opt-in before getting access.” “The solution must support peak loads of 500,000 transactions per second.” “The purchase flow must include: items review, billing information, delivery information, final review, and confirmation.”

Discussion

The Devising Game can be adapted to all levels and aspects of our work. From product idea generation, to UI designs, to code design, to testing strategies, to build and deployment tooling, to process improvements.

At its core, it’s an attempt at encouraging lateral/innovative thinking when problem solving. To fully realize that benefit, you should consider the following before you start.

For the Collaborators:

• You should be well-versed in the techniques of Collaborative Decision-making: consensus, range voting, dotmocracy. Choose one. You’ll need this when trimming many options down to three.
• You should only spend enough time on the devising phase in order to sketch out the three ideas. Different problems will require different amounts of time, of course, but the range should be between an hour and a week. No more. If you get to the end of the time period and feel you need more, then fine, take more time. But remember that you’re only picking an option for further exploration. You can (and will) revise the solution as you work on it. In fact, the first thing you should do is poke at the riskiest bits to see if you can make it fails fast. If it does, then try something else.

For the Director:

• You should not be one of the Collaborators. The Collaborators must be able to work as peers and freely pursue ideas without you being in the room. (Although, you should be available to answer questions.)
• It’s helpful if you happen to be the one already responsible for making the choice: e.g., the Product Manager, or Team Lead, or Architect. But if the group doesn’t have someone like that for the problem they’re solving, they should pick someone to be the Director whose decision they’ll be willing to accept.
• When writing the requirements, you should not constrain the solution space any more than necessary. In fact, requirements should remain conceptual wherever possible to serve as inspiration rather than constraint. Where there are real constraints, however, call them them out unambiguously.
• Try to keep the requirements simple. They should be rich and engaging, with as few individual items as possible. The Collaborators will be able to move faster and generate more ideas if they have fewer things to keep in their heads. If a requirement represents some detail that you’re relatively certain could be worked out regardless of the solution, then leave it out. This is the dreaming phase. You can add it back during the implementation phase.
• When reviewing the solutions, you should let the Collaborators present them all without offering comments. Once the Collaborators are done, you should discuss each solution one by one. You should praise innovative thinking, acknowledge risks taken by the Collaborators, and talk about what was learned from each solution — what worked, what didn’t, and what was learned about the problem as a whole.
• When choosing the “go-forward’ solution, thank the Collaborators for their efforts and reminding them that there are rarely right or wrong choices in this work. Often, the most important thing is to choose.

Happy devising!

Giving Credit

I adapted this from the process used for devising new plays by the Portland Experimental Theatre Ensemble — a company of theatre artists in Portland, Oregon who produce some of the most interesting theatre you’re ever likely to see. They started with the “composition” techniques found in the Viewpoints method for training actors, and evolved their process from there. If you want to learn more about it, checkout The Viewpoints Book: A Practical Guide to Viewpoints and Composition. There’s no doubt more gold to mine there.