of the practices you try to implement.
We will get to the essential practices, we promise. But before we dive in, we
need to spend some time on an XP value that can get lost in all the talk about the
mechanics of XP.
We told you in the last chapter that success on any software development project
is directly proportional to communication. One of the brilliant things about XP is
that it forces developers to communicate in order to get anything done. If left to their
own devices, most developers wouldn't talk much. XP makes that more unnatural
than not communicating.
Think about the person with you have the most intimate communication. Do you
ever produce a document for them to read so they know what you've been up to?
How about a weekly status report? Do you drop them an e-mail when they are in the
same building as you? When you're concerned about how they're doing, do you
schedule a conference room, invite a lot of other concerned people to come, and then
intimidate them into committing to doing more in less time?
We hope not. People in the same room talking to one another have the highest
bandwidth of direct and indirect communication. "Ken's got that look again…what
am I doing wrong?" "Andy, you look frustrated…is it with me?…do I need to slow
down?" "We're stuck…can anybody help?" Somehow, geeks and their managers
think that they can improve on that communication by using formal processes or
technology. Give us a break.
XP using four things to force and facilitate face-to-face communication among
the people involved in developing software:
1. pair programming (and switching often)
2. stand-up meetings every morning
3. planning (essentially, talking to the customer and to each other a lot)
4. a team atmosphere and environment that encourages impromptu
communication as the first line of defense
Pair Programming
We'll talk about more detail on the mechanics of pairing later (Chapter 13).
What's important to note here is that pairing makes programming an exercise in
constant communication, both within and among pairs. It does this in two ways:
1. replacing most written documentation with oral history and explanation
2. disseminating information through the "pairvine"
The theory goes, if you have everything documented then losing people is less
of a risk, because new people can come up to speed more quickly. It also should
keep everyone on the project in synch with what's going on, thereby maintaining
design consistency.
That doesn't work. On every "well-documented" project we've ever seen, the
pace of production was lethargic, it took forever to fix a problem (unless you broke
the rules), and the design was notoriously complex and confusing. New people don't
come up to speed quickly because the documents are outdated or incomplete. If they
want to find out what those documents mean, they talk to people anyway.
It seems that one of the curses of more heavyweight processes is that they treat
people as commodities. Not surprisingly, they usually end up with people who
blindly follow a process and aren't allowed to think effectively. It looks very much
like the "nameless horde" in that famous "1984" commercial Apple used to debut
the Macintosh. It strikes us as asinine to have a small group use their brains to
document an approach to the problems they think they have, and then have other
groups use their brains to interpret what the first group wrote. Maybe they'll have a
few cycles left over for programming.
We would rather encourage people to use their brains and collaborate to solve
real problems. Pairing does that by having people spend their time in the code.
When new people join, they pair with folks to learn rather than being handed a
document when they walk in the door. Pairs rotate frequently. That means code
knowledge gets passed around, as do development lessons, tricks, and so on.
A good illustration of the principle comes from an ongoing project Ken is a part
of. As he tells the story
I've used VisualAge for Java for quite a while. Wherever I go, I'm
pretty much considered the "VisualAge guru." But you know, there are
features I still don't know. One day, Duff asked me a question about
VisualAge I couldn't answer, so he went off to study the online help a
little bit. While he was doing that, he picked up a great trick for using
CTRL-Space to fill in method names automatically while you're typing.
I was out the next day. The following day, I was pairing with Karen. I
had the keyboard, and was just about to type out a long method name.
Karen said, "Stop, let me show you something." She hit CTRL-Space.
The least experienced programmer on the team taught me how to use
this powerful feature…The next day, I was pairing with Andy and he
asked, "What's the name of the method I need here?" Ready to show
off my new trick, I took the keyboard and hit CTRL-Space. Andy said,
"Oh yes, of course." Surprised, I said, "You already knew about
CTRL-Space?" He said, "Sure, I think it was John who showed me
yesterday." Within three days, everyone on the team had learned the
new trick, including a person who would have missed the
announcement had it been made. No one had to put together an e-mail
describing how to use the new feature. No classroom required.
If you are switching pairs around frequently, most of the verbal communication
you'll need to avoid surprises and to disseminate knowledge will happen. We're not
making that up. Now, for the real kicker. If you add Stand-Up Meetings, we predict
that more than ninety percent of that communication (some would say one-hundred
percent, if things are really clicking) will happen.
Stand-Up Meetings
Nobody will know everything all the time. That means everybody will require
some outside knowledge at certain points. Pairing is the first step, but what if you
don't know the details of what other pairs are doing, how can you know what they
need to know? And how can you get knowledge that you don't have when you need
it? The answer is the Stand-Up Meeting.
Trying to plan who will need to know what and when is a fool's errand. You
don't know everything yourself right now, and you don't know what you'll need
know tomorrow, because the problem will be different by then. Everybody else is in
the same boat. The trick is to communicate a little about what everyone knows, and
find out what they don't, on a regular basis. That way, people on the team can
identify who has the knowledge they don't have. That is what a stand-up meeting is
all about. It is a chance to hook up the people who have knowledge with the people
who need it. If you do it on a daily basis, the chance of missing the opportunity at
this important rendezvous are greatly reduced.
In fifteen minutes (or less, depending on the size of the team) you can:
get a sense of the trouble spots
identify who might be able to help
communication surprises to exploit or prepare for
make sure you are starting the day right
Replace your regular meetings with Stand-Up Meetings. Get everybody together
in one place and stand in a circle. Go around the circle and have each person share
what he did yesterday that might affect others, what progress he made yesterday, and
what he plans to do today. The only discussion allowed is the asking of questions
that have simple answers. Any longer discussion should be taken off-line. It's as
simple as that.
We do Stand-Up Meetings every day on all of our projects. It's a habit. And it's
amazing what gets done. Laurie Williams from North Carolina State University
stopped by late last year to bring a few of her students to be "flies on the wall" for a
day. She stuck around for our Stand-Up Meeting, but had to leave early for another
appointment. She interrupted Ken just long enough to say,
I hate that I have to leave. This has been amazing. The number of
issues that were raised and addressed in such a short period of time in
your Stand-Up Meeting is phenomenal.
And Ken thought we were having an off-day.
If it's so obvious that you should have Stand-Up Meetings, why don't people do
it all the time? There are several reasons:
you may have problems getting a quorum
people with the most knowledge might not share in the meeting
people with the most knowledge might try to share it all in the meeting
people might go into elaborate detail
it might be difficult to find a place to stand up together
If you have trouble getting a critical mass to show up, examine whether you've
communicated the reason for the meeting. If you haven't, do it. If they still are
skeptical, ask them to humor you with a one-week experiment. They will be
addicted in short order.
If people with knowledge seem reticent, identify why they won't open up. Many
times, the ones who think they'll get the least out of the meeting will be the ones
most likely to resist. They might feel threatened, because they feel their knowledge
gives them status, or they are scared it will be revealed that they don't know as much
as others think. Try encouraging them by acknowledging their importance and
asking them to share. If that doesn't work, ask your manager to encourage them.
Stand-Up Meetings are supposed to be short. If people spout off, Stand-Up
Meetings get long. Appreciate their knowledge, but remind them that the meetings
are supposed to be short. Direct other people to them for more information, but tell
them to take detailed discussions off-line. Thank them in advance for being available
for off-line discussions. Ask people to answer only the three questions:
1. What did you do yesterday that might affect others?
2. What progress did you make yesterday?
3. What do you plan to do today?
To develop the habit of being brief, interrupt long-winded speakers, but then
yield them some extra time when you suspect that there are a significant number of
people who want to know more. These folks are typically searching for significance.
Once you've given them the floor, they'll be less prone to take it unnecessarily.
If you can't find a place to stand up, ask management to rearrange your space.
It's not a lot to ask. Stand-Up Meetings take up much less space than is available in
a conference room. If rearranging the space simply can't (or won't) be
accommodated, ask someone in management if you can use their office while
they're trying to find a more convenient place. Make sure they understand that
scheduling a meeting room daily for a fifteen-minute meeting blocks other people
from using that space. It's also wasteful to make people travel five or ten minutes to
get there. As a last resort, you could try meeting in a hallway. It's not ideal, but it
usually keeps people from rambling, since they don't want to disturb others. It also
sends the message that it's more important to communicate than to travel to meet or
to be comfortable.
We would go so far as to claim that the Stand-Up Meeting ought to be the
thirteenth XP practice. We're certainly not advocating an explosion of practices. The
existing twelve are great. But we've talked to so many people who claim to be
having trouble implementing XP who aren't doing Stand-Up Meetings. We think
they wouldn't be having so many difficulties if they were doing them. We also think
that the need for Stand-Up Meetings is not as explicit as it should be in the XP
literature, or more people would be doing them as essential part of the discipline.
Discuss.
Planning
Planning in XP is very different from they way it's done in other methodologies.
This is a good thing.
Heavyweight methodologies tend to replace communication with formality and
documentation. This is most obvious with regard to planning. Various groups on the
project develop their own bottom-up estimates of work based on their understanding
of the requirements and of how they relate to the rest of the world. They develop
complex lists of dependencies and milestones. They have "checkpoint" meetings.
They disseminate status reports. They have contingency plans in case something
goes wrong. And they still get screwed up.
Roy worked on a huge project at a nationwide bank in the U.S. where all the
managers did was plan. At one point, between Release 1 and Release 2, the
management team spent over two solid months planning. The plans were so
complex, you needed degrees in finance and logistics just to read them. It seemed
like all the possible bases were covered (they better have been with all that detail).
But the project struggled constantly to keep its head above water. The plan was
effectively useless for keeping everyone informed and maintaining control.
The reason these other approaches fail is simple. There isn't much
communication going on. There is a lot of talking, and certainly a lot of paper, but
there isn't much communication. They say, "Make the plan, then follow it
religiously. All will be well." But there's something rotten in Denmark.
Requirements change. Your bottom-up estimates that you worked so hard to make
absolutely right…will be wrong. The complex dependency charts will miss
something.
The only solution is to increase the bandwidth of communication. Planning in
XP requires constant communication. Documentation is minimal (some note cards
are about all). Customers have to talk to developers, and vice versa. Everybody has
to listen. If they don't talk and listen, they will have no clue what to work on next.
Atmosphere And Environment
XP requires an open, group workspace to be effective. Why? Because Stand-Up
Meetings, planning, and pairing still aren't enough communication. Perhaps you're
getting the point that communication is paramount. We hope so.
Stand-Up Meetings and pairing cover about ninety percent of the
communication that has to happen to keep the team humming. It's the remaining ten
percent that we're talking about here. Often, people run into trouble in the middle of
the day. If it is their nature not to interrupt others, or to avoid asking for help, they'll
probably wait until the next morning's standup. That's suicide. Nothing will kill
your velocity faster than this (except a freak asteroid accident, but that's another
book).
People on your team need to start forming the habit of looking around at their
teammates whenever you have a break in the action. If they see frustration, concern,
anxiety, strange behavior, or simply lots of silence and little typing, they need to ask
those folks if they need any help. They can try to get them over the hump, or ask
them for help on something to get them away from their problem for a while. That
could break the logjam.
When emergencies happen, everybody needs to be within earshot. Someone
accidentally deletes something that everyone is using (hey, it happens). He says, in a
louder-than-normal voice, "TEAM, we've got a problem. I just deleted the project
files by accident and I need help recovering." (By the way, this is not a contrived
quote). Or maybe somebody at the integration machine can't integrate their stuff
because the existing tests don't run. "TEAM, we can't integrate. We're getting a
resource error. Can the last person over here help us out?"
Everybody on the team should be behaving this way. Looking around. Helping
out. Keeping people out of ditches. Asking for help when they are the ones in the
ditch. Letting people know vocally about emergencies that might affect them. You
can't do that with walls in the way. An open workspace where everybody can see
and eavesdrop on everybody else is critical.
[we need to put a picture of our studio here… we should probably put other
pictures in the book, too].
[we might want to put in the floor plan, too. The floor plan here. The floor plan
at OTC… anywhere else doing XP].
If you have to live in cubicle land, you can still do it. If the people you are
working with aren't close by, make sure people know that this is keeping you from
being as productive as possible. If it can be done, remove and/or rearrange the
cubicle walls… they are supposed to be moveable. Below is an example of some
things we've seen work pretty well.
[need to add picture here]
But don't let lousy cubicles be an excuse. In the early days of our first bix XP
client, we had to do all of our work in cubicles that were barely big enough for one
person. The only place the monitor would fit was in the corner. The keyboard was
on a shelf under it. To reach the mouse or trackball, you had to reach under the desk,
and your hand had about an inch of clearance. We did that for the first three months
of the project. It was awful compared to anywhere we've worked since. But the
client was convinced it was the way to go.
They extended our contract and found a small room that had been abandoned
and let us move up there. The project manager found some old desks that were being
scrapped that didn't have any drawers attached to them so people both fit there legs
under them. We arranged the room like this at first because we didn't think we'd be
able to arrange them in a way where we could face each other:
[picture needed]
It kind of worked, but people would bump into each other in the corners.
Then, after a few months, someone had an idea for rearranging them. They
brought in a tape measure and figured out we could do it. We rearranged the
furniture like this:
It made rolling chairs from place to place a bit difficult, but people could see
everyone else without having to turn completely around and it improved
communication and lessened the amount of chair collisions when people weren't
intentionally moving them.
Our studio is extremely spacious compared to this, but it works.
And don't forget the whiteboards!
Alistair Cockburn has pointed out that the most efficient form of communication
is two people at a whiteboard1. Good ones can be expensive and you might have
problems getting people to do the capital outlay. In our studio, most of the walls are
covered with whiteboards (and the whiteboards are usually covered with all sorts of
remnants of discussions). We priced good whiteboards and felt there had to be a
cheaper way. We went down to Home Depot and bought Mylar paneling for about
$20/sheet. Each sheet is 4' x 8'. We bought 10 of them and a bunch of tubes of liquid
nails. Some parts of the wall could not accommodate a 4' x 8' whiteboard. Nothing a
saber saw with a fine blade couldn't handle. So, we have whiteboards everywhere
you turn and it cost us less than $300 plus a bit of manual labor.
At the XP client who had small cubicles it was hard to find a place to hang a
whiteboard, so we bought some static cling white board sheets and put them on the
sides of the cubicles. Almost none of the conference rooms had whiteboards, either.
I've never seen so few whiteboards in a corporate environment. Even when there
was a whiteboard in a conference room, it was usually very small, and it was hard to
find dry-erase markers.
When we moved to the abandoned room, getting it outfitted with whiteboards
was not in the budget. So, one of the people in the group went to Home Depot and
bought 4 Mylar boards for $80 and submitted it as an expense. In a week or so,
"facilities" showed up to screw them into the wall. We probably had more square
feet of whiteboard in that room 300 square foot room than were present in the rest of
the 300,000 square foot facility! [need to check on the size of the actual facility]. I
know we had better communication.
Communication doesn't just take place among the development team. You can
improved your development process immensely purely by getting your developers
communicating to each other via the means we've stated above and others.
If I Could Talk to The Customers/Developers
But that is only part of the equation. Communication is vital between business
and development if you are going to play to win.
Read on.
No comments:
Post a Comment
Your comments are welcome!