The Manifesto for Playful Product Development

Guest Article written by Graham Holden – here’s a little something about him in his own words:

Graham describes himself as a Programmer, Scrum Jester, Shantyman.

Has been working within the internet industry since 1997, for a variety of organisations.  Has a passion for programming and helping teams become effective.

******************************************************************

 

In Peter Greys Book – Free to Learn (thanks Tobias Mayer (https://tobiasmayer.uk/) for recommending this), he emphasises the importance of Play for children’s learning and development. As a parent, I’m often conscious of not interfering in the play my children embark on. I’ll be present, so that if they need me for anything I can help – but I like to let them get on with things.

Peter Grey outlines Play as the following :

  1. Play is self-chosen and self-directed; players are always free to quit.
  2. Play is activity in which means are more valued than ends.
  3. Play is guided by mental rules.
  4. Play is non-literal, imaginative, marked off in some way from reality.
  5. Play involves an active, alert, but non-stressed frame of mind. (https://www.psychologytoday.com/gb/blog/freedom-learn/200811/the-value-play-i-the-definition-play-gives-insights)

 

It got me thinking about how, when I am programming for “fun” it’s actually me “playing”.

I feel that the 5 “rules” above could be adopted within organisations as a framework. Some might say business is a serious thing, and there is no room for frivolity. But what a lot of us have forgotten, is that as children when we “played” it was serious. When you are in the midst of it, play is all consuming – it is an example of a perfect state of “flow”.

I would encourage organisations to adopt the framework to help teams use play for personal development and learning. This would be a great first step. In the past I’ve been involved in some interesting breaks organisations have put on, these have been called “hackathons”, “hackdays” or just “learning days”. The most successful ones have essentially followed the basics of the framework outlined above.

  1. The Teams chose what to work on, and could switch to other teams if needed.
  2. The experience of the day and the activities trumped the actual end results.
  3. The teams got to work how they wanted, with what they wanted, and produce whatever they wanted.
  4. The teams could work on whatever they liked.
  5. The teams had very little pressure on them, there were no KPIs.

 

I believe more and more organisations should be adopted playfulness at their core, and we can have a playful movement for product development.