My first immersion in to Scrum occurred at StorePerform. We produced workflow solutions for big box retail stores. The company retained an external coach on contract and we attended training, which eased and accelerated the transition. Throughout the time we practiced unit testing and had a continuous integration server running.

Keeping the Build Running

Code coverage for us ran at about 30-35% and we had a company policy to keep it over 80%. We used a code review system to ensure, among other things, that unit tests were created.

The team agreed that fixing a broken build was highest priority. The person responsible for breaking the build was awarded a stuffed GIANTmicrobes® “macro virus” toy to display at their desk and wait to award to the next person who broke the build.

A successful build meant the code compiled and ran. Success also meant that all unit, integration and functional tests passed.

Applying Test Driven Development

Our manager entered work one morning and called us in to a room. He pulled copies of Kent Beck’s book “Test Driven Development” (TDD) out of a large box sitting next to him and handed us each a copy. Our assignment for the day, he told us, was to go home and read it. Tomorrow we’d be coming back as test-first developers. It took awhile for it to sink in that he was telling us to go home and read a book, but we did.

We assembled the next day and discussed the book with our manager and each other. The conversation was moving at a pace that made me believe I wasn’t alone in having read the book. We agreed to test-drive any code we created and discussed what we would need to do to support that kind of work. This would increase our code coverage, we hoped, and using TDD would help us to hit the 80% company policy.

Getting the Same Result

After a couple of months, our code coverage was still running in the mid-30% range. At the time we worked mostly solo and after completing a big effort, we would schedule a code review with a lead engineer.

Creating the Motivation to Pair

Now that we were apparently adopting XP practices, a couple of us felt like trying pair programming. Our manager supported the concept. We asked around if people wanted to pair and most were not interested. A big concern raised from a couple of the leads was that tasks would take double the person hours to complete. Some developers also believed that it would slow them down from cranking out work.

The merits of pairing were discussed as we continued to work in front of small, low-resolution monitors that were not well liked by any of us. Our accounting department saw high-resolution monitors as too costly for everyone to have one of their own. I asked my manager about the feasibility of approving just one. Could we justify it as a low-cost way to experiment with pair programming and manage the risk of work slow-down for the team? I hoped that folks on the fence would try pairing as the larger, higher-resolution monitors were so coveted by every one of us.

Accounting approved the purchase request swiftly. Upon the monitor’s arrival, we set it up in a small room where nobody currently worked. The room we chose had a wall of windows that looked in to the building across the street from us. The room was large enough to accommodate two, or three, work areas. Setting up the workstation drew curious on-lookers who were told that anyone could work in front of the new monitor. The privilege required finding someone to pair with.

Practicing Pair Programming

Those of us who were interested created a schedule, with three two-hour pairing sessions each day. The demand for the sessions grew and pretty soon our manager was able to get a second monitor approved. We switched up the pairs each session and among four of us we had six pairs. We could all pair with each other every day.

Within another quarter we added two more large monitors. Some days our manager would also rotate through the pairs. We switched rooms so that most people could pair in the large room. The smaller room now became the space where people worked solo when desired.

The Results of Pairing

We found that code coverage increased every Sprint. We agreed to increase coverage by 3% a Sprint, instead of failing to obtain 80% coverage, and usually exceeded that amount. Pair programmers were not awarding each other the “macro virus” toy.

The time spent on task did not double as speculated and our velocity increased. We noticed a drop in bugs along with an increase in code coverage. Other code measures improved for our team, and it was getting quiet around the foosball table.

Work was becoming fun for us and we didn’t need to play games for distraction. We did have to start enforcing breaks at the end of a two-hour session. Time was flying by as we worked intensely together and the breaks helped us keep energy levels high during the day.

Code coverage passed 80% and that level was added to the definition of a successful build. Less than one bug per week was being produced, and we fixed most bugs within a  Sprint. We changed our working agreements again. We had fun building a system together that became easier to create and maintain.