There may be some  fundamental assumptions – how different human brains processes information, what the established literature recommends, and what works in different team and cultural contexts.

What my team struggled with is dealing with a distributed team and laying out the right format of requirements for them to be productive. Initially, my assumption was that in case of a distributed development team that perhaps lacks the full context of the problems that the software intends to solve, we should focus on creating documents with excruciating details thrown in. So get those requirements specifications to be so well documented that a person with relatively zero context can covert it into working code that fulfills the original goals and desires.

Using the templates set forth by Alistair Cockburn, in Effective Use Cases, we felt pretty good about the format. Others in the team suggested using Control-Action-Response matrix for each UI element on the screen in conjunction with the use cases. This became a laborious process, but we did get it done. What we realized was that the biggest beneficiary of these detailed use cases were the QA team members who got a ready-made template to convert into test cases. The other beneficiary was the offshore development team, who were kind of cut off of the whole contextual nature of the solution. The offshore team members were tackling a completely unfamiliar domain and they lacked the proper preparation to come up with any innovation on their own. The use cases became a very very hard specification of what was supposed to be developed. Very infrequently were the requirements questioned and alternatives proposed.

However, the onsite development team was on a different track. These team members were visiting the end-users regularly, sitting down and observing them, becoming their apprentices for a day or two to really grasp the nature of the problem. Their contextual awareness was very high. In turn, they became one of the chief sources of innovation. The ideas poured in continuously and made a healthy backlog. These improvements were recorded as normal enhancements into JIRA and formed the basis of many features that were absolutely loved by the end-users.

Recently I checked out the “Head First” series of books. These books excel in condensing the relevant information for the brain to process in a very precise, humorous and entertaining fashion, while educating. And I wondered to myself – could this form a model of how we record requirements, how we conduct trainings, and impart education in the classroom. If a teacher is part educator, part entertainer – there is a better chance of him or her engaging the students.

Here are some tools that may help create more entertaining requirements documentation.

Balsamiq Mockups – This is one of the best mockup tools and is very easy to use. I frequently use it to make my requirements documents, and even emails more entertaining. Joel Spolsky is another big user of this tool to help create entertaining essays.

Flickr Creative Commons - I use this site heavily to draw from thousands of funny, humorous photographs to illustrate a point. I am always looking for situations that are well described by some photograph to capture the reader’s attention. Of course, you can draw from your own pool of photos if you have them as well.

Image courtesy – J from the UK at Flickr

ScreenFlow for Mac - Video is the most under-rated tool in requirements definition and can really make a difference in your deliverables. I use ScreenFlow for Mac, but there are equivalent screen recording softwares for Windows as well. For iPhone and iPad, there are numerous apps that will record and screencast.

VoiceThread - Why restrict collaboration to text, images, video and audio. Why not use everything in combination? This is the promise of VoiceThread which allows users to interact asynchronously using any media.

1. Have no real vision behind the project: If the application is not really going to solve any real pains for the consumers of the applications, don’t do it. Cost savings, ease of maintenance – are all noble goals in themselves, but not as worth doing as making that application more useful for the end users.
2. Outsource everything to a consulting firm: Firms like Ideo are great when it comes to pinch-hitting that creative idea for you. However, they are not you. Consulting firms cannot replace the lack of in-house talent. They are not a sustainable model when it comes to creating innovation from ground up within the organization. So send your staff to learn from companies like Ideo, but give them fertile ground to grow the organization from within.
3. Implement only the customer’s stated desire: If the innovative direction of your product is purely driven by the “stated” features desired by customer, you are putting the customer solely in-charge of the product. Listen to the customer, but don’t put them completely in-charge. Listen, observe, re-learn – from both stated and unstated desires.
4. Shield developers from customers: Developers develop software. But have they put a face to the end user who may use the product? Do they feel the connection on a human level? Do they understand the frustrations experienced by the end users? A relationship with the users will result in better product than a relationship with a requirement specification.
5. Time-box everything: Letting deadlines drive launch decisions rarely proves to be sustainable. Do it if you can really be ready, but don’t sacrifice quality to meet a launch date. It’s not worth the negative karma from customers.
6. Deny mistakes: Nothing is more refreshing than companies admitting they got it wrong. Nothing will restore the respect for you as a leader if you admit a bad decision. Refusal to do so will build a culture around you in which failure is seen as something terrible and to be avoided at all costs.
7. Don’t take time to play: If you want your team to be excited about coming back to work on any given Monday, then you have to make time to play. Channel play time into concrete innovations.
8. Don’t talk to everyone: Don’t get second hand information from the layer of hierarchy that reports directly to you. Take time to wander around, mingle and get a real grip on problems that may prevent the software from being successful.
9. Don’t harness everyone’s ideas: You are the boss. Are your ideas are the most important? Wrong. Ideas that will solve your company’s problems may be closer and cheaper to find than you can imagine and they may not be your own. Start by asking your staff. Continue by inspiring them to improve every single day.
10. Have two different game faces – one for employees and one for investors: If your team has no idea into the strategic decisions and direction the company is taking, and they have no idea of company’s financials, they may never understand some of motivations for project decisions. Bring their heads into the game.