You’ve talked about using wikis for documentation and tracking requirements or defects. However, with wikis, isn’t it difficult to do reporting or any kind of analysis on trends?
The advantage of wikis is that they promote collaboration. Everyone on the team -- indeed, everyone in the company -- is free to update the information on the wiki as they see fit. When it’s easy to find and update documentation, the documentation stays up to date. We can upload screenshots, mockups, graphs, any format of data that we want and make it easily accessible on the wiki. We can link to the automated tests, the “living documentation,” for each user story and feature.
Wikis have a dark side, though. It’s easy for them to turn into a jumbled mess, where nobody can find what they need. I highly recommend bringing a technical writer on board to help maintain the valuable information on the wiki, so that it is easy to search and retrieve documentation.
Wikis aren’t appropriate for tracking defects. If I’ve given that impression, I apologize. The information on a wiki isn’t highly visible, and indeed, it does not lend itself to any kind of analysis. Rather, it is a good place to store the results of our analysis for future reference.
As a team, decide on the areas where you want to improve, and set appropriate goals. Track those goals in a visible way: on a task or Kanban board, in the automated build or code coverage tool, in the defect tracking system, on the retrospective wall or impediment backlog. You can use the wiki as a repository for this information. First and foremost, though, make sure goals and information about progress towards them are out where everyone sees them every day.
This was first published in September 2011