As a guest post on The Agile Executive blog, I was invited by Israel Gat to describe book sprints as an Agile method for documentation. Here is the beginning of the post and I encourage you to read the rest and comment on it there.
One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.
Nowadays, Google’s search power offers software users access to documentation through forums, mailing lists, even through blogs and wikis maintained by the developers and authors themselves. These new conversational methods for documentation, support, and education have opened new opportunities for those groups to add value to software adoption. Ways to provide additional value to the working software include helping people learn the software, troubleshoot the software, or do their job with the software. Education, uptake, and support are all integral to the overall value of a software product.
Value proposition
First, a discussion on the value added by good websites, updated and relevant training materials, and a helpful support staff. Those departments want to avoid the continual cost center perception. To do so, they find ways to add to the bottom line, such as:
- increasing sales (enterprise) or increasing adoption (open source)
- keeping users happy and satisfied
- adding contributors to the community, whether helpful troubleshooters or prolific coders
- decreasing support costs (in time and money)
- converting participation into value
- increasing positive perceptions of the software
In my experience, these values are universal to both enterprise software and open source software. Let me share my story.