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. 

If you need a concrete picture of what I'm talking about, imagine yourself doing sales training for a new product. In its quest to open a new market, your company has launched a new product that's necessary, for whatever reason, to do business in that market. It's your job, now, to explain to the salespeople, in one hour or less, everything they need to know about (1) the new market, (2) what makes the new market different from the current one, (3) how the buying process in this new market is likely to be different, (4) why the new market is interested in your company at all, (5) what the new market needs from you, and, finally, (6) what the new product does.

Chances of success? Nil. OK, let's give you two hours. You still fail. That narrow window of opportunity isn't big enough to accommodate the months or years of backstory that went into requirements, design, and other elements culminating in the release. Obviously, there will have to be a follow-up, in the form of a site where the salespeople can get further information, a mailing list about the new product, and all the typical mechanisms companies use to try to increase readiness after a release, but never quite get there.

The solution, of course, is to start sharing information prior to the release. In fact, there needs to be a careful information strategy, tailored to make the salespeople as ready as humanly possible by the time of the release. Even the richest oral traditions in a company are no substitute for writing things down as the basis of this information strategy. Using what you've already written is a heckuva lot easier than stopping what you're doing so that you can write, from scratch, the ABCs of the new market and the new product.

No big surprise, therefore, that reports and dashboards are a popular part of tools that support the innovation process. In his Tyner Blaine post, Scott focuses on the executive sponsor of a project as the beneficiary of this content, but it's clear that in any company, a lot of other stakeholders depend on the prompt delivery of this content, too.

Of course, you can't dump the dictionary version of requirements data on the heads of these stakeholders and expect them to make sense of it all. Ideally, you'll have not only prepared the version of this information in advance, but even before then, deployed some techniques or tools that will make this re-formatting process easier. In reality, the chain of events will not progress this neatly, but you need to at least start thinking about what written content you'll need to convey well in advance of delivering it.

[By the way, congrats to Scott for five years of excellent Tyner Blaine posts!]