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)

Yes, yes, yes: Gamification! The term sparks this Tell-Sell voice in my head “Oh my God, this is just A-M-A-Z-I-N-G. Look, I can do what I have to do and have FUN while doing it. Such an amazing discovery. Your work will never be the same.” All delivered in pastel colours by suntanned people. True, this is powerful stuff. It is absolutely amazing but not all that new.

What are we talking about when we worship gamification?
Mostly, we are talking about a perspective change. A shift from doing something you do not want to do into something you do want to do, without having to change what you are actually doing.

The extrinsic reward system we have built our lives on creates postponed certainty and fulfilment; your actions may lead to money/status/physical comfort but the existence of these rewards is only certain in the moment they are given. Before and beyond this moment, these rewards are mere concepts. The physical manifestation (your experience of them) remains uncertain until they become. After they have become, they quickly vanish into your past. The world giveth and the world taketh away. So you hop from (mostly material) reward to reward, connecting the dots and building a life.
The very attractive perspective shift in gamification is to move your attention from the fixed-point-yet-uncertain-reward back to the process you are in. Back from what ‘may be’ to what you are actually experiencing, and making this experience more interesting. You reel in your postponed reward structure and fish out a desired experience. Instead of waiting for a future reward that may never be, the reward of any action starts in the process of the action itself.

If the manifestation of desired rewards depend solely on the results of our actions, these results better be good. We put a lot of stress on ourselves and others (and the planet) to manage the outcome of results before they even exist. We want to make sure that our results will be judged as desirable results and lead to the extrinsic rewards we set out to claim in the first place.
This kills creativity.
In order to make as sure as possible that we achieve what we want we look at who will be judging us, and preferably by what standards they will be doing so, and we try to fit in. Now, please take a moment and try to make friends between the words ‘judge’, ‘standard’, ‘fit’ and the concept of ‘creativity’. The more we try to make certain the results of our processes will be judged favourably, the less creative they must become for they cannot deviate from the norm used by those doing the judging.

Of course there is creativity and there are lots of brilliant and creative people. If you go and ask them you will find that they are more interested in the process than in the results. They need to write, to paint, to solve the puzzle, to build the thing, to go out and sing and dance. In short, they wish to create. The need is not to ‘have written’. The results of their actions are important but creators are most happy while in the process of creating (we all are but we tend to forget).

This shift of focus from result to process clears the way for more creative thinking, for oodles of positive emotions, for a more enjoyable experience of the actions you are performing and ultimately (usually) lead to a better result. Especially in such areas where there is no standard or the standard is irrelevant.
Software development is such an area and –low and behold- the structures they thought up and use to guide development have gone from rigid top-down ‘follow the marked X’s all the way down to the desired results’ to a development style that focuses much more on the process of creating than setting yourself up for judgement.
Crack-developers that should be hired to head such a process are the ones that say
“I think I understand your questions and I have some ideas that may lead to a solution. Let’s start working on this.”

The gaming in software development (part 2)