I’ve seen my share of Agile transitions. The critical factor in getting all the benefits off one is for me that the whole organization transitions to a more agile way of working. Managers can do a big part in that. My proposed problem for the session was how could we as agile coaches help the managers to transition to the kind of management role demanded in an agile organisation.

As we talked we made several observations about things worth taking into account when trying to help managers get accustomed to the agile way of thinking. I’ve listed them in their own categories below. The categorization is my own and made after the session.

Desired Outcomes

• Build mutual trust between management and developers
• Have common language for managers, business and developers alike
• Safety for middle managers to try different approaches
• Learning is encouraged for managers
• Company culture embraces constant change
• Company culture supports experimentation
• Managers are aware of their authority (are present, listen)
• Peer support and peer coaching between managers

Management Anti-Patterns

• Punishment culture
• Competition between managers
• Project thinking

Techniques to help

• Figure out the managers’ top fears (listen, be present)
• Have an internal management change agent (who knows agile)
  • Suggest hiring that person
• Visualize the benefits of agile (systems thinking)
  • visibility, adaptability etc.
• Offer systems thinking tools to support management decision-making
• Department retrospectives
• Company retrospectives
• Support managers’ learning of coaching skills
• “Walking the talk” – showing a good example

Try this

• Target top management, not middle management
  • middle management does not have say on big changes
• Get rid of middle management (as much as you can)
• Influence top management to change the management structure (=> flatter)

Got any more techniques or things to try? Please add your input to the comments.

Photos of the notes blankets by Olaf Lewitz.

I set up a short session to demo the game. I talked a little about my goals for the game, in short a video game that could be played on one’s own that would introduce newcomers to agile principles and practices. Then I demoed the game and we played it for a while together on a projector. All the while we conversed about the game.

For me the session was a huge success, thanks to the participants. I got the feedback that the problem I was trying to solve with the game was real and worth solving for the participants. By observing the gameplay of the prototype it also came very clear to me that the current prototype was nowhere near a solution to the problem.

Screenshot from First Scrum

The user interface seemed not intuitive enough. There was lots of text and the parser did not understand most of the commands the participants wanted to use. These UI / usability problems effectively nullified the potential positive impacts the game could have.

While some of this could be something that could be solved by polishing the Inform7 code, it seemed to me that an alternative approach could provide more value with less work.

I also got lots of propositions about improvements and added features. While the audience was much too small to draw any immediate actions from these, I was pleased to see that most of them were on the same lines of thought that I had for the future of the game.

So I concluded that the best thing I could do was to start designing a second prototype from scratch. I have some ideas for changes: use a richer and more contemporary UI, something like in Echo Bazaar.  There’s no need to change the fictional content at this point as it is essentially untested. The player actions will have to be more direct and immediately visible, probably some kind of multiple choice would be the most obvious option.

Now it is time to go back to the design board. One other thing that I learnt from this first iteration of game design is that it is important to test the prototype as quickly as possible. I got myself fooled thinking that I wouldn’t be able to test the interactive fiction game until I had made a lot of development work with Inform7, Parchment and the game content.

Now I think that I probably would have been better of with doing a lower tech prototype first. That’s exactly what I’m going to do with this one. The reason why this decision is a bit difficult is that I’d love to use this project right now to get better in developing web software (for instance with Grails).

Game design is unique as a design task. On one hand the properties of a game that makes it great can only be assessed by playing the game. On the other hand the designer cannot directly influence the gameplay experience — she only has access to the mechanics and the interface of the game. (see the mechanics – dynamics – aesthetic model (pdf), which worth it’s own blog post)

That is why it is recommended to design games in an iterative fashion — to make a prototype of the design and to playtest it. Here’s an overview of how such an iterative game design process could be structured. The structure is based on Eric Zimmerman’s article Play as research: The Iterative Game Design Process.

Reminiscience by Profound Whatever (CC non-commercial, attribution, share-alike)

The Iterative Game Design Process

1. Decide on Game Values

The first step is to decide what are you going to design the game for. Game values articulate the design problem you are trying to solve with the game design. You need to decide on the game’s:

• Objectives and
• Constraints.

Objectives are statements about what the game should do. A couple of example objectives: “A light party game for groups of people to get them to know each other quickly“, “web-based game of conquest for people that are active in social networks that keeps the players coming back again and again” and “a browser-based game that helps player in getting the basics of agile software development principles and practices“.

