Luke Jerram and Playable Cities

I really like the concept of a “Playable City”. At a recent conference, Clare Reddington, Creative Director at Watershed, spoke about the concept of a Playable City. A Playable City is a city where people, hospitality and openness are key, enabling its residents and visitors to reconfigure and rewrite its services, places and stories. In other words, the concept of Playable Cities enable inhabitants to interact with their cities in a way which is very different to their everyday interactions. I guess the concept can be best explained through some great examples:

Luke Jerram – “Park and Slide”

Park and slide “Park and Slide”, a one-off interactive art installation by Luke Jerram which took over a Bristol high street last year, with people taking turns on Jerram’s giant water slide.

Jonathan Chomko and Matthew Rosier – “Shadowing” 


With this project by Jonathan Chomko and Matthew Rosier, Bristol’s city lights have been given memory, enabling them to record and play back the shadows of those who pass underneath.

Design I/O – “Faces”


“Faces” is an interactive installation that captures your portrait and sketches it at large scale, projected onto a building across the street. It was installed for six months as part of San Francisco Art Commission’s “Lights on Market St” Project. During that time, Faces captured and displayed 30,000 portraits, with an average of 160 portraits a day. Pan Studio – “Hello Lampost” 

“Hello Lamp Post” was a playful SMS platform project that ran in Bristol and which enabled people to strike up conversations with familiar street furniture using the text message function of their mobile phones. As a result, people shared their thoughts and stories with streetlights, parking meters, letter boxes, bridges and boats in Bristol, with over 25,000 text messages sent by players in just 8 weeks.

Main learning point: I love the concept of “Playable Cities”, enabling people to see their cities in a new light and to interact with their everyday environments in a completely different way. Apart from the playful element involved in some of the Playable City projects, I believe that we can also learn from the new ways in which people interact with everyday objects. We can apply these learnings to other product areas and interactions.

Related links for further learning:


Book review: “Agile Retrospectives”

I believe that retrospectives can be incredibly valuable to any team. Taking the time every now and then to take a step back as a team and to reflect. How are you doing as a team? What have you learned from the things you did or released in the past period? Where and how can we improve? Actually starting to do team retrospectives on a regular basis is an important first step. Then you can start learning how to get the most out of your retrospective.

If you want to learn more about doing retrospectives, there are two resources which I’d highly recommend. Firstly, the Agile Retrospective Wiki created by my brilliant ex colleague Rob Bowley. This wiki provides a great wealth of tools and tips that one can use to plan and facilitate team retrospectives.

Secondly, the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen is a great resource when it comes to learning more about retrospectives. These are the main things that I took away from reading this book:

  1. Common retrospective stages – I like the retrospective structure which Derby and Larsen recommend in their book: Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective (see Fig. 1 below). This is a very useful structure to apply to your retrospective. Not only does the book outline the core purpose of each retrospective stage, it also provides concrete activities that one can do at each individual stage.
  2. Planning a retrospective – Even if you stop reading “Agile Retrospectives” after its first two chapters, you’re likely to have learned a lot already about how to best plan and structure a retrospective. The book contains a lot of practical information on how to plan a retrospective, after which it offers some very useful dos and don’ts with respect to leading a retrospective.
  3. Include a variety of activities – With the “Agile Retrospectives” book, the Agile Retrospective Wiki and the great retr-o-mat, you shouldn’t struggle to come up with activities appropriate for a retrospective. Too often I hear from people that they end up doing the same things in their retrospectives. In “Agile Retrospectives”, Derby and Larsen provide a great number of activities to choose from, depending on the goal(s) that you’re trying to achieve with the retrospective.

Main learning: For anyone who wishes to learn more about how to plan or run a retrospective, “Agile Retrospectives – Making Good Teams Great” is a must read. It contains a lot of practical tips on how to best facilitate retrospectives, making them action focused and creating an opportunity for the whole team to get involved.

