There’s a fine line between learned helplessness and realism. DevOps begs people to make a massive leap of faith: If you change what you measure, alter your development practices, change your organization and culture, awesome things will happen!
There is more than one obstacle to overcome here. First, humans have a poor track record of executing change as individuals or groups. Second, metrics are often gamed. Third, it relies on people who were promoted to senior roles question the very things that got them promoted. The list goes on.
Yet, here I sit, typing at 11:20pm, my wife asleep in the next room, kids asleep in the room above my head. After spending the last 6 years of my life advocating for DevOps and its cousins, Agile, Lean, DevSecOps, DOTS (DevOpsTestSec), BizDevSecTestOps, etc. pushing a stone like Sysyphus, I still believe there’s hope.
I believe John Alspaw when he says you “start in the middle.” Pick a project. Change it’s metrics for Delivery & Operational Excellence. Stop them in their track to have them build a pipeline, with tests, that they break builds when failed. Worship the pipeline, the path to production with every change.
Working software wins. You can show people a working solution and create broad alignment. Or you can seek broad alignment and never get to work on a solution.
So here I sit, about to roll out Sonar to teams. We could preach at folks about it or we can implement somewhere and show what good looks like. Preaching creates 10 arguments in a room with 7 people. Showing what good looks like offers a path to participation people can follow.
DevOps require leadership. Not by title. Leadership by spirit and commitment. Yes, top down support is critical to success. But until you hire a Bryan Finster or Ross Clanton as your CTO, you’ll need to provide evidence to non-believers. Evidence requires implementation. Build something that shows that going slow allows you to go fast. Spending time writing unit tests and actually making sure they passed helps team ship the right work at the right quality. Building monitoring as part of development supports a better user experience for customers. Deploying daily reduces failure rates and improves recovery times.
All of these things are empty messages of a faith-filled preacher with out evidence. Bring working software and the metrics that show business value. Talk to your Team about engineering for the best customer experience. Capture the data. And working software might win.
