The Telephone game

The traditional model of gathering requirements and building specifications is based on a lot of formalising, handing over and translating. Business analysts first extract knowledge about requirements from customers, formalising it into specifications and handing that over to developers and testers. Developers extract knowledge from that and translate it into executable code, which is handed over to testers. Testers then take the specifications, extract knowledge from them and translate it into verification scripts, which are then applied to the code that was handed over to them by the developers. In theory, this works just fine and everyone is happy. In practice, this process is essentially flawed and leaves huge communication gaps at every step. Important ideas fall through those gaps and mysteriously disappear. After every translation, information gets distorted and misunderstood, leading to large mistakes once the ideas come through the other end of the pipe. Tester’s independent interpretation might help to correct interpretations of developers, or it might very well be a completely different misinterpretation of the system requirements. With agile processes, the feedback loop is much shorter then in a traditional process, so problems get discovered quickly. If agile acceptance testing is not applied, even with other agile practices in place, there is still a lot of space for mistakes. Instead of discovering problems, we need to work out how to stop them from appearing in the first place.

People seem somehow surprised with this result even though most of us have encountered it and used to amusing effects in childhood. Antony Marcano draws a parallel between the traditional software development process and the Telephone game. The Telephone game works by getting a group of children in a line and then the first child whispers a phrase or sentence to the next child. The second child whispers what it has heard to the third one and so on. The last child in the line says what it has heard out loud, which is often significantly different from the original phrase. Although those cumulative differences may have been amusing when we were children, they are not so funny when it comes to solving real problems that obstruct people in doing their jobs.

go back to key ideas