TITLE: Robert's Rules of Order and Agile Forces
AUTHOR: Eugene Wallingford
DATE: May 15, 2009 8:30 PM
DESC:
-----
BODY:
I am coming to a newfound respect for
Robert's Rules of Order
these days. I've usually shied away from that level
of formality whenever chairing a committee, but I've
experienced the forces that can drive a group in that
direction.
For the last year, I have been chairing a campus-wide
task force. Our topic is one on which there are many
views on campus and for which there is not currently
a shared vision. As a result, we all realized that
our first priority was communication: discussing key
issues, sharing ideas, and learning what others thought.
I'll also say that I have learned a lot about what I
think from these discussions. I've learned a lot
about the world that lies outside of my corner of
campus.
With sharing ideas and building trust as our first
goals, I kept our meetings as unstructured as possible,
even allowing conversations to drift off topic at times.
That turned out well sometimes, when we came to a new
question or a new answer unexpectedly.
We are nearing the end of our work, trying to reach
closure on our descriptions and recommendations.
This is when I see forces pushing us toward more
structure. It is easy to keep talking, to talk
around a decision so much that we find ourselves
doubting a well-considered result, or even
contradicting the it. At this point, we are usually
cover well-trod ground. A little formality -- motion,
second, discussion, vote, repeat -- may help. At
least I now have some first hand experience of what
might have led Mr. Robert to define his formal set
of rules.
It occurs to me that Robert's Rules are a little
like the heavyweight methodologies we often see in
the software development world. We agile types
are sometimes prone to look down on big formal
methodologies as obviously wrong: too rigid, too
limiting, too unrealistic. But, like the
Big Ball of Mud,
these methodologies came into being for a reason.
Most large organizations would like to ensure
some level of consistency and repeatability in
their development process over time. That's hard
to do when you have a 100 or a 1000 architects,
designers, programmers, and testers. A natural
tendency is to formalize the process in order
more closely to control it. If you think you
value safety more than discovery, or if you think
you can control the rate of change in requirements,
then a big process looks pretty attractive.
Robert's Rules looks like a solution to a similar
problem. In a large group, the growth in
communication overhead can outpace the value gained
by lots of free-form discussion. As a group grows
larger, the likelihood of contention grows as well,
and that can derail any value the group might gain
from free-form discussion. As a group reaches the
end of its time together, free-form discussion can
diverge from consensus. Robert's Rules seek to
ensure that everyone has a chance to talk, but that
the discussion more reliably reach a closing point.
They opt for safety and lowering the risk of
unpredictability, in lieu of discovery.
Smaller teams can manage communication overhead
better than large ones. This is one of the key
ideas behind agile approaches to software development:
keep teams small so that they can learn at the
same time they are making steady process toward
a goal. Agile approaches can work in large
organizations, too, but developers need to take
into account the forces at play in larger and
perhaps more risk-averse groups. That's where
the sort of expertise we find in Jutta Eckstein's
Agile Software Development in the Large
comes in so handy.
While I sense the value of running a more structured
meeting now, I don't intend to run any of my task
force or faculty meetings using Robert's Rules any
time soon. But I will keep in mind the motivation
behind them and try to act in the spirit of a more
directed discussion when necessary. I would rather
still value people and communication over rules
and formalisms, to the greatest extent possible.
-----