Chinese whispers a.k.a. the telephone game a.k.a the whispering game; you know, the game where you as a kids formed a ring and one started to whisper a message to the nearest peer whom was supposed to whisper the message to the next peer and so and so fort, finally reaching the last person, whom then shared the result out loud. Obviously resulting in giggles and laughter caused by various funny distortions introduced during the journey of the message. But what if it wasn't a game? What if it was for real? As in, what if there were really bad side effects involved if the message got distorted along the way? Obviously people would try harder and really try to keep it intact. But the more people being involved, the higher the risk is for failure.
A) Our boss likes monkeys and suits.
-->
B) Our boss likes monkeys in suits.
-->
C) Our boss looks like a monkey in a suit.
I do believe we all understand that there will be a higher risk of distortion of the original message if there are more people involved in passing it from A --> Z. Yet it's not rare that we do this in our development projects. It's just like the game. The communication isn't direct between the business and the developers implementing the feature. As in, the journey of the message isn't A --> B between the person requesting the feature and the developer implementing the feature, but instead something like A --> B --> C --> D. Often there are business analysts, managers, leads, etc. involved before the requested feature and its requirements reaches a backlog.
I'm not against involvement of many people. Actually, I do believe it's good. But I also believe its crucial that the developer interacts with all necessary people. So if there is a backlog of "things to be done", I do believe they should be as unspecified as possible. This so that the developer is forced to interact with the people with knowledge. Of course this will fail completely if there's no engagement from the business. And if this is the case, then we as developers should just say: "No. Can not do." It should become obvious to them. Start engaging or stop spending resources on the project.
It's not rare that we as developers get to answer questions like: "Why did you become a programmer?" Or "What is it that you love about programming?" The answer is most often something in the lines of: "Because I like to solve problems". With this in mind, what do you think will happen if a team of developers gets no input and attention from the business? Best case. Nothing. As in, nothing will be produced. Then it's obvious there's a problem. Another possibility is that the team tries its best and implements something that is not compatible with the business work flows and domain. Another possibility is that the team it self set out to solve "made up issues". Focusing on building the fun parts. Focusing on technical and cool things that they always wanted to try out.
Communication, engagement and commitment is key to success. Be involved. Interact. Doing this gives us a chance to question and learn the domain. And knowing the domain is crucial for succeeding with our projects.
//Daniel