Scott Sehlhorst has an outstanding post at Tyner Blaine about documentation. Not technical documentation, but the information you write down to make the development process work. By work, I don't mean just the activities within the development team, but also the rest of the value chain, too.

Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:

Some collaboration is transient – communication happens right now, and is only important right now.  Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.

Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information. 

In the tech industry, the earlier in the innovation process a developer works, the greater the prestige. Lower in the status hierarchy are developers who work on performance and scalability issues, build integrations with other systems, handle security issues, and (heaven forfend!) help the QA team set up test environments. 

Of course, the customer has a much different set of priorities. Sure, new products and features are interesting, but their value is moot if the technology doesn't work. How many concurrent users can the system bear before it keels over? Are the big security holes plugged? Has anyone else run version 7.0.1.3 on Ubuntu 10.04? These questions determine whether a customer buys your product and how likely they are to remain a customer after they've tried to deploy it.

Remember The D In R&D
Some of the larger technology companies have decided to make a serious investment in fixing the problem. While sensitivity training might help some development teams better appreciate the contributions of some of their members ("Looks like the performance guy needs a hug!"), there's no replacement for a well-staffed, well-equipped, dedicated effort to ensuring that the technology works as advertised. Or, just as importantly, doesn't work as advertised, so that the customer knows what sort of configurations and use cases to avoid.

As readers of this blog know, I see a lot of benefits in using serious gaming to make better product and development decisions. Consulting firms like Enthiosys and Booz Allen Hamilton use different serious gaming approaches, but they ultimately have the same aim: Avoid the traps that we mere humans frequently make, even when confronted with a wealth of facts and reasonable arguments. The bigger the decision – for example, What will make us more competitive in the next five years? How do we make sense of all these enhancement requests? Should we pursue a new market? – the greater the need to guard against groupthink, the loudest voice in the room, information overload, and other common decision-making pitfalls. 

While I could (and have) provided examples from business, an equally compelling example comes from politics. One of the offshoots of Enthiosys' work with businesses is Games For Democracy, a charitable foundation that, as the name implies, applies serious gaming techniques to political decision-making. A good example is healthcare, the topic of a Games For Democracy exercise using the "Buy A Feature" game. Each participant had a limited amount of faux money to invest in different healthcare options, such as the public option, a mandate for personal health insurance, and cost containment measures. No one had enough money to buy any option outright, so horse-trading among participants was mandatory.

A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.

Business problems drive technology adoption 
You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.