Point At Whiteboard

Frequent readers of this column remember that our customers tell us what to do: they provide UserStories for each IterationPlanning session. We write the stories on the whiteboard, and then developers brainstorm the EngineeringTask's for each story. We sign up, estimate, and get to work.

Especially toward system delivery time (like now), we like to cross the tasks off the whiteboard as we go. It gives a sense of progress and urgency.

We noticed this week that not many stories were crossed off. The customer was nervous because it's so close to release and nothing was getting crossed off the board.

Inquiry showed that developers were working on tasks that were not on the board. Some of these were emergencies that had arisen; some were just things they thought they needed to do. Sometimes the stories should have been on the board; sometimes they didn't need to be done, in the customer's eyes.

We already have a regular 10 AM standup meeting, where everyone says what they've been working on.

We added a new practice: when you speak, you go to the whiteboard and point to the task you're working on as you talk about it. If it isn't on the board, it's obvious to all, and we can quickly decide whether it should be, or it should be dropped. And the real benefit is just that it helps us remember, in this stressful release time, to stay on track.

--RonJeffries

I HaveThisPattern. I've done this for a couple of projects. The strangest instance I've seen is the project where the manager taped sheets of paper to the whiteboard. I've never quite figured that one out.

--RobCrawford

One technique I have found useful for smaller projects to do a quick design is to have 3 programmers in the boardroom at the whiteboard. I divide the board into 4 sections by drawing one big vertical and one big horizontal line. I then draw a UseCase diagram that outlines the overall functionality in one quarter. We then pick the key UseCases and I make one of the programmers take the board to draw the sequence diagram in the second quadrant, with everyone contributing as to what objects to put and messages between then. Another programmer draws what is on the board as we go (may try WhiteboardPhotos? but drawing is quite quick if done as we go). We can selectively erase since we are copying to make more space. The person at the board then switches to the third quadrant to sketch the class diagram finally the fourth quatrant is used for any other notes or diagrams (process flow, RDBMS etc). Once we have the UseCases I let them come up with most of the rest, and more or less just facilitate. In this they the people doing the coding participate in the design and less time is needed to explain. Before I would do the design, explain it to one of them who would then have to explain to others if it required several people. This way everyone knows what to do much faster and less time is needed of me to create the same design. The more they do it the faster they become.