What Kind of Game Are You Playing?

Alistair Cockburn promotes the model of cooperative games for software development:
Viewing software development as a “series of resource-limited, cooperative games of invention and communication” meets the objectives for an underlying model of our field:
  • It lets us make sense of historical successes and failures.
  • It names at the top priority level a set of topics that are known to be important to project success but do not normally have a place to live in discussions of software development, topics such as community, amicability, morale, talent, trust, proximity, and sufficiency.
  • It offers immediately usable advice to people busy on live projects.
Here's a drawing Alistair uses to illustrate his point:
With business stakeholders we should be playing a cooperative, finite goal-directed game in which each member of the team understand his or her roles, responsibilities and strengths, the desired outcome is clear, the outcome's temporal horizon is relatively close, and our status toward that end is clear each step of the way.
With platforms like a Customer Support/Sales system, Order Management system, eCommerce system, or Business Intelligence system, we are engaged in ancooperative/collaborative, open-ended game.  Each member of the team, in addition to understanding his or her role and responsibility in day-to-day tactical matters, should understand many things about the relevant business processes and technological architecture in which solutions are being developed.  There is no near-term temporal endpoint to this game.  As long as the business survives and continues doing business in the relevant domain, the system will evolve to add value.
A detrimental tendency at both larger system and smaller feature or project levels is viewing them as competitive games that result in only one winner, a zero sum or win-lose game.  We get into that mindset because we limit the available options for arriving at a desirable outcome.  In traditional project language, we view scope, time, and quality/resources as fixed and insufficient to achieve a stated goal.
To get your mind into a different mode for solving software development problems, look at other categories of games in the cooperative, finite goal-directed game space in Alistair's drawing: rock climbing, theater, and exploration, and contrast them with the competitive games, tennis and chess.  When we treat a software development problem as if it were a chess match we determine that the outcome will produce winners and losers.
Getting out of that mindset and into a cooperative/collaborative frame of mind allows us to consider alternate paths, end points, time frames, use of available skills, identification of resources and solutions not previously considered, in order to achieve a highly desirable outcome for all participants.  Rather than setting up one competition after the next, winning some and losing some, we develop teams and partnerships committed to one success after another.


Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

Chatbot Code of Ethics