You have this great idea for an improvement in your team/company/organization. “If only we would change from X to Y, then we would be so much better off.” You have seen the data for it, heard about it or even experienced it yourself. Of course everyone will follow you to a better future. Right?
Unfortunately, change is not that simple. Most people are hesitant to change, they create workarounds for problems they have and trying to make them change often fails. Resistance to change is not about politics or opposing views. Most of the attempts that try to change something and fails do so not because the change was bad, but because of the way the change process itself was managed. Here are three very important facts about change that are often overlooked, leading to almost certain failure in changing.
1. Your vision is not their vision
In the words of my friend Joakim Karlsson, change is a pull system. It may be obvious to you that if your team or organization would just do this change, you would all be much more effective. But do not expect your coworkers/manager/friends (or whoever you want to change (with)) to think so. If you try to push your change on them you are almost certain to fail.
This does not mean that you should just sit back and wait of course. Instead you need to convince them that they need the change. But it is not enough to say that things will get better, or that this new technology is proven to be better. You have to put it in context for each specific individual or group you are trying to convince. What problems are they having today, and how will the future created by this change affect them specifically? The more specific you can be about describing both the current status quo, the change and most importantly the improved future from their perspective the more likely you are to get people interested in the change. And then you will not need to push the change on them, they will be requesting it to happen.
2. It gets worse before it gets better
So you managed to convince your boss to try your idea. He will be back in a week to follow up and see the effects of it. Or maybe you did not even try convincing anyone. After all, when the change is implemented who could possibly have any objection to it when things are already much better?
Wrong! No matter how great your idea truly is, no matter how much improvement it means to your effectiveness, changing what you have now always hurts your effectiveness in the short run. People are used to doing things one way and it does not matter if that is an ineffective way of doing them, if they are forced to change they will do things worse for some time until they learn the new way and settle in with it.
There is lots to say about this curve and how to help people through it, as well as how to work to shorten the time between the change and when you are back at the starting level. For now though we will just keep it at accepting and realizing the importance of this curve. Do not expect immediate gains from the change.
3. It takes time to see the benefits
Finally, you have managed to convince and get people interested in the change, and all of you have also understood that it will be a time of chaos before things get better. But the question is, when has it gotten better? Or more importantly, when can we start reaping the benefits of the change?
It is very easy to think that as soon as the period P1 is over it will all be ok. But you have to remember that during P1 you lost effectiveness. Many change efforts fail because they expect net gains at this stage. But net gains are not achieved until you go through the period P2. Instead of getting surprised by this, set your goals for the end of P2 and keep working to support the change efforts all the way.
Keep these three facts in mind when you plan your change and improvement efforts and you will have a much better chance of succeeding with them.
When planning a retrospective you as the facilitator need to come up with a set of activities that help the group in discussing and learning about whatever goal you have for that particular retrospective. If you follow a basic framework for planning your retrospectives, such as the one proposed by Diana Larsen and Esther Derby (Set the Stage, Gather Data, Generate Insights, Decide What to Do & Close the Retrospective), this often turns into simply choosing an activity for each phase with no real connection between them.
For instance, you might choose to do a timeline to gather data, then a brainstorming activity to generate ideas for improvements and finally a dot-vote to decide what to do. While this can work just fine, I have found that when I am able to combine several activities so they build upon each other the result can be much better. Here is one example of how this can be achieved.
This week I facilitated a retrospective for the new development team that I have assembled at work. This was the first time that this team did a retrospective after working together for four weeks and I wanted them to start thinking about how satisfied they are with how things are working out. After getting started with an introduction to retrospectives and checking in we did a quick anonymous vote for how satisfied they were with work, in four dimensions. I chose two dimensions regarding the product increment they completed (Quality and Quantity of the increment) and two dimensions regarding how it was achieved (Teamwork and Support (-ing Environment)). Every one voted 1-5, I tallied the votes and then created a Satisfaction Histogram on a flip chart.
After a quick discussion about the results I hung the histogram on the wall and we then moved on to a second activity for gathering data, Diana Larsen’s FRIM which is one of my favorites for this. At this stage we did not talk more about the dimensions of satisfaction, they just wrote down good and bad things that happened during the four weeks and posted them on a grid according to frequency and impact. We finished with a good discussion of patterns and themes on the grid.
While the group was busy with the FRIM activity I prepared four flip charts for the next activity, doing a Force Field Analysis. For each one of the dimensions I had written the name at the top and then divided the chart into two sides. On the left (negative side) were forces that was restraining the group’s satisfaction in that dimension of work, and on the right (positive side) were forces that was reinforcing it. Now I asked the group to move the post-it notes from the FRIM grid to these flip charts. They also ranked them (using both frequency and impact plus a bit of intuitive “gut feeling”) to show which forces were larger than others.
This set of activities is an example of how you can move back and forth between gathering data and generating insights, to really get as complete a picture as you can and drill into it to really understand it. When the group was done they had a good idea of which forces were the most important to focus on and we could move into the phase of coming up with actions to do during the next iteration.
One interesting insight that one of the participants made was that it was interesting to see that there were only positive post-it notes for the dimension that the group initially voted the highest satisfaction for. Their initial instinctive feelings turned out to be very similar to the much more detailed picture they created through multiple rounds of thinking and analyzing, which was pretty cool.
 Agile Retrospectives: Making Teams Great, Diana Larsen and Esther Derby
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.
Scalability. Great presentations scale. Most importantly, a great presentation can always be scaled down. If you can deliver a great presentation in 45 minutes you should also be able to say the same thing in 10 minutes. Or in a 45 second elevator pitch for that matter. So, how do you create a presentation with that in mind? My advice is to start with the one thing that you want the audience to learn, then build on that.
This blog post is part of my Duoblog Series. For each topic I ask someone I know and respect as an expert on that topic to write a blog post with the same title as my post. We then post them at the same time without knowing what the other person wrote.
For advice on creating a great presentation I turn to Claudio Perrone. When I first met Claudio two years ago he had just been accepted to speak at a conference, his first public speaking engagement. Claudio is an amazing learner and quickly studied everything from storytelling and moviescript writing to creating powerful visual presentations. I have been fortunate enough to see him present a couple of times so I know that he can really engage an audience with stunning visuals and a great story.
Read Claudio Perrone’s answer to “What is the secret of great presentations” on his blog.
So much to say, so little time
Picture this: You have been given a chance to present your company’s new product in a 45 min presentation. You want to create a great presentation to make people really enthusiastic about it. So, you fire up Powerpoint and start making bullet points for everything fantastic you can say about your product. The more great things you mention, the better people will feel about it, right?
Unfortunately, this seems to be what a lot of presentations are about. The speaker tries to mention as many things as possible in the time they have available. Each slide has so many bullets that she does not even remember to mention all of them. When time runs out she jumps to the final slide to wrap things up, while mumbling that there were more interesting things to say if only there had been more time. The audience remembers a fraction of what was said, and probably have a hard time summarizing it.
I believe that this happens when the speaker starts by considering how much time is available for the presentation and then works to fill that time with interesting stuff, rather than the other way round.
Creating a great presentation
Start by defining what you would say if you only had a short moment to say it, no matter how much time you actually have for your presentation. There is probably a specific reason why you are giving this presentation. Whether you are talking about a new technology or an idea you have, there is something about it that you think is important enough that you want to tell others about it. This is the core message you should deliver, and it should take no longer than 45 seconds to deliver it. If you can make people more enthusiastic and wanting to hear more about the topic then you know you have succeeded, and you are ready to add more things to the presentation.
If you have more time available, think about how you can make that message clearer and more powerful. Resist the temptation to add another core message to the presentation. Instead add some supporting ideas that give some more detail, still with the core message in focus. To avoid adding too much consider what you would say if you had 10 minutes to present your idea. If you have even more time then add another level of detail, this time giving further support for the ideas introduced in the previous level. In this way the presentation scales up, and everything you say is still related to the one central idea you want people to learn from your presentation.
A powerful message that people will remember
Now that you have taken a different approach to creating your presentation you will need to think about how to frame the core message so that the audience will understand and remember it.
Put yourself in the shoes of your audience and ask “What’s in it for me?”. If you do not give people a reason to remember it, why would they? Put your message into a context that the audience can relate to. Describe a situation or problem that they will recognize from their own life, and then present your idea and how it solves or relates to that problem.
Introduce the core message very early in the presentation, right after setting up the context it should be delivered in. Also repeat it throughout the presentation. Specifically make sure that you end with the core message again, since people generally remember best what they learn at the start and end of a learning session.
Finally, do not be afraid to use Powerpoint or other visual aid. People favor different learning modes (auditory, visual and kinesthetic), and multi-sensory learning is a powerful memory aid. Seeing keywords in written form, accompanied by powerful images, can help your audience remember better. The important thing is to avoid confusing presentation with documentation. A bullet list with some key points is a great aid when later reviewing something, but that does not mean it has to be a part of the actual presentation. Instead provide a separate file for documentation.
Scale your presentation up from the one thing people should learn
In summary, creating a great presentation starts with a clear and concise core message that the audience can relate to. The presentation is then scaled up level by level to add more detail, all the time repeating that core message. If you feel the time is to short, make it shorter.
When thinking about how to get inspiration for blogging I came up with an idea I have named Duoblogging. The concept is simple. I choose a topic that I want to blog about. Next, I contact someone I know who I respect as an expert on that topic, and ask that person to simultaneously write a blog post on the same topic. We decide together on a title we will both use for our posts, but other than that we do not know what the other person writes. We then both publish our blog posts at the same time, linking to each other. The idea is basically that one plus one is greater than two. By reading both posts readers will hopefully be able to infer even more than what is said in the posts.
I will be updating this post with links to each duoblog post as they are written in the future. Stay tuned!
I recently participated in a discussion regarding pair programming. There were not really anyone against pair programming in general, so the discussion was mostly about what situations or types of tasks are good for pair programming. What always bothers me with this type of discussion is that it seems like most people consider pair programming to be something we decide to do because it fits a specific situation. In my opinion it should be the other way around. For any given situation we might decide not to pair program because of some circumstance, but that should be a conscious decision to disregard our normal standard of always working in pairs.
The problem with considering pair programming as something we decide to do in some situations, as opposed to deciding not to do it in some situations, is that it is too easy to stick with the norm by not making that decision. “This task is too simple, that task is too complex and requires some serious thinking, I do not feel like pairing today” are all easy excuses to use when you do not have to answer why. A conscious decision of disregarding a work standard requires much more than “not feeling like it today”.
When I propose that pair programming should be the norm people often react by listing situations where it would be wrong and wasteful (according to them at least) or by identifying problems with working with someone else all the time (“what if someone smells bad?”), almost regressing to an anti-pairing opinion. I think this is because this concept is so foreign to what we have been taught for so long, and that most pro-pairing people have actually not tried pairing as the standard way of working like I propose. To this day I have never met anyone who have actually tried working this way for at least a month but would like to work any other way.
For a great story of someone who did try real pair programming I really recommend Rod Hilton’s post I Love Pair Programming. I’ll end with a quote from that post:
I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time.
Together with Marcus, I recently designed and led a workshop on refactoring, unit testing and other techniques for producing good code. To start the day off we asked the participants to list some characteristics of good and bad code. After getting most of the usual suspects on the list, one participant shouted out a new one, which should be pretty obvious. On the good code side is my code, on the bad code side is your code. Everyone had a laugh, but the fact is this is probably true if you ask most people about code.
As I said, it should be quite obvious that most people consider their own code to be better than someone else’s code, but I think we can make some profound realizations from looking into this more closely. There are two questions that are important to think about here. First, what is the effect of this issue? Second, how do we use this knowledge when working with a development team to help them produce better code?
An escalating mess
If I encounter some bad code, I will try and make it better. Since I believe my code to be good code, I will of course try and change the bad code to become more like my code. So, the code is better and everyone wins, right? Well, what about the other guy? He sees my code, and since from his perspective his code is better than mine, he will of course try and change it so it becomes more like his code. And round and round it goes. Each of us are trying to make things better, but together we are actually producing an ever escalating mess.
So, the important question then is how can we help developers realize that their good code might not be the best for the team as a whole? My bet is on communication. Using practices of communication and reflection between the developers in a team, we can create a common understanding of what good code means to us, and break the escalation.
Talk about code
Any time spent away from programming, instead talking about code and coding, is time well spent in a development team. If we want to get a common understanding of what good code is, then we need to have some formal structures in place to insure that this talking about code happens. Do you use pair-programming as the default mode of working? Do you do code reviews, where everyone on the team sits down and talks about some piece of code to learn from each other about how it could be improved? Do you collectively break down user stories (or other requirements) into tasks, using CRC design and similar techniques for exploring what a good design would be? Are you running a study circle?
What techniques and practices does your team use to make sure that you talk about code enough to have a common understanding of what good code means to you?
Note: This post describes an anti-pattern that I have observed with software development teams. I wrote it as a contribution to Ola Ellnestam’s under-development book on Software Development Team Anti-Patterns. I recommend taking a look at Ola’s book for more anti-patterns. I like the short and concise definition of anti-pattern that Ola use in the book, taken from Wikipedia:
An anti pattern is a repeated pattern of actions, a process or structure that initially appears to be beneficial
The Helpful Teacher
“If we would only use test-driven development, our design would be better.”
As the self-designated technical leader of your team, you are constantly trying to help your colleagues understand and use good practices for writing high quality code. Even so, the code base is a mess and it is not getting any better. You have tried everything, from buying them books (with your own pocket money!) to showing them your own great code during a monthly meeting. The best you have managed is to convince some of them to try, but after a short while they always give up while telling you that it does not work. You are back to square one, or worse since now there are people saying that the practices you are promoting does not even work!
Studies in psychology* have shown that if we ask a person about their ability and competence in some skill, most people would estimate themselves as ranking above the average. (For an example, try asking people about their driving skills.) If we ask a group of people to estimate their own competence relative to the rest of the group, again most people consider themselves to be among the “better part” of the group. In fact, as the above referenced study shows, even the most unskilled people estimate themselves above average, because coupled to the lack of competence is a lack of awareness and understanding of that skill.
To be able to teach someone to use a new skill, they must at least see some need for it. Otherwise, from their perspective, you are only trying to push something not needed on them. Since they are unaware of the problem you are trying to solve, and therefore cannot distinguish your proposed solution from their defunct practices, all of your teaching goes in through one ear and directly out the other. “We are practicing test-driven development. We write tests in a Word document and run them manually before release.”
Before you can teach someone a new skill they must become aware of the need for the skill and their own deficiencies in that area. In other words, if you want to promote good technical practices for writing quality code in your team, you must first talk about the need for high code quality. The team needs to have a common understanding of what code quality means to them, otherwise everyone will just think that they are writing quality code and they do not need to learn new practices for improving on it.
Here are a couple of things you can try with your team to increase awareness on the value of high code quality, and to create a common understanding of what it means to your team. The thing in common between them is that they all encourage reflection and discussion.
The mother of all knowledge-sharing techniques. If you want to spread an idea to your colleagues you should never sit alone and program. No matter how nice code you write no one is going to notice it, and the practices you follow to achieve it will be completely invisible to the others. Try and spend as much of your time as possible working together with someone else. Do not push for all the practices you would like everyone to use, but use the opportunity to show your partner what you can do and the great results that follow.
- Code Reviews
Lots of organizations use code reviews as a way to achieve higher code quality. However, in my experience they are used in a command-and-control way, where you as the developer submit your code for review to the mighty architect, who then returns it with a number of things for you to fix. While some bugs and other problems can be avoided this way (depending on how much time the reviewer has to look into the code), it is not an efficient way of promoting high code quality in a team.
Instead, schedule a regular meeting where the entire team meets to review and discuss some piece of code from your project. As an alternative you can pick some open source project and review code from there. That way no one in the room is criticized, and it is easier to have open discussions about issues in the code sample. Rotate the role of selecting the code to be reviewed, make sure everyone has the code in advance to review ahead of the meeting, and then spend an hour or two discussing it together over coffee and a snack. If you want to you can follow up by actually implementing the improvements discussed in the meeting.
- Coding Guidelines
Again, most teams have a coding guideline that prescribes what is good code. They can contain things such as naming guidelines, where to put the curly braces and how many spaces the indentation should use. Sadly though, these are documents written a long time ago, by someone who is not part of the team or sometimes even no longer in the organization. As can be expected, they are not meticulously followed and it is not uncommon for people to be completely unaware of their existence.
Creating a coding guideline for a team should be a collaborative activity for that team. Gather everyone once a month, discuss what people think is important when writing code and find out what everyone will agree to do. Write this down, preferably on large flip-charts posted in the team room. After a month, meet again and continue the discussion. It is not really the results that are the most important, the discussions are where awareness and understanding is spread throughout the team.
If you can create awareness on the need for high code quality you will not need to teach your colleagues how to do it. They will already want to learn, and all you have to do is answer their questions. (Not quite, but lets not get into that here.)
* See for instance “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self Assessments (Kruger & Dunning, 1999)” for more information.
Things are changing. We are closing down Blueplane after two fun and interesting years. I have had a great time and learned a lot and I am sure my colleagues would say the same (here is what Andrés and Joakim say). Now I am looking forward to a new beginning, although I do not know where right now. If you have an idea or suggestion, please let me know. I’d love to talk.
I always start retrospectives, in fact more or less any meeting, by having the participants check in. After introducing the retrospective and describing its purpose, I let each participant in a round-robin fashion answer some question I ask. By having each participant speak in turn, the tone is set to show that during this meeting everyone is allowed and encouraged to be an equal participant. If we instead would just ask if someone wants to say something, those who are unsure, shy or quiet would probably not say anything and would be more keen on staying in that mode for the entire meeting.
The simplest way of doing this is to simply ask each participant to say something, for instance describe the past iteration in just one word. This activity, and some variations of it, is described as the Checkin activity in Agile Retrospectives, by Esther Derby and Diana Larsen.
However, if the group are becoming more used to participating in retrospectives, this activity can feel a little boring if used every time. This is a perfect time to spice it up with some more creativity from the participants. By having people draw something and then describe why the drew that specific picture, not only do we get a more rich picture (no pun intended) of their mood and feelings, but it also starts the creative process in everyone’s head.
Invite participants to be active participants of the retrospective, and help them to get in a creative thinking state. Share the mood and thoughts people have with the rest of the group, including the retrospective leader.
The retrospective leader asks participants to think about how they would describe the past iteration. Each person then draws a simple picture to symbolize their answer. Finally, in a round-robin fashion, everyone shows their drawing and describes what it shows.
Ten to twenty minutes.
I recommend that you supply each participant with a magnetic drawing board (or even Doodle Pro for more size). A simple piece of paper and a pen could of course also work, but see the Motivation section below.
- Ask the participants a question. You could ask them about their perceptions of the past iteration, or just their current feelings. Depending on the situation, you might want to hear about their feelings of this retrospective or just the work that was done.
- Tell everyone to draw a picture that symbolize their answer.
- When they are done (or time is up), ask them in turn to describe their picture to the rest of the group. Some will just say what it shows, others might describe why they drew that specific picture.
- Listen carefully to signals indicating a safety concern. If necessary, follow up with an activity to create more safety for the retrospective.
In Pragmatic Thinking & Learning, Andy Hunt tells us to “add sensory experience to engage more parts of the brain” in problem solving and creativity. He goes on to write that “when you involve an addition input mode, you are activating more areas of the brain – you’re bringing more processing power online [...]“. So by drawing our thoughts and feelings, instead of just speaking them, we are thinking more effectively on this ‘problem’, and also setting our brains up for creative work.
And of course, a picture says more than a thousand words! In my own experience, people who can seem very shy and quiet often draw very descriptive pictures, and are normally quite happy to talk about them.
The question of using simple pen and paper or something like a magnetic drawing board comes down to the purpose of the activity, and the specific situation you are in. The ease with which you can erase a drawing board can create a sense of safety. “It does not matter if you cannot draw very well, it is just a doodle that will be gone in a minute.” The playful nature of it, a children’s toy, also helps in this regard.
On the other hand, you might want to use the drawings later in the retrospective for some other activity, or even bring them back to the team room, in which case paper trumps.
Two specific variations of this that I know of are the Project Weather activity (I will talk about this in an upcoming post) and my friend Michael‘s Car Instrument Board activity (which I will let him write up a description for himself).
Alt. 1: To really get the creative thoughts going, have the participants pair up to create a drawing together two-and-two. Tell each pair to take turns adding something to the drawing. You can start them off by giving them a subject to draw, such as an animal symbolizing the past iteration. The other person then gets to add something to the drawing to change it, for instance another animal trying to eat the first. The first person ‘defends’ by adding something more to the drawing, and on it goes. After discussing their thoughts and the drawing, the pair then presents it to the rest of the group.
Alt. 2: If you only have one drawing board, and preferably a large one, start by letting the first participant draw something (or do it yourself). The board is then passed to the next person who is not allowed to erase it, but must add to the picture. Everyone gets a turn to add to the complete picture!