Team Building Telephone Game Phrases
Do you remember the 'gossip game' we played in elementary school? Our teacher would give one person a sentence or two and ask them to repeat it to the next person. They would repeat the sentence to the next person, and so on, until the last person in the class would tell everyone what they heard. The more times a message was passed from person to person, the more garbled the message would be. It was occasionally close, but usually a phrase like 'I really like the oceans' would become 'Giraffes hate lions and politicians are corrupt'. It was always fun to see how completely twisted a phrase could become when everyone was doing their best to repeat exactly what they heard. It was a given that the original phrase would never survive the trip around the room.
So why do we try to gather requirements the same way? Think about the way we typically gather requirements. We designate someone to gather requirements. They talk to several customers and gather the requirements into a large document. They meticulously write down every detail.
How To Play Telephone. A classic and fun party game for all ages! Get players to sit in a circle facing inwards. Pick a player to start. Tell this player to come up with a sentence or phrase and then whisper (or 'pass it on') to the person next to them. Consisting of a number of telephone game phrases, this game works. Telephone game is a captivating icebreaker and party game. Our collection of Telephone game phrases ideas gives you an opportunity to outperform your family & friends. This activity can also be used in conferences and team building projects. It provides a healthy way of.
These documents are often hundreds of pages long with every conceivable detail written down. Every screen is described.
Every function spelled out in excruciating detail. This long, often boring, document is passed along to program managers who edit, adjust, and generally 'improve' it. Finally, the document is broken up into bits and pieces that are passed along to the development teams. They take these out of context snippets and try to build a cohesive system. The developers dive in they work for months.
They argue with each other about important details and debate the meaning of the requirements document. The testers devise test plans for each part of the system.
Each word in the document is studied and every drop of wisdom is painstakingly extracted. The research and knowledge that went into creating the requirements document is reconstructed step by painful step. After thousands of man hours and millions of dollars of effort, the completed product is proudly presented to the customers. The customers, our reason for being, promptly turn their nose up at our newly birthed baby.
They declare the product worthless. It’s not what we need or want they say and they refuse to pay for it. Later the lawyers gather to debate how much of the work should be paid and what should be written off as a loss. You and the customer part ways, each thinking the other is an idiot and a cheat. By the way, the process I’m describing here is actually a very short one for most medium to large companies.
The requirements gathering process is usually much more convoluted, but this example illustrates a few key principles. How can we do better? What’s wrong with this model? There are several glaring shortcomings in this model that you’ll see immediately once they’re pointed out.
First, just like in the gossip game, we see the typical requirements process involves repeating information. The customer talks to the requirements committee. The committee creates a document (another form of repeating the original phrase). The company leadership changes the requirements document to reflect the company’s goals. Then the various developer teams interpret the document before writing the code. This process is often much worse. Many times the client has an internal point of contact who gathers the requirements from the managers of the people who’ll actually use the software.
This creates a few levels of interpretation before our people every get involved. The next thing we see is the lack of feedback. The developers rarely go back to the creators of the requirements document.
Telephone Game Whisper Ideas
That team is busy writing another document for another product. They don’t remember what they put in your document anyway.
But even more importantly, the developers never get a chance to ask the customer what they wanted. How can you possibly understand what the end user wanted if you never talk to them? This is a very important point. We feel that we can represent what people want by writing it down very carefully. Then next time write more! As Doctor Phil might say “How’s that working for you?” I’d like you to consider another industry that follows a similar model: contract lawyers.
Someone pays their lawyers $250 an hour to write down exactly what they want in a contract. Later someone else pays their lawyer $350 an hour to prove the document means something else. Lawyers have been trying to write down what people mean for thousands of years and they still fail. Are we, in a brand-new and relatively immature industry going to improve on that model?
I don’t think we are. We need to move forward with a different model.
Workplace Telephone Game Phrases
Instead of trying to write down what people want, let’s try to:. Represent Feature Requests Differently. Allow developers access to the customers. Provide smaller features that can be completed and shown to the customer more frequently Represent Features Differently Let’s step back from complicated and “complete” documents and move towards a more accurate representations. Let’s also try to include more context in our feature descriptions. One way we can do this is by using the popular story card format for each feature. It pulls out just enough information to be useful, but prevents the multipage novels that are so common.
The format is fairly simple (and there’s plenty of information available on the topic). The short version is this.
Write your features on 3x5 cards this automatically caps the amount of information you can capture. Then write 'As a (role), I want (feature) so that (reason)'.
Then on the back, record the completion criteria. This format provides the context and usage information, not just the feature. This is invaluable information for anyone implementing a feature. The last piece of information, the completion criteria, makes the team asking for the feature really think about how they’ll know when it’s working in a way they’ll be happy with. This eliminates feature requests like 'Make it scale' and creates features like 'As a reports user, I want reports to render more quickly so that when multiple users are running reports they’ll still be fast enough.
This feature will be done when 10 users can generate a usage report at the same time and they’ll all generate in under 30 seconds'. Another way to represent features is in executable documentation. If you’ve never looked at tools like Cucumber, you’ll be pleasantly surprised at how well the Behavior Driven Development tools can reflect a user’s request. You can see examples of cucumber syntax at Allow Developers Access to the Customers When the developers have questions about features, it’s rather pointless to let them debate the issue among themselves. I know the team is a very smart group of people, but they aren’t the customer. The customer has their own history and their own unique point of view. All too often the development teams aren’t allowed to ask the customer questions.
Instead of getting clarification from the source of the request, the development teams work in a vacuum. It may be that you have many customers and some of the developers may not be perceived as having the social skills needed to spend time with customers unsupervised.
(Some developers I know aren’t really qualified to spend with other developers unsupervised, but that’s another topic) In that case, grab the company’s requirements gatherer and have them set up a conference call with the developers and the customer. This keeps everyone in the loop, but still lets the developers ask the customer to clarify an exact point in the requirements document.
When you ask the customer to help you clarify a point, you not only avoid writing the wrong feature (talk about a waste of time!), but you move a customer into a different role they become partners. They’re working alongside you to build a better product. Would you prefer to have a customer that’s trying to shoot down your product when you release it, or a customer who’s an advocate for how great your product turned out? I know which one I prefer.
Smaller Features There are many reasons to break down your work into smaller features. It’s easier to estimate the work, easier to test a single feature, and, most importantly for this discussion, we’re able to get the smaller feature done more quickly.
The traditional model is to show the customer the product when it’s nearly done. When it’s an 'alpha' or 'beta' we’ll open the doors and show them how the finished product will probably look. We can make minor tweaks at that point, but no major changes can be made. The product is nearly done. You can only hope you did a good job, because sink or swim, this is what you’re delivering.
Another approach is to work on smaller features and then show them to the customer when they’re working. Instead of building an entire system, show them the data import feature as soon as it’s done.
Ask the customer if it works the way they expected it to work. Does it handle their data in the format they need it to handle? Breaking down the work allows you to engage the customer more frequently. The paranoid developer is afraid that showing the developer a feature will give them the opportunity to change their mind, but any great salesman will tell you the secret to selling anything is to reach out and engage the customer as often as possible. This isn’t about bugging the customer, but giving them a chance to see new features on a regular basis. Your sales team will love you and your customers will tell you if you’re building what they need. Remember, the alternative to getting feedback is to not get feedback.
And that leads to building features no one wants or needs. What tips and tricks are you using to improve your requirement gathering? The next installation will come next week. Note: This article is a preliminary version of a section in my upcoming book, the second edition of Ship It! A Practical Guide to Successful Software Projects. I’m planning on posting preliminary versions of content here as a way to get preliminary feedback and share the ideas as I write them.
Will Gwaltney and I started the first edition of Ship It! Nearly 7 years ago.
After several printings and 7 languages later, I'm finally doing an update.
