This is the second of possibly a few posts about my “aha moments” at Agile Roots. In addition to pairing with Janet on two sessions (see previous post), I was lucky enough to pair with Amitai Schlair (see his awesome Agile in 3 Minutes podcasts) for a DevOps Dojo.
The code’s ready. Wait, what is this data?
We asked participants to pair up, with one person playing the role of Dev, the other Ops. Our “product” was a script to print labels (see GitHub for workshop material). We began with Devs throwing their code over the proverbial wall to Ops, who provided the production data. No surprise, addresses such as “Belling, Vicar of St Loony Up the Cream Bun and Jam,Arthur,Rev.,789 Incubator-Jones Crescent” tripped up our software.
After a retrospective, the Dev and Ops pairs worked together (hey, that was the conference theme!) to drive the scripting with tests involving the “prod” data.
Feeling their pain
In hindsight our exercises were a bit simplistic, but hey, we only had 90 minutes. More important to me was that we had real-life Operations people in our workshop! I was fascinated to hear their “war stories”. One pointed out that the last person to touch the code gets the blame when things go wrong. In my experience, sometimes this is Test – but of course, if Ops deploys the code to production, they get the blame first.
Experiments to try
In the last section of our workshop, we brainstormed on ways each participant could go back and foster dev – ops collaboration in their own organization. One interesting idea was “monitoring-driven development”. Ops can provide helpful production metrics as well as helpful tools. This can be effective for things like improving product performance.
One Ops person said he collaborates with Dev to do Operational Release Tests on an unused prod server before doing the official prod deploy. Making a plan for easy rollbacks seems obvious, but sometimes is neglected.
We talked about the need to support each other, and build trust across the organization. Even dipping your toe in the pairing water with 10 – 15 minute Dev-Ops pairing sessions can help.
Trust often simply has to be earned. If you can show how
your tests keep bad problems out of production, others will pay attention. A one-team approach helps build relationships and break the chain of blame.
The importance of empathy shouldn’t be a surprise, but I hadn’t thought about Dev – Ops collaboration so much in those terms until the Ops folks in our workshop told their stories. We need a mindset shift. A “Not my problem” attitude doesn’t build relationships.
Your experiments?
If you were in our workshop, I’d love to hear if you tried any of the ideas we discussed in the workshop. If you weren’t in our workshop, I would still love to hear about anything you’ve done to build those bridges between Dev and Ops.
It’s not news, but… why aren’t we all doing this already?
The lines between testers and programmers have blurred in recent years. So have the lines between operations and other roles on the software delivery team. We may be better off thinking in terms of competencies rather than roles. Working Together ™ to guide development with tests from the Ops perspective as well as that of testers and others is, to me, the obvious way to go.