Constraints are limitations on the implementation of the game. For example “can be played in less than 30 minutes“, “works on any browser without plugins“, “can be learned by a non-gamer in less than a minute” are possible constraints.

Gate 1: Game Values

Before proceeding, you need to have positive answers for the next questions. If you find yourself answering no to either of these, go back and re-formulate the game values.

Question 1: Are the objectives of the game valuable? Are they worth achieving?

This is pretty self-explanatory. Every objective should be important and provide value. If you find that you’ve listed some stuff that is not needed, you can cross them out. On the other hand, if you haven’t got any objctives that you consider valuable, maybe you have to dig a bit deeper before continuing.

Question 2: How will you know if the objectives have been met with a particular game?

As game design and its effects on the gameplay experience is not straightforward, you may have to think about this a bit. There may not be clearcut answers for all your objectives, but you should have some idea of how to measure the progress of your design towards the objectives.

1.5. Brainstorm

After deciding on the game values, it’s head-to-the-clouds time. Set your reservations aside and start to brainstorm any ideas on what the game design could include. Make a wall of post-its, a long (unordered) list, a mind-map, some drawings, a list of links and references. Anything to get the creative juices flowing. It’s good to have a number of people involved together at this phase as bouncing ideas of one another is often a good way to come up even more ideas.

2. Create a Game Concept

In this phase it is time to formulate a high-level view of a solution proposal for the design problem articulated in phase 1.

A game concept expresses the core idea of the game. The description of a game concept usually answers the following questions:

• What does the player(s) do?
• What genre / format / type of game is this?
• What is the goal of the game?
• What are the mainfeatures of the game?
• When does the game end?
• What are the most important game elements?

Game concept description should be concise. A couple of sentences will do. What it needs to communicate is what type of game you are proposing to design.

You can end the brainstorming phase by creating a number of concepts and select one in this phase. Or a some combination of the most promising ones, whichever method seems to produce the most promising concept.

Gate 2: Game Concept

Question 3: Does the concept fit in with the game values?

If not, you need to go back to the concept creation step or if the game values need re-thinking, to phase 1.

Tough Question by Terry John (CC non-commercial attribution)

3. Test Question

In each iteration, you need to select a test question for the iteration. That is the question you explore with playtests to see how you current design fares.

It is essential to select the most crucial questions first. If you have one objective that you value more than others you should formulate a question to test that first. Or, if you have some mechanics problem that you deem of high-risk, start with that. That way you won’t waste multiple iterations with a weak game concept.

Some example test questions to help you on your way:

• Is this game playable at all? (mechanics question)
• Are there interesting decisions for the players? (aesthetics / mechanics question)
• Is this particular strategy too dominant? (mechanics question)
• Are the interesting decisions in the game related to the learning objective? (objective question)
• Can this be played in 15 minutes? (constraint question)
• Do new players get what the game is about?

Gate 3: Test Question

Question 4: Is the test question important for your design?

Basically the same question as question 1, but on a smaller scale. If you can trace the test question back to one of your objectives or constraints, you are probably all right. If not, maybe you need to re-think your question or your game values?

Question 5: Can you measure the success of your prototype in regards to the test question with a playtest?

In other words, is the test question measurable and how can you measure it in the playtest?

prototype by YAPixel (CC attribution share-alike)

4. Design the Prototype

Now you need to produce a prototype to use in the playtest. Use as low-tech and low fidelity prototype as you can to be able to test.

You can use paper prototypes (even for videogames), use one designer as a facilitator to help with the operations, anything to keep the production costs as low as they can.

5. Playtest

After you have your prototype it is time to test it. With your test question in mind, organize a playtest session.

At first it will be enough to have the designers themselves test the game. At this point the design is still in very early stages and you are likely to make many tweaks to it. The questions will also be on a very high level so you can probably get away with the designer bias (if you are honest with yourselves).

At the later stages you need to draft more people, starting of course with potential stakeholders, partners, friends, relatives and the like. At the final stages it is probably a good idea to have some people unrelated to the design endeavor to test the game.

An important point in playtesting is that if you tweak the rules in the middle of the playtest you are basically screwed. The observations you have from the session before the tweak are from the non-tweaked version of the game and the rest are from the tweaked version. There are usually very low probability of coming up with conclusive readings of how the game plays with that kind of data.

Of course if you have to fix something to be able to continue the session, do it, but take a moment to think about what the tweak means in terms of your test question.

