[Sigia-l] We could just use whiteboards instead.

[Marc Rettig]

Matt,
I should have made it clear that the "enthusiastic VP" incident happened
during concept generation -- deciding what to make. Having captured
stories about the present, and made visual, conceptual models of the
patterns and themes in these stories, we were generating stories of
possible futures that were *grounded* in our field research. So this
particular incident happened about a third of the way through the project,
when it is *important* to keep everything loose.

My personal preference is to use the walls for initial construction of key
team deliverables -- we make things together. At some point all the big
decisions have been made, and the thing starts to gel. Then it is time to
institute rules about how it gets changed. So, for example, suggested
changes or new issues might be put on a different color sticky or written
with a different color of marker. Some one or some  part of the team has
ownership of that piece of wall, and is responsible for  incorporating
changes, facilitating work sessions about issues, and so on.

Some percent of the things you make on the wall are things you need to
document electronically, or maybe even tidy up and make pretty for
presentation to stakeholders. Some other percent can just be thrown away
(or better, photographed then archived in a box somewhere). As the Agile
Development folks say, "YAGNI" (You Aren't Gonna Need It). I prefer to
take time for tedious electronic representation only when it is something
that will be archived or distributed.

Once things are in electronic form, I agree with everything you said about
having someone own the versioning and change management.

I'm sure I've been vague about a lot of things. Part of the territory in
this medium, I'm afraid. While I was writing this a post came in from Ziya
about "design by committee," which makes me realize that I have glossed
over a lot about work style, believes about collaboration, and so on. Like
software tools, walls and post-its in themselves have no magic power. They
aren't a "method." I happen to be enthusiastic about a fairly methodical
approach (*not* design by committee) that involves small groups of people
making things together throughout the project, and I find paper and walls
to be Just The Tool for that way of working. Create it with atoms,
document it with bits. Issues like change management aren't really a big
deal in practice, because any one of these constructs develops over a few
hours or days, with all of its creators/owners in the room the whole time.

You asked about tracking the history of changes. For some kinds of
constructs-on-the-wall, this is answered by never taking anything down,
instead covering up the old with the new. I once worked on a design for an
intranet product, during which a "product snapshot" wall developed over
the course of about eight weeks. At first it was made up of rough pen
sketches of the pages, making a sort of storyboard. These were covered by
computer-drawn mockups of increasing fidelity, then more layers made from
screen shots of the actual product, piling up as we went through revisions
and iterations. So at any point you could walk up to the wall and scan the
current state of the entire product. If you were wondering how something
came to be the way it was, you could dig back through its layers and read
all the stickies representing issues, decisions, and "done by Joe
mm/dd/yy" stickies. This was *much* more accessible than anything on a
file server, and one of the most commonly heard phrases on the project was
this: "Good question -- let's go over to the wall."

I'll have to shut up about all this after this too-long post, because I'm
facing a deadline. I'm sure my description left holes and opened
questions, but to cover all this for real would require a book or a
course.

Cheers,
Marc Rettig


Matthew Rehkopf wrote:

> How does one manage revisions and reasons for
> revisions when all of the information on the system is
> "loose" on the wall? It seems that with so many people
> able to make changes, that decisions made prior would
> eventually get overwritten because the "changer" was
> not aware of the decision, or no one remembers why
> something was placed in a particular spot. I guess
> this is a question for all of those that work with
> stickies until the product is nearly fully designed...
>
> I have found that using digital files and having one
> person be in charge of the latest version prevents
> decisions from being reversed. I am sure that we have
> all worked with clients who, months into the project,
> start requesting changes that contradict decisions
> that they made earlier. Having digital files and
> tracking changes, I have found, helps to remind us of
> where we were, and the reasons why the design evolved.
>
> In working with groups with tasks, needs, flow, and
> pages up on a wall, how is this risk of reverse
> decision making avoided?