Take one look around any IT organization and you quickly see that plain old whiteboards (POWs) are in common use for modeling software systems.  In part this is because whiteboards are inexpensive, very flexible, and very easy to work with.  More important is the fact that POWs, when used properly, can be very effective tools.  The end result is that POWs are a preferred tool of agile modelers.

Free Download: Whiteboard Etiquette Rules, a one page PDF summary that you can print and put beside your whiteboard(s).  Requires the Adobe Acrobat viewer.

In this article I explore tips and techniques for improving your use of POWs.  It’s important to understand that one size does not fit all; you will want to develop your own set of rules and guidelines for whiteboard usage.   Here are my suggested rules:

• Erasing Whiteboards

• Whiteboard Modeling

• Managing Whiteboard Supplies

• General Tips

Erasing Whiteboards

Because whiteboards are often shared you need to identify a protocol for 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 so.  This message must include 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, then erase it.
4. If a message just says “Do Not Erase” but does not include the other required information you should make a judgment call whether you want to erase it.  If you don’t put the date on the diagram then useless diagrams will proliferate throughout your org and 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.  
   
   

POW Modeling

When you are modeling on a POW, consider the following advice:

1. It’s better to work with several people, e.g. follow Agile Modeling (AM)’s practice Model With Others, to increase the quality of your work.
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 from them.
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.

Managing Whiteboard Supplies

You can improve the way that you manage whiteboard supplies via 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 something or is about to run out, tell the person responsible for ordering new supplies.

General Tips

1. Never wear white clothes.

2. Use color effectively.  If you’re going to use color to indicate meaning, then 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 will 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 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 using software utilities and then share it electronically on your project web site or by putting it under version control.  Take pictures from and angle to avoid the flash reflecting on the board.

7. Have a well-ventilated room.

8. Designate some boards as personal whiteboards, some to a specific team, and some as public whiteboards available to anyone. 

As far as I’m concerned the more whiteboard space the better, and I believe that any empty wall space that is not covered by whiteboards should be considered an affront to professional developers.  Unfortunately some project teams will find themselves in a situation where they don’t have sufficient whiteboard space – either their facilities management people refuse to install the whiteboards or the walls are strangely shaped (they’re small, 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 empty spaces.

Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.