Naturally it is important to observe how the game plays during the session. What happens, are there any notable moments, glitches etc. You can also interview the participants afterwards, but formulate the questions carefully.

The testers usually have a very different view of the game session than the designers have, so you probably need to do ask for concrete data and do the interpretations related to game mechanics and their effects yourself.

LEGO Mini construction site by bucklava (CC attribution)

6. Analyze

After the session, it is results-time. Take a look at the data you got from observing the game session and the tester interviews (if you did them) and find out if you can interpret that data into an answer for your test question.

7. Iteration done, onto the next one!

If you got a positive answer to your test question, kudos to you. If not or the answer was inconclusive, also kudos to you. Both ways you now know more about your design.

If the answer to the test question came out positive, you’ll also need to consider all the previous test questions you had. Game design is not an incremental activity and so you cannot possibly know if the design decisions you made this iteration broke something that was working before. So test the previous questions if you intend to use the current design as a basis for the next iteration.

If you did not get a conclusive answer to your test question, figure out why. Was the question too vague? Maybe you need to figure out how to measure out your question better or even formulate it in another way. Or maybe you need to change some of your playtest practices.

If you get a negative answer, it is probably time to hit the design board again.

Either way it goes, the minimum for each iteration on each phase is to return to the gate questions of each phase. This way you can be sure in each iteration that you are working with something valuable and can make progress.

If you are in the enviable position that, after multiple iterations, your game design fulfills the game values you set for it and you are happy with it then congratulations! You are done for the design part (for now). Now go throw the prototypes away — I mean keep them as a document of the design, but I would suggest you start to implement the actual game from scratch. And feel free to return to the prototyping whenever you feel the need to do so.

Final words

So that was the short of it. I hope this is of some use. I’m happy to answer any questions or comments you have on iterative game design.

The are much more to be said about each phase of this process and in fact there are many resources out there to help you laying around in different corners of the web. Next thing for me to do is to compile a list of resources, but that will be a topic of another blog post.

I hosted a session in Play4Agile 2011 on the basics of game design. I started with a look on game ontology – that is specifically the question of ‘What is a game’. Instead of just talking about it I thought that a better way to make the participants think about the potential problems of defining what games are would be to play a game that would help us in search of a usable definition.

The game we played wasn’t that polished as I made it up while stepping in the room the session was in. But I’ve thought about it more since that. So here’s the second iteration of the game:

What is a Game?

a game about the ontology of games

The objective of the game

The objective of the game is to come up with a usable definition of games that every player agrees with.

Materials

• A marker board or a black board (or some index cards, some tape and a wall)
• post-its
• pens
• Any number of players (a group that can share thoughts easily (4 to 9 people) is ideal)

How do you win

You win when everyone is satisfied with your written definition of games.

The game ends

• When somebody wins or
• all of the players give up.

Preparations

• Divide the board into two areas.
• Write “Is a game” as a title for one area and “is not a game” as a title for another.
• Write names of games and other activities, things etc. onto a couple of post-it notes, examples of things to include:
  • boxing
  • mind games
  • Hamlet (the play)
  • Texas hold ‘em poker (for money with friends)
  • Chore Wars
  • Simcity
  • Lego
  • Dungeons & Dragons (the tabletop role-playing game)
  • Playing with dolls
  • Playing guitar
  • Monopoly
  • Snakes & Ladders
  • Solitaire
• Write the preliminary definition of games into an index card and put it up on the board
  • You could use something like “games are fun” to start with.

Game rules

Player moves

Each player has an arsenal of couple of moves to try and reach the objective of coming up with a satisfactory definition of what a game is. The players can:

1. Move a post-it note with something written on it to either area on the board.

The player must then describe the other players the reason why the player considers the thing written on the post-it to fit into that area (i.e. why the player thinks that the thing is a game or is not a game). The decision and the reason for it must be made on the grounds of the current definition of games.

2. Take a blank post-it note, write something on it and optionally make move 1.

The player can introduce a new thing to be considered a game or not a game.

3. Make a new definition of what a game is.

The player writes down his definition of games into a post-it note and presents it to the other players. He then replaces the previous definition of games on the board with the new one.

Play procedures

There are no turns and the players are free to make turns whenever they like. There are a couple of important moments in the game, however:

A new definition is introduced

Whenever a player introduces a new definition, it is up to the other players to test it. They can do this by moving the post-its between the “game” and “not a game” areas on the board (move 1) and introducing new things to be considered as a game (move 2).

