Agile process documentation

I went to AgileAustin last night and watched a panel discussion on architecture. The discussion largely took a how-do-we-deal-with-the-fact-that-management-will-not-approve-a-rewrite theme, but more interesting (to me) was an early tangent on how an Agile process could produce documentation.

One of the participants in the audience asserted that there is a false perspective that an Agile process is a panacea and that in fact, yes, you still have to know what you are doing or you will just build a big ball of mud with Agility. The incremental process will let you realize that you're doing something wrong quickly, but nothing more. One of the panelists suggested that a sprint zero to set up some architecture could be a wise move.

In building a product, Geoff Meyer of Dell, suggested that one could go to the product owners for some example, initial use cases by asking about whom the competition is and what some things to potentially test could be. Get the owners involved in the details and get marketing claims out of process. The marketers should be able to see how they'll write promotional materials based upon what you are to bake in the first few sprints, so the marketers will be doing some work paralleling the developers. Herein some documentation may be driven by want for money instead of being sidestepped as a waste of time as might be the norm. I thought it was a good first step to deal with this problem.

As I sit here typing this up it seems like the marketers would also want to detail what differentiates their product from rivals, and that initial sprints would be of differentiation as much as of a generic foray into the space at hand.

Geoff Meyer is shown in the center of this photo and the panelist at his left (looking towards the camera) is Ryan Vanderwerf of ReachForce. The panelist at the left of the photo is David Sheth of Calavista.

The event was moderated by Lee Fox.