Games Stakeholders Play

Activity theory explores what is happening inside a person while that person is acting. Use it to make better decisions about what to build, create a motivation map, and ask what else your stakeholders are thinking about besides just using your system.

We have good ways to capture what the users want to do with our systems, but we don't yet have a good way to capture what else the stakeholders are thinking about besides the system's functions. That "what else they are thinking about" drives much of the system's requirements and determines the ultimate success or failure of the system after it's deployed.

To find a structure for determining what else they are thinking about, I went back to the original Russian description of activity theory and connected it to my own notion that software development is a cooperative game of invention and communication.

Games People Play
Activity theory is a century-old psychological framework that rejects the isolated individual as an adequate unit of analysis. As the article on Wikipedia.org states, "each subject may have one or more motives (e.g., improved supply management, career advancement, or gaining control over a vital organizational power source)." That framework shows us how to extend the cooperative game notion to handle conflicting games across stakeholders.

When developing a software system, the team works to deliver running, useful software. Along the way, the team makes moves of various sorts (such as holding a requirements-gathering workshop, doing a stand-up meeting, writing a test, and so on) and employs strategies to get to positions that serve as useful jumping-off points for a subsequent move or strategy. The game is cooperative, in that people help each other improve the overall position of the team.

However, we can't really understand what is happening on the project without taking into account the "side games" that people are playing at the same time. These include insisting on using new technologies that look good on their résumés, bucking for promotion, thwarting rivals, and so on. Therefore, we have to consider the wider set of games the people are involved in from their perspectives .

Let's widen this thinking to include all the eventual stakeholders and the other game boards they are playing on:

• The project sponsor is playing on game boards centered around career growth, relationships with peers, and relationships with other communities (user communities, business partners, etc.). The outcome of the game called "build system X" is evaluated by the sponsor with respect to how his position changes on all those other game boards.
• The programmers are playing on game boards centered around résumé management, technical excitement, peer approval, career advancement, and relationships in their other communities. They have friends who are users, they want to learn new things, and they may want to make themselves indispensable.
• The users are managing their own careers and relationships. In addition—and this becomes important for user interface (UI) design—they are quite likely thinking about something else entirely while using the system. Just think about all the Web browsing people do at work—finding cheap airline tickets, sending photos and emails, and so on.
• The managers above the users may never use the system itself. However, they will use the data produced by the system. The mere existence of the system affects the way the managers negotiate with their business and social communities to advance their department's or their personal position. What gets built affects their ability to make useful moves on these other game boards.

Here are two recent examples I found of using one game board to improve positions in other games:

I