This fourth post in the Making Software Quality Visible series describes a rare encounter with an automated testing Laggard that ended really well for everybody. It expands on the first of two footnotes from the previous post in the series, Formative Experiences at Google.
I’ll update the full Making Software Quality Visible presentation as this series progresses. Feel free to send me feedback, thoughts, or questions via email or by posting them on the LinkedIn announcement corresponding to this post.
Footnote from "Geoffrey A. Moore, Crossing the Chasm, 3rd Edition"
I do have one story about engaging a Laggard that had a genuinely happy, “everybody wins” ending. During my first Test Mercenaries engagement, one member of the client team who was not a manager was clearly angling to become one. This person thought automated testing was a waste of time, and opposed what my Mercenary partner and I were there to do.
At some point, I proposed a chat with this person out on the second floor patio at the east end of Building 43. We were frank with one another about what our problems were—but then, quite unexpectedly, we found common ground. One of this person’s primary concerns had to do with overnight build breakages.
The Mountain View team would have working code (or, at least, code that successfully built) checked in at the end of the day. The team on the other side of the world would check in new changes overnight. The Mountain View team would pull the changes in the morning, only to find that the code failed to build. They spent time having to fix the breakages before getting to their own work, and the cycle continued.
At that point, I said one of the first things we could do would be to set up a Chris/Jay Continuous Build system. Then we’d enforce a policy that the build must remain green at all times, and any breakages must be fixed or rolled back immediately. These tasks happened to be part of the Test Certified program the Mercenaries were there to help the team adopt. It also happened that we could make immediate progress on these tasks without even requiring anyone to write tests at this point.
We were in full agreement, and went to work making it happen. I got the continuous build system working, the team adopted the “no breakages” policy, and the rest of the engagement continued successfully.
About a year or two later, I got an email from my erstwhile nemesis, who’d moved on to another project within the company. Much to my surprise, it was a thank you email—my nemesis had since become a strong automated testing advocate.
This kind of experience is the exception rather than the norm. My standard advice is to ignore Laggards and give them a wide berth. But sometimes you get unlucky such that you can’t get around them—but then, you might get lucky and find more in common than you’d expected. It’s amazing how shared objectives and shared success can bring about positive changes in people and relationships.
Coming up next
This event also inspired me to organize the Revolution Fixit in January 2008. I’ll cover that story briefly in the next post.