The gaming in software development (part 2)

Taking in trial and error as part of the process instead of avoiding it like the bubonic plague is part of creative success.
One of the most magical elements of a game-frame is that we constantly try and fail until we get it, without being demotivated. In real life we are reluctant to stick our necks out into new territory and if we do, we do so cautiously and are easily dissuaded. In real life we convince ourselves and each other that obstacles are mountains to be feared and can only be scaled by a talented few. Many mouths tell us that what we have is preferred to what we might get. Should you try anyway and fail, this is viewed as feedback that YOU are incapable. Most failures arrive into our inner sanctums as a big fat ‘I told you so’.

But not with gaming. Here we are more confident that we are able to do this and that if we are not able at this particular point in time (because we obviously failed), we are confident that we will learn. In gaming, we try again. What makes gaming so different in this respect?

First of all, the cultural notion is the opposite. Instead of an inbred feeling of ‘things are hard’, ‘experts are there for a reason’ and ‘successful people are different from me’ there is a notion of belligerent ease. It’s a game, of course you can play a game; everyone can!

Second and possibly more important, a game is designed in manageable chunks;
it has levels. Gaming gets harder in small steps. Before each time it is about to get harder the game will tell you that so far you are doing fine. Once you have been through a gaming iteration once or twice (try, fail, frustrate, learn, try, achieve, feedback) you grow confident that you will overcome any new failures as well. Whatever this game is going to throw at you, you will be able to catch, even when you miss the first few balls. You learn to fail and live to fail again connecting all these failures into a big win.

We see the levels from the game in the block structure of agile development, or sprints. Huge problems are cut into bitesized particles, a size we feel we can manage. This quality is especially important when the end-product is unclear because ‘it’ has never been made before. By breaking the process into smaller pieces and only focusing on the next (big) step you ditch the daunting ‘win or lose everything’ emotion that can cloud development projects. One failed iteration is not going to kill the planet. You have also just added tremendous flexibility to the whole process. Within the blocks the feedback cycle is short, the horizon never that far away. Like playing levels in a game, every new cycle feels like something you can do.

Agile software development also changes one cultural notion in the way teams are formed, blocking one common built-in escape that people create in the space between in- and out group. When you leave everyone in their respective field or department (as little islands in a huge green sea) in- and out-group effects occur. One of the effects is that we push the possibility of failure onto the out-group (other field or department) over which the in-group holds no influence what-so-ever. If, or when, the project fails it will be because ‘the testing department has always been a mess’ or another favourite ‘management has cut it down to all the useless options’. In any case there is a ‘them’ that will ensure failure. So why bother? Run back to attend the judging festival and make sure that your part of the project is exactly up to specifications in preparation of the blame-game that will follow the unavoidable failure of the project you are working on. Exit any between-team-spirit and creativity.
Taking people out of their usual in-group and (tries to) makes sure that everyone that should hold influence over what is being made is present. No forwarded expectancy of failure. No escape. Instead you have everyone and everything you need to do what must be done. The in-group is your entire development team. If your expectancy does not shift to achievement, the team is incomplete or you may need to start looking for a different job. Changing the in and out group perception changes the expectancy of the outcome.

The gaming in software development (part 1)

This entry was posted in Mediated and tagged , , , , . Bookmark the permalink.

Leave a Reply