In his book, Agile Software Development (Addison- Wesley, 2001), Alistair Cockburn argues that the most effective means of communication between two people is sketching at a whiteboard. Most developers seem to agree--take one look around any IT organization and you quickly see that whiteboards are in common use for modeling software systems. In part, this is because they're inexpensive, flexible and easy to work with. More importantly, when used properly, whiteboards can be very effective tools.
As far as I'm concerned, the more whiteboard space, the better: I believe that empty wallspace not covered by whiteboards is an affront to professional developers. I'm convinced that you should identify some boards as personal whiteboards of individuals to guarantee that they always have access to their own workspace. Some whiteboards should be designated for the use of a specific team, enabling them to develop and maintain shared diagrams throughout the project lifespan, hence reducing their need to write internal documentation. Finally, some whiteboards should be designated as public, available for anyone to use.
Some project teams don't have sufficient whiteboard space--either their facilities management refuses to install the whiteboards, or the walls are strangely shaped (they're small or curved ...). When this is the case, consider taking the matter in your own hands and cover your walls with plastic flip-chart sheets that statically cling to the wall; or go further and purchase whiteboard wallpaper to permanently cover up those dreaded wasted spaces.
Tabula Rasa
Because whiteboards are often shared, you need to identify a protocol to determine when to erase them. Here are my rules, in order of importance:
1. Everyone should erase their own work once it is no longer needed.
2. If you want to save your work for a future working session, you must include a message indicating this, including your name, contact info and an erase date-- after which someone is allowed to erase it.
3. If you need a board and there's no message or the erase date has expired, erase it.
4. If a message says "Do Not Erase," but doesn't include the other required information, you should think twice about erasing it. You don't want useless, undated diagrams proliferating, because you'll quickly run out of whiteboard space.
5. Don't ever spit on the whiteboard to clean it. Not only is it gross, it means that subsequent writing will not "take."
6. If you've used a permanent marker on a whiteboard, use whiteboard cleaner to erase it or simply go over the writing with a whiteboard marker to loosen the permanent ink.
Whiteboard Etiquette
When you're working on a whiteboard, consider the following advice:
1. To increase the quality of your work, try working with several people: Follow Agile Modeling (AM)'s practice Model With Others.
2. When discussing alternatives, don't erase someone else's work; instead, draw your own vision beside theirs.
3. Ask for a marker from someone--even if you only gesture for it, don't simply take it.
4. Keep your voices down. Others may not be as interested in your discussion as you are.
5. Invite others to participate by passing them a marker or simply moving away from the whiteboard. This makes it clear that you've opened up the floor to others.
Supply and Demand
You can improve the way that you manage whiteboard supplies with the following techniques:
1. Immediately discard dry markers.
2. Put the caps back on the markers after use.
3. Leave supplies at each whiteboard, including at least one working marker and one eraser.
4. Don't use a marker if you aren't positive it's for whiteboards. Consider purchasing only whiteboard markers even for working on flip-chart paper. Yes, whiteboard markers dry out faster, but you don't risk any accidents this way.
5. Purchase quality markers with strong tips. Some soft tips smush up easily and need to be discarded.
6. Don't take supplies from another whiteboard if there are new ones in the supply cabinet.
7. If the supply cabinet is missing or low on an item tell the person responsible for ordering new supplies.
Finally, here are some general tips and techniques:
1. Never wear white clothes.
2. Use color effectively. If you're going to use color to indicate meaning, you must agree to your color scheme first. Many teams will choose to define their color usage in a reference box on the side of their diagrams.
3. Protect your whiteboard. Don't tape things to whiteboards, and don't use non-whiteboard cleaners because they'll ruin the surface.
4. Remember that whiteboards are public forums--don't write anything you wouldn't want to show your mother.
5. Don't take a portable whiteboard out of a room if isn't meant for you.
6. Consider making a copy of critical diagrams. Although you can manually copy the diagram onto paper or use a printing whiteboard, my tool of choice is a digital camera. You can improve the quality of the picture with software utilities, and then share it electronically on your project Web site or by putting it under version control. Take pictures from an angle to avoid the flash reflecting on the board.
7. Work in a well-ventilated room.
It's important to understand that one size does not fit all; you'll want to develop your own set of rules and guidelines for whiteboard usage.
I would like to extend my gratitude to Philippe Back, Brian D. Bertien, Dale Emery, Karen Lopez, Les Munday, Paul Oldfield, Jim Standley and Robert M. Wilson for the input regarding this topic that they provided on the AM mailing list.
Recently on the Agile Modeling Mailing List:
Essential use case modeling. The trade-offs and techniques associated with essential use cases, a simplified and abstract form of use cases that capture the intentions of a user in a technology- and implementation-independent manner. Essential use cases are very useful for exploring the real usage requirements of a system, whereas "traditional" system use cases are more appropriately used as analysis and even design artifacts because they reflect architectural decisions such as your user interface design.
Modeling uncertainty. An interesting conversation started about how to indicate information that you aren't sure about on your diagrams. Several viable options were discussed, including using a specific color, fuzzy lines, a specific symbol such as a question mark, or simply adding a note to your diagrams.
Class modeling guidelines. Style guidelines for working with UML class diagrams were discussed after I announced the posting of my initial thoughts on the subject at http://www.modelingstyle.info/.
Recommended Online Resources
Agile Modeling Mailing List
http://www.agilemodeling.com/feedback.htm
Visit this URL to find out how to get involved with the
AM mailing list. Everyone is welcome.
Agile Modeling: Best Practices for the Unified Process
and Extreme Programming.
Scott W. Ambler (Wiley, 2002).
The AM book is finally available. Read more about it at
http://www.ambysoft.com/agileModeling.html.
Agile Software Development.
Alexander Cockburn,
(Addison-Wesley, 2002). This book is an excellent
overview of the principles and concepts of agile
development.
http://www.amazon.com/exec/obidos/ASIN/0201699699/ambysoftinc/104-6654147-5100746
Avery Write-On Cling Sheets
http://www.avery.com/
DryErase Wallpaper
http://www.whiteboardsetc.com/WhiteboardWallcoverings.htm
"Easy Does It," Software Development, March 2002.
http://www.sdmagazine.com/documents/s=4077/sdm0203h/0203h.htm
In this column I discussed the importance and viability
of using simple tools, such as whiteboards and index
cards, for modeling.
Modeling Style Web Site
http://www.modelingstyle.info/
This Web site, a work in progress, presents a
collection of pages describing techniques for
describing how to create effective UML artifacts such
as use case and class diagrams.
Software for Use: A Practical Guide to the Models and
Methods of Usage-Centered Design
by Larry Constantine
and Lucy Lockwood (ACM Press, 1999). This book
describes several modeling techniques including
essential use cases.
http://www.amazon.com/exec/obidos/ASIN/0201924781/ambysoftinc/104-6654147-5100746
Whiteboard Photo
http://www.websterboards.com/products/wbp.html
This software can be used to clean up your pictures and
to convert them to a format suitable for optical
character recognition (OCR) software. The software is
inexpensive and easy to use.
