Strategizing to solve a communication problem

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.

Playing the game:

• 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.

The teams enjoyed the challenge of working together to improve their communication strategies. The best solution that any team found was to have the observer 'tap in' whenever the builder put one piece in the correct spot. This strategy enabled the builder to easily understand when they had done something right (improving communication) and helped the team to improve their time. Hurray for the team!

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.

Agile Winnipeg Inaugural Event - "Shorten the Distance"

It was pretty exciting for myself and the other organizers to see a packed room of over 60 people attend the first Winnipeg Agile User Group event on Thursday, March 10, 2011. After a quick meal from Homers and some furniture re-organization, we kicked off the event with a word from several of our sponsors. Wadood Ibrahim spoke on behalf of Protegra and recalled giving a presentation to the local PMI group 10 years ago about agile techniques that was not well received and was delighted by the turnaround of opinions and interest 10 years later.

For the main presentation, Doug Kok and I split the attendees into groups of about 15 people and led them through the ball point game. The ball point game is a simple and fun exercise that allows teams to think about process * people through team decision making and the power of reducing hand-offs. Here are a few images from the event:

Team 1 Discussing their strategy



The scores of the game. Notice the significant improvements from most teams. Team 3 forgot to count during the last iteration, but based upon the process they were using, I think they would have surpassed their estimate of 160



And, thanks to Doug - here is a brief video summary of the teams playing the game: 


So how does the ball point game relate to agile? In both the ball point game and in software development, improvements in speed can be gained in similar ways:

• Focus on reducing hand-offs by having face-to-face conversations, dedicated teams, shortening the distance between a requirement and its implementation, a question and its answer, etc.
• Stop frequently to determine how to go faster.
• Measure your experiments through velocity and frequent feedback.
• Value and encourage cross-functional, de-centralized, self-organizing teams.

Homework: To take this further, read the 12 principles in the Agile Manifesto and think about how each of the 12 could be re-stated as a way to reduce handoffs, or as shortening the distance between [A] and [B]. Also, to see how these ideas can work in the 'wild', read this case study on facebook.

To close the event, we held a short open Q&A session. Some of the questions we discussed were:
 1. Can you do agile without TDD (Test Driven Development)
 2. When/how do you do requirements?
 3. How do you control scope creep when you aren't defining the requirements up front?
Lively discussion continued over drinks at Triple Bs on Scurfield.

Based on the survey responses, the top 3 categories for future event topics were Agile Testing, Agile Adoption, and Agile Estimating.

Finally, on behalf of the organizers I would like to thank you for participating and thank the sponsors for allowing this event to occur. To register for future event notification, please click here.