I’ve the honor of having just been interviewed by the brothers Hunter, John and Justin, from Hexawise as part of their “Testing Smarter with…” series. You can now read another iteration of riffs on many of my favorite topics in the hot-off-the-presses “Testing Smarter with Mike Bland”. (Note that that link posts to the “blog” version, which itself contains links to the full “Testing Smarter with Mike Bland" interview.) Thanks to both John and Justin as well as Sean Johnson, the Hexawise CTO, who recommeded me for the series.
It’s long-winded, as is my wont, as I basically brain-dumped a first draft and the Hunters decided to cut very little, despite my offer to trim things up as they preferred. Naturally there’s a lot of overlap with and references to The Rainbow of Death. Still, as I’ve advised all these years and stated over and over again, a lot of culture change is about repeating yourself, finding more than one way to say the same thing, and being redundant to the point of tedium. Ad nauseam.
Case in point, there is one bit of insight in the interview that I hadn’t expressed anywhere before, I don’t think:
Hexawise: Our CTO, Sean Johnson, shared your memorably-named “Rainbow of Death” presentation with our management team. We absolutely loved it. In your presentation, you describe a series of concrete, practical steps you and your colleagues at Google took over the course of 5+ years to overcome resistance to change, educate teams, and successfully achieve broad adoption of automated testing efforts at Google across many teams, including lots of teams that were initially very change resistant. Can you please describe for our readers 2 or 3 noteworthy aspects of that change management journey?
Mike: What I hope the Rainbow of Death model, in combination with Geoffrey A. Moore’s Crossing the Chasm model, make apparent is that different people adopt change differently. There are many needs that need to be met by and for many different people, and the chances of figuring out the perfect plan to execute before taking any action are practically zero. After all, don’t the Agile and DevOps models that are all the rage comprise tools and practices for adapting to change, for performing experiments and adjusting course based on feedback? Organizational change is no different, yet many people remain conditioned to expect waterfall-like solutions to their social problems.
And true to form, I subtly reinforced the message a little later:
Hexawise: Large companies often discount the importance of software testing. What advice do you have for software testers to help their organizations understand the importance of expecting more from the software testing efforts in the organization?
Mike: Sadly, there’s no one message that works for every company, every culture, everywhere…. Back to the Rainbow across the Chasm, testing (and DevOps) adoption is more a human problem than a technical one, and many different solutions are required for many different people and many different parts of the problem. Just as we must be free to experiment and adapt when it comes to developing features and deploying releases, we must apply the same mindset to hacking our organizations.