The Information, the Opportunity, and the Mindset

There was a standoff in a recent project of mine. It had no gunslingers, hangman’s rope, or a pot of gold. The standoff was about how to work. I kept putting forward that considering the end-state as an information broker API and continually changing specifications most testing could be automated in code and contract testing applied to keep the interfaces under control. Any explicit testing besides that should be exploratory, be it in the team or by the customer. This would be in line with recent DevOps research about high-performing teams.

Developer owned testing (often assisted by testing “experts”) is proven to be highly correlated with quality and delivery. [I Don't Wanna]

The other parties in the standoff, had their mental model around elaborate test cases being key to control the work of the developers. The testers would be the gatekeepers of quality - with defined entry and exit criteria in all the testing phases. When shit hit the fan, it was on the testing team (sic) to have known every little detail, every state of the solution, and every tool in the belt.

Due to a contractual construct, the customer who would usually cut through the rope was tied in their mental model and way of working. The end of the sprint demo had quickly become a presentation of delivered artifacts, including elaborate test cases. How could they test without detailed instructions about the endpoints?

So there we stood. We could all see that something was wrong. To me, the biggest failure was to mistake it for a testing problem. The problem was inherently systemic anchored not so much in the actual work to be done - but in the way of working together.

I soon realized that I was cornered by the old Beckhard-Harris change equation. While I had the first steps and a vision - the dissatisfaction was with the testing approach. Beckhard-Harris change equation:

Dissatisfaction x Vision x First Steps > Resistance to Change.

The equation always seemed abstract to me, even with a math minor at University. But the story above and Alan's "I don't wanna" have helped me rearticulate the three equation parts I needed to align:

• The relevant industry Information about how to solve challenges
• The Opportunity to solve the challenge
• The growth Mindset to embrace challenges based on new information

We need all the parts equally. We can have all the information and models of the DevOps world, but with no places to do them, it's no use. We can be stuck knee-deep in busy work, but without information about how to get out, - we get nowhere. The ugly head though is with the growth mindset - the willingness to embrace change.

If the data say that developers owning more testing and operations aspect of their software is beneficial - and your response is “not my job” - your growth is limited [I Don't Wanna]

The information (models, research) on how to design effective software teams is around. The practical situations where this research applies are abundant too. The key factor is acting on it. And with that, the stand-off was over for me.