Upfront is good

Let’s get a few things straight.

• Analysis and documentation are not synonymous.
• “Big up front design” (the agile zealot’s hell) and analysis are not the same.
• The holy grail of self documenting code (“the code is the documentation”) means bugger all to people who ask for the software to be built in the first place (people for whom a class is something they went to school in).

The Agile Manifesto states “Working software over comprehensive documentation”. Note the use of the word “comprehensive”. It doesn’t state “working software over documentation”. It also states (and this is all too often forgotten) “That is, while there is value in the items on the right, we value the items on the left more”. It is essentially pragmatic, do just enough that is necessary to allow you to be successful. This is most important in the field of analysis.

On all but the smallest of projects where you have a customer who knows exactly what she wants, is available at a moments notice to the developers and can communicate a clear vision to all involved, you are going to have to invest in some analysis. I’m not talking about writing-a-bunch-of-stories-analysis, I’m talking about understanding the business context, producing a product statement, segmenting customer needs. Maybe it is crafting an aspirational visual representation of the end product, wireframes, an information architecture, an imaginary product “fact-sheet”.

I’m not saying do reams of analysis for the sake of it. I once worked on a government project where I spent three months specifying requirements and designing business processes for a scheme that was inevitably going to change when new legislation came out. That was stupid. Just enough analysis is not only volume and content, but also its timeliness. It would have been sufficient to identify the broad scheme requirement as something in the pipeline with the detail to be fleshed out when it was required. That way we would know about it up front, and act upon it when required.

Developers are smart people, they don’t want to write code for the sake of it. They ask questions, why are we doing this? “Individuals and interactions over processes and tools”. Nothing in that line about not using documentation. Just the right type of documentation to help facilitate the conversation. “Individuals and interactions” lack permanence – the business guy doesn’t want to explain the who’s and why’s to every new developer that comes to the project. They expect to state the project background once and it to persist through the project. (Ask a business guy to repeat this stuff more than once and he’ll soon get annoyed).

Bottom line: Do up front analysis and be proud of it. Make it just-enough in a format that is appropriate (so why is it suddenly OK that it is on the Wiki rather than in a Word document on the corporate LAN?) Get it out there!! Stick it on the walls, let everyone see the business objectives, who the users are (personas), the competition, the wireframes, the product mission statement.