Brainmoda | Staffan Nöteberg’s blog

“Software development is a cooperative game”, manifests Alistair Cockburn. I add on top of that, that if small cooperative sub games are included in software development, then the team members will be more motivated. I’ll show you the rules, ornaments and pros of these tiny games.

Playing develops my mind

Many people think that there is a congenital opposition between working and playing games. Working is lutheranic and producing, playing is lazy but also creative. I don’t feel comfortable with this opposition paradigm. So I rather quote Leonard Cohen when he sings: “There is a war between the ones who say there is a war and the ones who say there isn’t”. There is no war going on? Work vs. Play should be Work and Play.

Tony Buzan wires the opinion that work and play should be two sides of the very same coin. He wrote 2003 in Brain Child about this no-war: “Once again, educational theorists in the late centuries of the last millennium found themselves thinking that they had to either work or play. The twenty-first-century solution is neither to work nor play, nor to do some work and some play. It is to do only one thing, and that is to do them both at the same time! As Heraclitus’ co-philosopher, Plato stated ‘life must be lived as play…’”.

Pulitzer Prize winner James Michener gives similar thoughts about the invisible difference between Work and Play that could be: “One who has mastered the art of living simply pursues his vision of excellence at whatever he does, leaving others to decide whether he is working or playing”. Enjoy your work and it will feel like playing.

And Ken Blanchard, who wrote The One Minute Manager which has sold over 13 million copies and has been translated into 37 languages, is on the same track: “Work is thought of as something that you have to do, while play is something you choose to do. The distinction is more of an idea than a reality, since both require physical and mental energy.”

Ok, so Work and Play doesn’t necessary have to be distinguished. For a software developer, the trick is to put a mental picture where the development is a game. Alistair Cockburn explicated his Cooperative Game Manifesto in 2003: “The game is not competitive, it is cooperative. The game is for the players - the software development team - to help each other complete the software.” And also: “A game consists of a set of moves or movements.”

It’s a well known fact that playing is an indispensable activity for developing a child’s brain. Sharon Begley explained in the Newsweek magazine in 1997 that “A baby is born with a head on her shoulders and a mind primed for learning. But it takes years of experience - looking, listening, playing, and interacting with parents to wire the billions of complex neural circuits that govern language, math, music, logic and emotions.” And Dr. Joe Frost wrote in his paper “Neuroscience, Play, and Child Development” in 1998 that “Play…has earned new respect as biologists, neuroscientists, psychologists, and others see that play is indeed serious business equally important as other basic drives of sleep, rest, and food.”.

I started about tiny games above - games that are booth playing and working, that enables motivation and on the same time add value to your service. I encourage you to add Tiny Games to your process. Try them and then use them or, drop them. They will booth heighten your daily enthusiasm and make the team even more productive.

What characteristics should a Tiny Game have?

There are booth mandatory and also advantageous characteristics for qualifying as a true Tiny Game. Mandatory characteristics are at least the following:

• Simple tools – like pencil, paper, whiteboard, e-mail etc.
• Cooperative – opposed to competitive win/lose games
• Local Thinking – it’s not necessary to have the whole picture in order to participate
• Duration Inexpensive – from ten minute games up to at most one day duration
• Lightest Drum Roll – only a minimum of preparing a game session is allowed
• Self Documenting – no compiling artefacts work afterwards
• Creative – routine tasks are no-no
• Moves and Movements – strategic thinking
• Value Adding – the outstanding criteria

If they also have some of the following characteristics, it will make the Tiny Game even more advantageous:

• Leadership round-robin – many games practise follow-the-leader activities; it’s desirable if the leadership isn’t permanent on one person’s shoulders
• Social Gluing – to glue team members tighter is done with e.g. face-to-face communication, honesty and quick feedback
• Mimicking – imitative games infects other team members with the imitated member’s skills
• Jargon Manufacturing – a team with unique intra team culture is feeling strong
• Time-boxed – or at least time limited, is preferable to goal-seeking like the game is over when a player enters the target door

Here are three examples of Tiny Games:

The CRC card game

Properties: Simple Tools, Cooperative, Local Thinking, Duration Inexpensive, Lightest Drum Roll, Self Documenting, Creative, Moves and Movements, Value Adding, Leadership Round-Robin, Social Gluing, Mimicking, Jargon Manufacturing
Props: Index cards and pencil
Rules: Find a few concepts (classes) that are crucial to your domain. Write them down, one per index card. Ask what the class does as well as what it must maintain. Write that information down as responsibilities on the same card. Define collaborators, either a request for information or a request to perform a task. Write them down on the card as well. Move the cards around so that collaborating classes are next to each other, and that everybody in the team agrees on the denotation of the classes.
Problems solved: Class design and concept awareness.

The Planning Poker game

Properties: Simple Tools, Cooperative, Local Thinking, Duration Inexpensive, Lightest Drum Roll, Self Documenting, Creative, Moves and Movements, Value Adding, Leadership Round-Robin, Social Gluing
Props: Planning Poker deck of cards (can easily be home made)
Rules: A user story is read. Product owner answers any questions from estimators. Each estimator privately selects a card with the number corresponding to her estimate. All selected cards are shown simultaneously. If estimates differ, highest and lowest estimator explains their thoughts for a few minutes. Then re-selection of cards is done by everyone.
Problems solved: Effort estimating without anchoring.

The Daily Scrum Meetings game

Properties: Simple Tools, Cooperative, Local Thinking, Duration Inexpensive, Lightest Drum Roll, Self Documenting, Creative, Moves and Movements, Value Adding, Leadership Round-Robin, Social Gluing, Mimicking, Jargon Manufacturing
Props: Whiteboard – for recording impediments
Rules: The team arrange themselves in a circle. Only one person talks at a time – no side conversations. Moderator asks each member what she has done since last meeting, what she will do between now and next meeting and if anything got in her way of doing work. Moderator is responsible for recording any impediments mentioned in answering third question.
Problems solved: Collective progress and problem awareness.

And there are many more Tiny Games…

CRC (Class-Responsibility-Collaborator), Planning Poker and Daily Scrum Meeting are just three examples of Tiny Games. There are many others not clarified here, like Iteration Retrospective, Lightning Talk, Facilitated Workshop (sometimes called JAD), Sprint Demo, Knowledge Crunching, and Wall of Wonder. Some of these don’t incorporate all the mandatory criteria of a Tiny Game. But, that should only be seen as a challenge for us to improve the rules of them.

I advocate adding Tiny Games to software development working habits. We try them and then use them or, drop them. They will booth intensify our daily eagerness and make my team even more productive.

Additional facts:

• Sharon Begley has received numerous awards for her work. “Your Child’s Brain” earned Begley a Clarion Award from the Association for Women in Communications for “excellence in clear, concise communication.”
• Ellen Gottesdiener coined the term Wall of Wonder (WoW). She portrayed it as “something that combines the art and science of facilitation, customer involvement, and good (agile) requirements development/modeling practices. It is fast, fun and really engages stakeholders.”
• James Michener (1907-1997) was known for his ambitious research behind more than 40 titles. He was raised to be a strict Quaker by parents who he later wrote wasn’t his biological.
• James Grenning, who was the first to describe Planning Poker, was one of the original 17 signatories of the Agile Manifesto.