Feedback exercise – showing the value of instant feedback
Could you draw a copy of the image above without seeing it, acting only on someone’s description of it? What if the other person was only allowed to describe it in written text, and you are not allowed to talk to each other at all? That is the idea of an experiential exercise that I like to include in classes and workshops when I want the participants to experience the importance of instant feedback.
Here is the way I usually use it these days. First, the participants form pairs. One will take the role of developer, the other will be the customer. I then tell them that they will be “developing” drawings, by copying an original drawing to a blank paper. The customer is the only one who will be allowed to see original drawing, and the developer is the only one who will be allowed to draw. I then inform them that we will run two rounds.
In the first round the customer must create a specification for the developer, by describing the original drawing in writing. Only text, no symbols or drawings. The customer and developer are not allowed to talk to each other during the entire round.
After five minutes the requirements phase is finished and they move into the implementation phase, when the developer is allowed to start drawing (if they have received a specification of course). The customer is allowed to watch as the developer draws, and if they want to they can provide further instructions in writing throughout the implementation phase. I usually place the developers and customers in different rooms and instruct the customers that they are only allowed to write at their own “desks”.
After ten minutes the implementation phase is finished and I bring everyone together, standing with their pair colleague. Each customer shows their original drawing and the developer shows their produced copy, and we have a quick vote to decide which pair got the best result.
I ask the pairs if they want to change roles for the second round, and then introduce the new rules. In this round the customer and developer will sit next to each other. The basic rules are the same, only the customer can see the original drawing and only the developer may draw (e.g. touch the pen), but this time they can communicate in any way they want. They can talk directly and the customer can even point to the paper. The full round lasts for ten minutes and there is no requirements phase, they can immediately start talking and drawing.
Insights and learning points
Apart from the obvious fact that the results were much better in round 2, with less time to complete them, there are also many other insights that can be made from this exercise. Depending on how you play it some of them might be more clear than others. Here are a few things that usually come up when we debrief the exercise (always debrief!).
- Following made-up rules: We often find ourselves following “rules” that do not even exist, we made them up ourselves. Sometimes customers think they are not allowed to use measurement units (such as “3 centimeters wide”) to describe the drawing, even though no such rule is given.
- Creating a common language: In the pause between the two rounds the pair will often talk about their drawing and find common ways they have of describing something. For instance, some will call the solid blue circle in the drawing above a donut. This common “language” makes it easier to describe abstract things such as a drawing (or software).
- Iterating the drawing: This usually happens during the second round, where some pairs sometimes adopt a process of first quickly sketching out the basic layout of the shapes to have something to point to and discuss. They will then start on a new paper and make a better drawing, and possibly iterate like this multiple times.
- “This is just a simulation”: Very often this comes up in some way. One favorite of mine is when people say that they sit in different buildings so they have to communicate by writing to each other. Asking them if the exercise have changed their mind on the value of clearer communication and instant feedback is usually enough to get them started on planning how to make it work anyway.
I usually run the exercise the way I have described above, as part of an introduction to agile methodologies, to show the difference between trying to communicate by written specifications versus sitting down together and working collaboratively. There are lots of ways it can be altered depending on what insights and learning you want the participants to get from it. Here are a few that I have tried and some that I thought about while writing this.
- Improving through retrospectives: One of my favorite subjects is retrospectives, and variations of this exercise can help teach participants how to use them. For instance, run several shorter rounds and do a retrospective between each one, where the the pairs learn and find improvements to their process. You can choose to only work with written specifications for instance, and let the pairs use the retrospectives to discuss how the specs can be improved and a common language can be used in them.
- Include a messenger: In round 1 use a messenger (maybe call them Project Manager, or Business Analyst) who is responsible for delivering the customers written specifications to the developer and giving the customer feedback on the result. The customer is not allowed to move from his desk, so he never sees the work as it progresses and have to rely on the information from the messenger.
- Involvement of product owner in development: One of the worst anti-patterns I know is the product owner who takes part in the planning of an iteration and then disappears, until he then shows up at the demo and disqualifies the work the team has done during the iteration. Real product owners take part in the daily work of the team, and it is very simple to show this with a variation of this exercise.
- Information loss in multiple handoff situations: Let the customer describe the drawing (probably should be a simpler drawing in this case) to a business analyst, who describes it to an architect, who then describes it to a designer, who describes it to the developer (introduce as many levels as you wish) and see what results you get.
When thinking about variations I think it is important to remember that an exercise should be as simple as possible for whatever learning it should support. Remove any element that does not directly support that learning point. If you have more ideas for variations of this exercise please post a comment. Thanks!
I have uploaded a presentation on Slideshare that introduces the exercise and includes some sample drawings (basic shapes laid out in various ways) you can use.
Alistair Cockburn also has a somewhat similar exercise he calls The Draw-This-Drawing Game which is a bit more complex and used for more specific learning points.
Use this link to trackback from your own site.blog comments powered by Disqus