Teaching the Rules of the Game

How to Introduce the Change?

One of the first tasks introducing a change in an existing team as an outsider, is to teach the new rules. If you are coming from inside the organization, having the knowledge of the people and the backup of the rest of the management, you can probably have a better plan than what I had when I joined the team.
I decided not to wait until I discover the fine balance of power inside the organization, but to set up the stage in a form of game. The game is educational, as it give first hand experience of the concepts, and more importantly, it is fun and causes much less defense from the participants.
The first concept I wanted to change in the Agile or SpeeDevelopment was the waterfall or serial stream of deliverable from the field to the lab and back. To be able to speed up the cycle of development for real customer, it is important to break the walls or gates between the teams.

The "Good Old" Way

The process used to start when the product manager wrote a long and detailed general requirement document, based on his discussions with sales and real customers. The requirements were analyzed by the development team, designed and developed. Then it was tested by the QA, who learned what are the requirements from the developers. The process was considered "Agile" as each such cycle or iteration was of one month.
The first phase "Requirement Writing" seems to me as the root for most of the problems; if the requirement are too general and the development is done far away from the real customer, the chances for success are slim and the effort wasted is fat.

The Simulation Game
To teach this lesson in a fun and quick way, I found a nice simulation called "Offing the Off-Site Customer". Just before the beginning of the first iteration that used the methodology of writing requirements by the developers with the help of the product and actual users, I ran this simulation on all people involved (development team, product team, professional services team...). I divided the group (about 30 people) into pairs and gave them the tasks of copying diagrams in two ways;

1. One writing description and the other using the description to copy the original diagram
   
2. One watching the diagram and describing it orally while watching the copied diagram being drawn by the other.
   

I think that the message got through quite effectively, as the results of the second method were dramatically better than the results of the first way.
I still had to make some modifications of the ways of requirement writing collaboration, but the idea of writing it together (developers and customers) was accepted without much objection.