Fig. 1 – Common retrospective stages – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 4-13

  • Set the stage – Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. It also contributes to creating an atmosphere where people feel comfortable discussing issues. For example, as a person facilitating the workshop you could start with a welcome and an explanation of the retrospective purpose. You can then ask people in the room to speak and you can outline your approach for the session.
  • Gather data – Gathering data is an important part of the retrospective as it will help to create a shared picture of what happened. Start with the hard data: events, metrics, features or stories released, etc. You can then focus on feelings, which will tell what’s important to people about both the hard facts and about the team.
  • Generate insights – This part of the retrospective is about asking “why” and thinking about what could be done differently. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes.
  • Decide what to do – At this point in the retrospective, the team will have a list of potential experiments and improvements. The team will pick the top items, decide on what to do and will action them. You can take action during the retrospective. For example, as a team you can decide in the actual retrospective to change the “working agreements” (e.g. “Everyone will pair at least four hours a day”). Equally, you can create a number of story cards or backlog items to follow up on after the retrospective (e.g. “Change the font on the homepage” or “Simplify deploy procedures”).
  • Close the retrospective – End the retrospective decisively. Decide how to document the retrospective, its outcomes and actions, and how to follow up. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Finally, before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective.

Fig. 2 – A retrospective custom-fit to your team – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 15-26

  1. Learning about the history and environment of the team – Especially if you’re working with a team other than your own, study their context. When you talk to people on the team, try to find out about topics such as these: What did this iteration produce? What was the team aiming for? How did the result meet (or not) expectations? What kind of outcome will achieve value for the time invested – both for the retrospective sponsor and the team?
  2. Shaping the goal for the retrospective – A useful goal provides a sense of why people are investing their time, without predetermining what actions or direction the team will take after the retrospective. Useful goals for retrospectives include the following: find ways to improve our practices, discover what we were doing well or understand reasons behind missed targets.
  3. Determining duration – How long should your retrospective be? Fifteen minutes can be enough – or not. There’s no set formula for this. Base the length of the retrospective on four factors: (1) length of the iteration (2) complexity (of the technology, relationships with external departments, organisation of the team) (3) size of the team and (4) level of conflict or controversy.
  4. Structuring a retrospective – The structure of the retrospective – Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective – helps to bring in perspectives from all team members, follows a natural order of processing information, and moves the group towards committed action. Look at the goal that you’re trying to achieve with the retrospective and allocate a set amount of time per activity. Also allow for some “shuffle time” for people to move from one activity to another.
  5. Selecting activities – After you have the bare bones of the retrospective – the goal, duration, attendees, room, and setup – it’s time to think about activities. Activities are time boxed processes that help the team move through the phases of the retrospective. Activities provide structure to help your team think together and have several advantages over freewheeling discussion.

Fig. 3 – Demo video of the print version of Corinna Baldauf’s “retr-o-mat” – Taken from:

Agile Retrospectives

Electric Objects brings art from the Internet into your living room

I recently found out about Electronic Objects, “a computer made for art”. An Electric Object is effectively a wall-mounted device which comes without a mouse or a keyboard. It promises to bring “art from the Internet into your home”, and I can see that it will do exactly this:

  1. Designed for the home (1) – The problem that Electronic Objects are looking to solve is that of small devices not being great for properly experiencing art on the Internet. As Electronic Objects founder and CEO Jake Levine explained to TechCrunch recently: “The devices that we use to access the Internet (our tablets, our laptops, our phones, our computers), they’re designed not for contemplation, not to live in the background, not to be quiet or still, but to demand your attention and absorb you.” Reason why the Electric Object “01” is created in such way that users don’t have to worry about all the – utility and productivity related stuff – happening on their devices.
  2. Designed for the home (2) – In a recent Product Hunt podcast, Jake Levine mentioned how digital hasn’t yet made its full foray into people’s living rooms. There are products such as Nest which cater for the whole house or the kitchen, but the “Internet of Things” hasn’t quite made it into the living room yet. Electric Objects aims to provide a product which isn’t about utility but something that can become “a part of our lives fitting seamlessly into our familiar home and work environments” according to Jake Levine.
  3. Designed to fade away – On Electric Objects’ Kickstarter page it describes how the “01” has been designed to “fade away”, like a photograph or a painting. I like that the screen of Electric Objects 01 is effectively just a frame that you can stick onto your wall. There’s no keyboard, mouse or alerts, avatars, slideshows, feeds or docks. The frame is connect to your WiFi account, which means that you can directly control the artwork on the frame from your smartphone or any other device.

Main learning point: Electric Objects have created an exciting new product in this computer made for the display of art from the Internet. Their “01” computer is now available for pre-order and it will be interesting to see how many people will buy it to bring digital art into their living rooms. Separately, I’m keen to see how many product people and designers will start to concentrate more on the ‘living room’ as a place to create digital products for. Watch this space!

Fig. 1 – An Electric Object ‘in action’ – Taken from: 


Fig. 2 – Electric Objects Founder and CTO in conversation with TechCrunch’s Anthony Ha – Taken from:

Related links for further linking: