I came across this blog post on the Developer Art blog on preserving and sharing project knowledge. I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.
This is a topic near and dear to my heart. Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times. They can lead to information overload, but to me, it’s worth the risk. You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them. I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact. The act of recording the information also helps me remember it.
When it comes to project management, the most important things to track for each what are the who and the why. As the world changes around (and inside) a software project, decisions often need to be reevaluated, and that can’t be done without knowing the context the decisions were made in.
In the Agile world, we tend to build our design straight from user requirements (or stories). Done right, each change to the software can be traced back to the user story or issue report that required it. If the user story changes (the customer now wants single-sign-on centralized authentication instead of a separate user/password database), one should be able to find the code that implemented the user story the old way, even if it means searching your SCM system’s commit comments for some standardized tag like #US213.
I have, in the past and present, used a wiki for project knowledge management. This worked very well, because being able to hyperlink between pages means less duplication (reference the other page instead of duplicating content), and because it can be done collaboratively and gradually over time. Any knowledge management methodology that takes too much work to maintain or distribute will not work, just like any other project management tool. For instance, Word processing documents and spreadsheets fail epically as collaborative tools, because multiple people can’t work on them at the same time without passing the One True Latest Version back and forth, and there can be any number of outdated copies. There’s no clear way to know if you have the latest. With a wiki, there’s only one instance, so there’s no questioning whether it’s the latest or not.
Another project knowledge management technique is to rotate people in and out of the project, so more people get exposed to it. I like to think of this as RAID: Redundant Available Informed Developers. At one company I worked in that utilized pair programming, after most month-long iterations, most developers would be moved to a different project such that someone who knows the project well would be paired with someone who didn’t.. This is still old-style word-of-mouth, but with the advantages of more ears aimed at the mouth.
Agile teams tend to use physical whiteboards and index cards. I know I’m in the minority on this one, but I never really liked that. Even when you don’t have distributed teams, it means your team has to meet in that conference room, and even doing a quick status email for your boss whose out of town requires you to go to that room, if it’s available. It also makes that room unavailable for meetings with non-employees who shouldn’t have access to that information. I prefer a web-based solution. Put a project or big LCD screen in the conference room and you can bring up any project you want. There’s a log of who changed what, it can be backed up, and can even have security to control who can see/change it. These tools can be used whether you’re running Agile or not.