For devs: how to befriend ops

Everyone loves devops. Well...at least most of the people I meet!

That love, however, sometimes needs a little push. Especially when there is some trust lacking on the holy work floor. Or when there is a lot of distance between dev and ops. Or...well, just paste your own less than ideal situation here.

Here's one powerful way for devs to befriend ops people:

Release rock solid stuff with rythm!

Now more than a year ago I hosted a session for ops people within a large organization. This session was titled "let's design a one-day go-live process!". All attendants were sent by their managers and they all had a look on their face that could make Stone Cold Steve Austin shiver in fear!

They welcomed me, a coach hired by the dev department, with black snowballs. Who the hell did I think I was to suggest a one-day go-live? 

Within the first three minutes of that session, they gave me all the arguments I needed to start understanding their position, their pain and their lament. 

These were people who work their butts off every day to repair whatever crap devs created. These people were responsible for apologizing deeply for trouble they did not create themselves. They fine people get out of bed in the middle of the night whenever an incident occurs. To analyze and fix what they didn't break. And these dedicated people shift their schedules whenever a project doesn't deliver on the date they promised to deliver for sure. Almost daily.

Thank you ops people. For being honest, open and collaborative. Yes collaborative, because even then they listened to the ideas that then lived to make life supposedly more easy for the company.

Now the "easy" way would be to just create full blown devops teams. Boom. There. Got a complaint? Here's a check, now find another job! We'll manage with the rest of you.

For some companies, that might work. Just change everything into fully accountable feature teams, delete most of ops and live happily ever after.

Alas, for some other companies that's too large a step. Some of these companies don't even know exactly what their product lines are or have unions to respect. Oops!

Fortunately there is a less disrupting road.

Any dev team could just start by writing better code. Code that breaks less. That's a first. To do that, the team needs better craftmanship and better testing. Not _more_ testing per se, but better.

But...sometimes these teams do not have the skills or the tools available to run proper tests! Or they don't "get" the time to practice refactoring, pair programming, do unit testing or anything else that would probably contribute to better code.

That's when a Scrum Master, Agile Project Leader, Agile Coach, Product Owner or basically anyone else being a true agile leader starts making a ruckus. 

They start raising the impediment. They seek the support of ops people in their quest for acceptable quality. Then they educate and experiment. Until things change and quality goes up measurably. Quite often it starts with things as simple as just writing better user stories, adding some acceptance criteria to the darn things or agreeing on a Definition of Done that makes actual sense.

The same goes for predictability. "Never change a promised delivery date" could be the motto of the agile leader. Why do some teams still create only one package per sprint and then even on the final day? How awesome would it be if they just could leave out all the stuff that isn't done done and get that lovely package out? Why is that still, after 14 years of Agile Manifesto, such a hard thing to do? (Not for you, of course. For all the others)

Imagine you're an ops person. Imagine you would receive a package on the day you expect it. Imagine that you run a test on it and find zero bugs. Imagine that you would have this experience over and over again with different teams during several weeks. Months!

Then imagine the cold sweat on you back for you know you are now obsolete because all teams

Release rock steady stuff with rythm!

Fortunately, most ops people are much smarter than just waiting around. They will join the band wagon much earlier and live happily in the now new created feature team.

Welcome aboard!