Beautiful Testing

Delivering Value

When Brian Marick interviewed me for “Travels in Software,” he asked me an interesting question: “What would you go back and tell your 2003 self?” The most important thing I wish I had known back when our team first implemented Scrum was that we really needed to understand the business inside and out. Not only the parts of the business automated in our software, but all the manual operations, accounting, marketing, and sales—everything that makes the business succeed.

Everyone Owns Business Problems

A year into agile development, our team effectively used TDD to produce robust, stable code. We were automating 100% of our regression tests, and devoting significant time to exploratory testing. Too often, though, we failed to deliver the exact functionality the customers wanted. We missed or misunderstood requirements, especially in areas outside the main application, such as accounting. We sometimes missed ripple effects that changes in one part of the system had on other, seemingly unrelated parts.

Problems not caused by software defects also troubled us. Application users made mistakes that had to be corrected with manual data changes. How could we make the system more “foolproof,” and could we provide software to allow users to unravel their own messes? How could we maximize the ROI of the software we delivered every two weeks?

We decided to budget time to study the business more closely. Sitting with our customers as they performed their daily processing, we found ...