 |
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:
Because whiteboards are often
shared you need to identify a protocol for when to erase
them. Here
are my rules, in order of importance:
- Everyone should erase their own work once it is no
longer needed.
- 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.
- If you need a board, and there’s no message or
the erase date has expired, then erase it.
- 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.
- Don't ever spit on the whiteboard to clean it. Not
only is it gross, it means that subsequent writing
will not 'take'.
- 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.
When you are modeling on a
POW, consider the following advice:
- 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.
- When discussing alternatives don’t erase someone
else’s work, instead draw your own vision beside
theirs.
- Ask for a marker from someone, even if you only
gesture for it, don’t simply take it from them.
- Keep your voices down, others may not be as
interested in your discussion as you are.
- 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:
-
Immediately discard dry
markers.
-
Put the caps back on the
markers after use.
-
Leave supplies at each
whiteboard, including at least one working marker
and one eraser.
-
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.
-
Purchase quality markers with
strong tips, some soft tips smush up easily and need
to be discarded.
-
Don't take supplies from
another whiteboard if there are new ones in the
supply cabinet.
-
If the supply cabinet is
missing something or is about to run out, tell the
person responsible for ordering new supplies.
-
Never wear white clothes.
-
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.
-
Protect your whiteboard.
Don’t tape things to whiteboards and
don’t use non-whiteboard cleaners because they
will ruin the surface.
-
Remember that whiteboards are
public forums – don’t write anything you
wouldn’t want to show your mother.
-
Don't take a portable
whiteboard out a room if isn’t meant for you.
-
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.
-
Have a well-ventilated room.
-
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.
 |
|
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. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
