Awesome superproblems are large, complex and enduring problems which can only be solved through collaboration, argues Luke Hohmann. The key to making collaboration work is serious games, where participants voluntarily agree to follow the rules of the game to create a better and more durable result.
Luke Hohmann, CEO of Conteneo, will give the keynote Awesome Superproblems at Lean Agile Scotland 2017. The conference will be held on October 4-6 in Edinburgh:
[Lean Agile Scotland] covers the usual broad range topics taking a holistic view of what it takes to make great software products. [There are] sessions that will stretch your thinking, introducing you to new ideas [and] also sessions geared to help those new to Lean & Agile to start the journey.
InfoQ will cover this conference with Q&As, summaries, and articles.
InfoQ asked Hohmann what makes it so hard to solve awesome superproblems, the conditions to make collaboration work to solve problems, and how you can scale retrospectives to enterprise level.
InfoQ: What are "awesome superproblems"?
Luke Hohmann: At present I define an "awesome superproblem" as a problem that has the following characteristics: it is awesome, in the sense that the problem inspires a sense of reverence, fear or awe; and it is "super", in the sense that you cannot solve this problem on your own - you must engage others to solve the problem.
InfoQ: What makes it so hard to solve such problems?
Hohmann: There are many factors that lead to challenges in solving awesome superproblems. Here are a few that standout in my experience.
Perhaps the most prominent is found in how you worded the question: you used the world "solve". That’s like asking if you can "solve" the problem of eating, or sleeping, or going to the bathroom. You might solve it in the moment, but the problem will always come back. It is an enduring problem.
What makes enduring problems awesome superproblems are their scope and scale: budgeting for cities, the future of work, managing shared and scarce natural resources, dealing with climate change. We can’t "solve" any of these. But we need to deal with them - like we need to deal with eating, sleeping and going to the bathroom.
InfoQ: What are the conditions to make collaboration work to solve problems?
Hohmann: I think collaboration works best when we use games and game semantics as the foundation for collaboration. I will use the Innovation Game® Prune the Product Tree as an example in what follows - I invite the reader to use their favorite game or retrospective technique as a test of the concepts.
There is a goal, or something to achieve. For example, in Prune the Product Tree the goal is to shape a product or service to meet the needs of the constituents.
The participants have a clear understanding of the resources at their disposal, their roles and how they can use these resources (the rules of engagement and interaction, including rules about the acquisition and disposition of resources). Continuing our example, the participants in Prune the Product Tree are given a limited number of apples that typically represent product features. However, you can also imagine a variation of Prune the Product Tree in which participants can "earn" more apples if they present particularly compelling ideas.
The participants have a clearly defined space or "field of play" that supports their work. Sometimes this can be in-person with a physical tree; we’re seeing more organizations move online with the Conteneo Weave platform to address challenges associated with distributed teams and scale.
There is clear feedback on the progress to the goal. In Prune the Product Tree all of the participants can see the results.
The results of the collaboration have a material impact on the participants. Prune the Product Tree works best when the participants believe that their feedback will adjust the product or service in question.
The participants are voluntary participants. They aren’t coerced into collaboration.
Note that games are the foundation of the collaboration. Putting this foundation into practice means addressing different dimensions of the multidimensional design space of collaboration. Here are a few of the most common dimensions:
In-person or online: Sometimes collaboration will be in-person, like a single Scrum team engaged in release planning. Sometimes collaboration will be online, when dozens or hundreds of teams are engaged in participatory budgeting.
Team Structure: Teams can be stable or dynamic; homogeneous or heterogenous; based on existing structures of formed in an ad-hoc manner depending on the goals of the designers. Teams can be formed of internal stakeholders or customers/partners and other external stakeholders.
Synchronous vs. Asynchronous Play: The participants can be working together in real-time or can be working over a longer time horizon.
InfoQ: How does volunteering look like in practice?
Hohmann: I find that voluntary participation is easiest when it occurs as a natural part of the culture of the team. A part of culture is the behavioral norms of a team, often expressed as working agreements. For example, the Scrum Guide defines the Scrum practice of Sprint Planning. You could argue that this isn’t "voluntary", but instead "required" when practicing Scrum. In practice, though, teams I coach instantly find real value in a proper Sprint planning session and voluntarily choose to continue the practice. This voluntary participation continues as long as the team is finding value in the collaborative framework - the degree to which the framework enables the group to realize its goals.
Earlier InfoQ interviewed Hohmann about Huge Retrospectives with Online Games where he explained why online games are suitable for large scale retrospectives:
Hohmann: Online games are lower cost, generate faster results, allow retrospectives to be conducted at times convenient for the teams involved and provide better data analysis. The online format allows people who are introverted or who speak a native language that is not the dominant language of the company to better capture and represent their thoughts.
InfoQ: How can you scale retrospectives to enterprise level?
Hohmann: Conteneo has pioneered scalable retrospectives, conducting several retrospectives of a few dozen to more than 60 agile teams. The process is quite straightforward:
Confirm that the leadership of your company seeks to improve performance across multiple teams. Make sure the leadership is aware that the project may identify some fairly thorny, hard to resolve problems.
Identify one or more retrospective frameworks that can help the organization identify opportunities for improvement - Sailboat is a great candidate because it is metaphorical, open-ended and enables teams to identify both impediments and accelerators.
Identify a team of facilitators who will facilitate the retrospectives. Scrum Masters are a natural choice, provided they can manage their inherent biases.
Schedule a retrospective with each team. Our experience is doing this via in-person retrospective techniques takes too long and is too tedious. I strongly advocate using a platform that is designed to collaboration at scale.
Analyze the data across the teams in the following dimensions:
Category: is this impediment associated with people, process, technology or something else? Is there a discernable pattern to the problems and categories?
Scope: is there an impediment that the team can fix (it is within their scope of control and/or responsibility) or is this something the organization needs to address? To illustrate the difference, let’s say an enterprise retrospective identifies a set of important infrastructure changes, like upgrading from Angular 1.6 to Angular 4. If you’ve got one or two teams, coordinating the change should be fairly easy. But if you’ve got 30, 70 or 100+ teams you’re going to need create a project that crosses across all of the teams (an "enterprise scope" project).
Assemble a list of specific changes with cost and impact estimates.
Engage the team by letting them select the impediment they want to tackle.
Get to work!
