My wife spent part of this past weekend on a leadership retreat. Her team was asked to participate in the following game to help them develop their team strategy and communication skills:
Setup:
- One person acts as a builder.
- One person acts as the architect.
- Two people are observers.
- The builder and architect sit back to back in chairs. The two of them are not allowed to look at each other, but they are allowed to talk.
- The two observers stand on either side and watch and are not allowed to talk or interfere in any way.
- The builder is handed a blank piece of paper and some shapes that have been cut out.
- The architect is handed a drawing where the shapes are already put in place - the blueprint.
- Round 1
- The architect's job is to have the builder re-create the drawing by putting the shapes in the correct placements on the blank piece of paper. The architect is not allowed to turn around, but is allowed to talk.
- The observers are instructed to watch - no talking or gesturing.
- The builder is also not allowed to turn around but is allowed to talk.
- Time how long it takes for the team to correctly finish replicating the drawing.
- Rounds 2-n
- A rule change: For this and any subsequent rounds the observers are allowed to 'tap in' during the round. That is, when they tap the architect's shoulder they can trade places with the architect who then becomes an observer. You can 'tap in' as many times as you want during the round.
- Before starting the round the team is asked to strategize together on ways that they could improve their communication and their results.
- Once again the team times how long it takes for them to correctly finish replicating the drawing.
This was a great exercise to promote team building, continuous improvement, strategizing, and to encourage the team to actively work on their communication skills. It reminds of some of the ways I have seen and used to help teams improve communication between roles. Does the developer have a hard time understanding the requirements document? Let's work on our documentation skills to make our writing clearer. Does the team struggle to meet it's project deadlines? Let's increase the project management rigour and status reporting. Are bugs found during user acceptance testing? Let's write a better test plan.
Or... have the architect (customer/business analyst/tester/project manager) turn around and talk to the builder (developer) directly. Break the rules (and your cubicle walls). Shorten the distance.
No comments:
Post a Comment