Playing Telephone can be Fun
To those not familiar with the game of Telephone (also known as “Chinese Whispers” or “Russian Scandal”), it involves transferring a message amongst several individuals. The first in line whispers something to the person next to him who in turn passes the message on to the next person and so on. The game ends when the last person in line repeats the message out load. The entertainment value comes in when corruptions are introduced to the original message as it makes its way down stream. If you are wondering how playing Telephone is relevant to software development, read on.
One of the biggest challenges of developing software for new business models is that you only get a short window of opportunity to launch before your competitors join the race. This is contrary to an evolutionary product development where we use a clearly defined road map and feature list. During the early stages of new product design, no one really knows exactly what is needed or how to go about building it (that’s where the cone of uncertainty (is the largest). At this early phase, the business has not yet fleshed out their model (i.e. customer base, distribution, pricing, etc.) and the development team hasn’t yet picked the tools, platforms or frameworks.
Because of this, the design process defies common sense. If you follow the tried and true PM and SDLC practices (i.e. detailed requirements gathering and formalization phases), you are guaranteed to end up with an outdated design that does not reflect the real business needs. This can be a bit unsettling, when considering that the business requirements document you’ve worked on so hard become obsolete as soon as you send it to the printer.
The causes of this paradox stem from the difficulty in articulating and converting new business requirements to a functional product. Just like in the game of Telephone, the original message tends to get comically distorted as it traverses the line so do the business requirements and the final software solution. Playing telephone can be fun, but it’s not if you are trying to accurately convert business requirements to a software solution in a timely and cost efficient manner.
How do we address these challenges? Luckily, over the years several effective methods have been devised. The following are my six favorite cures for playing software requirements telephone:
Shorten the feedback loop for all development activities and streamline your design (i.e. develop less functionality and deliver it early). This approach is based on the OODA Loop originally developed by John Boyd. One of its key requirements is that all stakeholders meet frequently (daily) and promptly iron out all newly discovered problems.
Leverage RAD methods to quickly convert raw business requirements to proof of concepts and prototypes that closely resemble the real business objectives (especially as they apply to the product’s functionality and look and feel).
Keep project deliverables and key milestones to a weekly time-frame. This will help prevent problems from popping up a month or more later or going undetected until the product is in its downstream phases.
Utilize SCRUM methods to quickly convert business requirements to functional features and smoke test and build daily, so at the end of the weekly cycle you will always have functional code.
Put in place an effective collaborative infrastructure (document depositories, real-time progress dashboards, accurate bug tracking, etc.). There is no better way to secure trust and cooperation with the business than to maintain transparency.
Involve all team members in the decision making process, especially the architects and developers actually responsible for designing and coding the product. Immediately bubble upwards bad news regarding show stoppers like instability, scalability, system performance, and security.
Another important factor to consider is that unfortunate truth that many development team members consider the horse trading side of software development to be tiresome. Naturally they’d rather spend their productive time coding.
Unfortunately, this isolationist mentality only exacerbates the Telephone game. As a development manager, you should work diligently to eliminate it and bring the business as close as possible to the technology. Instead of relying on outside resources to explain a business case or strategy to your team, have your team develop domain expertise in every aspect of your business (including sales, marketing, customer boarding and support, etc.).
I have found the following three approaches to be most effective in achieving this:
If your company has a sales training academy (typically a several day orientation for new salespeople), have your team members attend it. Learning the business from the point of view of a sales rep will help you design more effective and streamlined products.
Encourage your senior technical staff to obtain business related degrees (MBA, marketing, etc.). Tuition reimbursement goes a long way towards achieving this. It will help your company in the long run by improving your team business acumen and at the same time provide a larger pool of future leaders.
Actively participate in business strategy meetings and regularly brief your team on upcoming business ventures. Provide technology leadership beyond the current ongoing projects by volunteering to present new technology trends to your business units and show how these trends can benefit the business. Be proactive in putting forward new solutions that can make the business more agile and improve sales and revenue.
Learning and mastering your company’s business model and gaining a thorough understanding of the market forces where your product will live and compete will go a long way towards being able to navigate the high seas of ambiguous requirements. It will also help you build better and financially successful software.
© Copyright 2009 Yaacov Apelbaum All Rights Reserved.