If the other players are content with the post-it arrangements, the player who came up with the definition can request a vote on the definition. If someone submits a new definition before the vote is requested, the old definition can no longer be voted on.

Voting on a Definition

When someone requests a vote, there are usually two possible options:

1. All the post-its are arranged according to the current definition, but the arrangement of some post-its conflicts with some of the players idea of which of the things are games and which are not or
2. all is well (post-its arranged correctly and everyone’s satisfied)

Each of the players voting (not the one who came up with the definition) must decide which is the case at the moment. You can use thumbvoting: Thumbs up means the defitionis good and thumbs sideways or down means that the definition is lacking.

After voting, discuss on the merits and weaknesses of the current definition and continue playing (unless you all voted for the definition in which case the player who came up with the definition just won the game).

Last words

Remember that the game is about the discussion on the ontology of games. Discuss freely about all the moves happening in the game and make a move as soon as you disagree with something on the board.

If, after you’ve played, you feel the need to read more about the ontology of games, these links (or books) might help:

Rules of Play (by Katie Salen and Eric Zimmerman, 2003) has a compilation of definitions of games up to the time of publication of the book.

Half-Real by Jesper Juul has an ambitious attempt at a definition.

Chris Crawford gives a definition of games in his 1982 classic The Art of Video Game Design.

For a more historic look Roger Caillois has a definition and typology of games in his book Man, Play and Games (1958, Google Books). Johan Huizinga’s Homo Ludens (1950) is another book that gets a lot of mentions.

And finally, I guess Ian Bogost’s DIGRA2009 keynote is the most in line with what I think about games at the moment.

A week ago I attended the Play4Agile 2011 unconference. It was an excellent event (thank you, organizers): I learned a lot, had fun and made new friends.

The event was organized as an open playground (a mod of open space technology) - we the participants designed the program ourselves and were responsible for the success of the event. It worked like a charm: there were plenty of excellent sessions and I was completely engaged in the program most of the time.

I have to say that it was exhausting, too. Each day I had to sneak of for a nap or some alone time as I couldn’t keep up with the intensity level of the sessions for hours on end.

The evening program consisted of games, conversation and a bar – excellent entertainment! By Saturday night there were lots of playtests going on and people were also excited to try out different games they had heard of.

There was also lots of game concept creation, game design and playtesting going on in the sessions. I was involved with the design of (at least) three very interesting games, of which I’ll write about in this blog later. Jurgen Appelo playtested his agile management games and there were plenty of others, from Lego to rpgs to clay or putty to improv and applied drama games.

All in all, a very rewarding and energizing experience. The German hospitality and friendliness was outstanding and the attendees made the whole event simply amazing.

That may seem a short time but actually I think that after developing this thing on a back burner for a while it is actually good to have some pressure to create a proof of concept in a limited time now.

Plan of Attack on Batoche (1886) by Manitoba Historical Maps

I’ve made some further restrictions not directly related to my goal:

• The genre of the game is going to be interactive fiction.
• I’ll be using Inform 7 as the language for IF.
• The release channel will be web. This may change if some technical risks are not resolved.
• I want to have some way to record data on the gameplay of my prototype. This means that the game will be playable online and the actions of the players will be logged.

Items

So in order to reach my goal I need to do three things:

1. Make the game itself with Inform7.
2. Install Parchment and deploy the game.
3. Hack Parchment to enable logging of game events.

However, I can spend as much time as I can in the first item to make it as good as possible. That is, after all, the main focus and the rest are clearly secondary.

Monitoring Progress

I’ll measure my progress during these two weeks in order to ensure getting things done and to be able to make informed changes to my plan as I go. I’ll use a Google Spreadsheet to record my progress. I’ll use lines of code (LOC) of the Inform 7 game to monitor my progress on the game itself. For Parchment and Logging items I’ll use time use (I’ve timeboxed 4 hours to each item) as well as number of tasks completed. I will update these figures daily as it shouldn’t take more than 5 minutes to do so.

These are not particularly useful measurements and I wouldn’t measure anyone else’s progress with them. But as I understand their weaknesses I think I’m less tempted to modify my work habits to “make the numbers pretty”.

So, of I go, to work. Here’s a link to the Google Spreadsheet for you to monitor my progress. I’ ll also be reporting my progress on Twitter.

In short: To create a game that is useful in learning about agile software development.

To unwrap it a bit more:

Useful in learning

