A wiki is a simple and powerful tool for collaboration of any sort. Wikis are perfect for story documentation or...
artifacts throughout the application development lifecycle. Not only can you organize all your information, but a wiki is a potent tool for teamwork and collaboration, making it an excellent tool choice for distributed teams.
The three basic operations of a wiki are:
- Anyone can create a wiki page
- Anyone can edit an existing wiki page
- Anyone can link one wiki page to another wiki page
Modern wikis have other features added:
- Anyone can tag a page with an arbitrary tag
- Anyone can attach a file to a page
- Anyone can print, export, email a page
- And many other features, depending on the particular wiki implementation
Probably the most well-known wiki is Wikipedia. Anyone familiar with Wikipedia is aware that each subject has a single page, and all the pages are subject to being updated by anyone at any time, with all revisions to all pages always saved.
But Wikipedia is a wiki designed to be an encyclopedia. Encyclopedias are not generally useful in a regular business environment. But the simple, powerful concepts behind wikis in general make wikis flexible for many uses, and as Wikipedia demonstrates, wikis scale efficiently to a large size.
An Agile example of wiki through an iteration
To demonstrate how a wiki might be used in application lifecycle management (ALM), consider a theoretical example of how a wiki could facilitate a classic Agile process.
An Agile development process generally starts with story planning. Product owners (POs) or business analysts (BAs) create descriptions of new features called "stories" to be implemented in future iterations. Let us imagine an Agile team managing an iteration using a wiki:
To begin, our product owner creates a wiki page called "User can order our products online." The page contains a brief description of how ordering our products should work. The product owner creates a tag for the page called "story" and adds another tag to the page saying "being planned." The wiki page for the "User can order our products online" story will eventually say something like:
- User can navigate to the product catalog
- User can choose at least one product to purchase
- User can submit a credit card number for purchases
- User can submit a delivery address for the products purchased
- User can complete the purchase
In the course of noting the details of how a user should order a product online, it quickly becomes apparent that this story is too big and needs to be broken down into smaller stories.
So the product owner removes the tag "story" from the wiki page and replaces it with a tag saying "epic" to show that this page will refer to smaller stories on other pages. The epic page now has five individual stories on it that the team can develop in some iteration or another.
In order to manage each individual story, the PO creates links from the epic page to new pages for each of the five smaller stories. The PO tags each of the smaller story pages as "story" and also, like the epic page, as "being planned." Because this is a wiki, anyone who looks at the epic page can see that there are five stories for the epic, and anyone who looks at any of the story pages can see the incoming link from the epic page. When the descriptions of the five stories are complete, the PO changes the "being planned" tags on all of the pages to "ready for implementation."
Of course, story planning is ongoing, so there are many other stories and epics also undergoing this process simultaneously.
When the team is ready to implement some stories for the current iteration, it is a simple matter to retrieve all of the pages in the wiki with the tag "ready for implementation." The team decides that the "User may order our products online" feature is the most important feature ready for implementation. After a quick discussion of the five stories shown on that epic page (possibly involving Planning Poker), the team decides that all five stories for the epic are too many points for one iteration. The team agrees to tackle the navigate story and the choose story for the current iteration, and tackle the payment and delivery stories in a future iteration.
The team tags the story pages appropriately. The navigate and and choose story pages are tagged with "current iteration" and the other stories remain "ready for implementation." The team tags the payment and delivery stories as "epic in progress" so that they don't lose track that the epic feature will still be incomplete at the end of the iteration.
A common saying in Agile development is that "a story is a placeholder for a conversation." Since anyone can edit any wiki page, as the team learns more information about how to implement each story, they add that information to the story pages in the wiki so that everyone can see who knows what about whichever aspects of the story are important in their work.
The PO may edit the page to provide more details of how the story should work. The developers may edit the page to point out to others particularly tricky parts of the architecture, or add links from the page to a source code repository or other resources. Testers may edit the page to describe or to link to test charters or user interface automation to be created for the story. There is no reason not to use the wiki for defect reports associated with each story as well.
Since anyone can create, edit, and link pages in a wiki, the wiki itself becomes an instantly customizable tool for each particular team that uses it.
Retrospectives and history
Since wikis make it easy to link to any number of other wiki pages, the team decides that each iteration will have its own wiki page for the purpose of post-iteration retrospective. The team retrieves all of the pages tagged with “current iteration” and gives them a new tag "Iteration 42." The team easily creates a central wiki page entitled "Iteration 42" with links to all of the wiki pages created, edited, or linked during the iteration. This central reference helps the team remember what went well and what did not go well during the iteration.
Note that most modern wikis keep a record of every edit made to every page in the wiki. Over time, teams that use a wiki for process management create a history of every decision made by the team, who made it, and why it was made. This is helpful for any number of reasons: it is a record of the team culture, it is a reference for future decisions, and it is a resource for new hires. It may even serve a function for certain kinds of audit activity.
Wikis for process management
Process is fluid. Someone once said "if you've been doing Agile for a while and you're still doing it by the book, you're probably doing it wrong." Many process management tools require teams to do certain steps of the process at certain times, in certain ways. But not a wiki. The simplicity of a wiki allows the team to implement any process they find amenable. The power of a wiki keeps the flow of information among the people on the team consistent and available even as the process changes over time. And the inherent democracy of a tool where anyone can create, edit and link wiki pages makes it easy to have the "whole-team" approach to software development that is so critical not only to Agile development in particular, but to any successful development process.
For a comprehensive resource on social media, see Social media: A guide to enhancing ALM with collaborative tools.
Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)