Got blank walls? Instead of hiring a decorator, perhaps you should enlist the help of a facilitator. This article examines how three experts use the wall in very different ways to make retrospectives, design, and collaboration better and easier.
One of the most valuable tools in the software development process may be staring you right in the face every day: your wall. That's right, your wall. Whiteboards and flipcharts barely scratch the surface of the elements you can tack up on that boring white wall to gather information, analyze it, and glean valuable insight and direction. We will examine how three experts use the wall in very different ways to make retrospectives, design, and collaboration better and easier.
1. Case Study Esther Derby on Retrospectives: Sizing Up Your Project
A typical project review consists of looking at the project plans, the effort hours, the defect data, and other similar information to answer the questions: What went well? and What should be done differently?
"These are good questions," says Esther Derby of Esther Derby Associates, Inc., "but, they aren't good first questions." Instead, Derby's retrospective wall tool has teams answer the questions: What did we do? and How was it for us? The answers are captured on a piece of rip-stop nylon sprayed with adhesive or a simple brown sheet of paper draped on a wall.
"I ask people to recreate the timeline for a project and list all the events that were important to them." These events are written on index cards and stuck on the wall in the appropriate time slot—Q1, Q2, November, December, etc. (see Figure 1).
Once the timeline and events are in place, each team member is asked to draw what Derby calls an energy line above the timeline. The energy line measures project energy or job satisfaction as the project work" at the bottom to "was excited about the project" on the top. For example, an individual line might start out high at the beginning of the project, dip back and forth between the top and the middle for a while, and then dip down to the bottom to correspond with a particular event. Derby explains, “We have the events and then we have how people responded to the events. We step back and look at it, searching for shifts and patterns. We examine what was going on in those periods of time when things on the project were going well for people, and also what was happening when people were just not enjoying their time on their project at all.
"People get a very different set of insights from looking at a project this way than they do from just looking at the hard data, or from asking the usual questions." For example, one group that Derby worked with noticed a huge dip that coincided with a senior management pep talk, where coupons for Starbucks coffee were promised to the developers who fixed the most bugs in their code. Why did such low energy center around a reward? Derby explains, "There was this one little event card up there that said, 'zero coffee coupons.' And this came from a guy who wrote solid code. He was never rewarded because his code was solid." Having this information out there allowed the group to discuss the reward system, as well as have some closure to the negative feelings that had cropped up as a result of the misguided reward effort. "I doubt that would have come up had we just been looking at the hard data of the project," says Derby.
As with any tool, there are some safety issues to consider, mainly emotional and psychological. "If people are afraid to say what's true for them because they will be ridiculed or punished, or it’s going to show up on their performance evaluations, they are