• Something to interact with
• to help deepen your understanding,
• to raise thoughts and questions,
• to try out ideas.
• Not something to use as the only source of knowledge.

Agile software development

• The paradigm behind the agile manifesto, not specific models (such as Scrum), but the principles of agile and lean.
• For the purpose of a prototype I will have to focus on a limited set of themes.

Learning situations

• To use on your own, along with books and blogs and other sources.
• To use on courses, like exercises, to promote discussion and allow active exploration.
• To use with your colleagues, for another frame of reference and common experiences besides the things you do at work to support peer coaching.

This first game will be a proof of concept. I’m excited to see how it will turn out.

1. Motivation (the door is locked, the avatar cannot get to the other side)
2. Material for possible solutions (is there a toolbox nearby or does it look like I have to search for the key)
3. Exploration to come up with a solution (maybe sub-problems with the same structure)
4. Solution (door is open, I can advance).

It is easy enough to deduce why this is the prevalent pattern of problems in interactive fiction. When the motivation is presented to the player clearly, he doesn’t wonder off o

r try to achieve something that the game doesn’t support. In order to have multiple solutions to a problem or more vague or complex problems a lot more would have to be built into a game.

Interactive fiction isn’t traditionally particularly system-oriented, rather there are specific things which can be manipulated in specific ways. All interactions between different objects in the game environment are declared explicitly without abstraction and thus there is not much room for emergent problems or behavior.

The Generic IF Cheat Sheet

For the uses I aim at this simply doesn’t do. What I’ve come up instead is the systems thinking model of problems:

1. The player comes into contact with symptoms of the problem (the key to the storage is lost once again, shelves of the store are empty, customers asking if you are out of a certain product)
2. The player seeks out more information about the problem to form a hypothesis (player asks the employees when the key has been lost, examines the shelves, the work shifts, where the key is stored, what’s in the storage etc.)
3. The player, having made a hypothesis, makes an action to impact the problem (3 copies of the storage keys are made)
4. The player studies the changes if the system to see how the change has affected it (at first the shelves stay full but one by one the keys disappear again)
5. If the changes did not have the desired effect the player starts all over (with more information and maybe a different kind of situation)

In the traditional problem model the problem diagnosis and the working solution are scripted into the game. In the systems thinking problem model I propose, the system itself has to be modeled into the game to interact with. This presents a number of problems, one of them being how to guide the player towards the potential problems and through the problem-solving process.

Doug Sharp's diagram of IF taxonomy

The big problem with this design-wise is modeling the whole system inside the game. Interactive fiction deals with language, conversations and objects and is not that well suited for building systems or simulations. For example in Inform7 there are limitations in instantiating things (objects in the game) at runtime. As the Inform7 language is flexible and object-oriented, it should however be possible to do a simple model with emergent properties.

The other option would be to make a traditional game with problems that would mimic the model of systems-thinking problems I’ve described above. That would require designing problems with more material to explore and more kinds of solutions / changes to try, but without modeling a functioning system. In short: more shovelwork, less engineering.

Both solutions have their advantages and time is an issue too. I plan to have something to show in Play4Agile 2011, so I’m leaning towards only building a partial model and mocking other facets with option 2. But I’ll keep all avenues open for now.

I’m planning on doing a little experiment for Play4Agile unconference and to work on it I need to choose one existing anecdotal situation from literature. The other alternative would be to invent a situation by myself but this would be way better so please indulge me.

The Blog-Health-o-Meter™ reads This blog is doing awesome!.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,000 times in 2010. That’s about 5 full 747s.

In 2010, there were 16 new posts, growing the total archive of this blog to 21 posts. There were 8 pictures uploaded, taking up a total of 682kb.

The busiest day of the year was October 19th with 68 views. The most popular post that day was LESS2010 Recap, Tuesday edition.

Where did they come from?

The top referring sites in 2010 were twitter.com, gamebasedlearning.org.uk, uusinokia.livejournal.com, networkedblogs.com, and obama-scandal-exposed.co.cc.

Some visitors came searching, mostly for theory of knowledge games, simjavasp, game based learning definition, game based learning wikipedia, and lean sw.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

LESS2010 Recap, Tuesday edition October 2010
2 comments

Game-Based Learning for Software Engineering January 2010
3 comments

Recap of Leadership & Coaching Questions Workshop @ LESS2010 October 2010

GBL for Agile Coaching: Experiential Learning June 2010

LESS2010 Recap, Monday edition October 2010