What do you mean by “do”?

In every coming-of-age story about a young, hopeful hero, there is a grizzled, wise man who says things about doing and being:

While writing our new ebook, Contested Development, we expected some grizzled wisdom about “doing” Agile and DevOps. Our interviewees didn’t disappoint, and they raised an interesting question: What do we really mean by “do”? And if you are doing, what are you “being”?

Let’s start with a comment from Glenn Trattner, COO of Quantum Metric:

“People say, ‘We implemented DevOps.’ You can’t do that. What did you actually do? Seriously, ask people how they ‘implemented’ DevOps, and they won’t be able to answer.”

Glenn is arguing that a prescribed set of actions doesn’t equate to “doing” DevOps. It’s not a religious conversion where you can just dunk your head underwater and say, “We’re Agile now. Blessed be Automation.”

Some organizations want to show the world they “do” DevOps and therefore are “being” Agile. It’s an identity play, a signal to the market that you’re with the times and not a fossilized company about to plunge off the Waterfall (method) to its doom.

Glenn wasn’t alone in questioning what it means to “do” something. David Hussman, Agile coach and founder of DevJam, identified another flaw in this word:

“More interesting is the use of the verb ‘to do.’ In English, you only use that verb in that way when you’re talking about something discrete. I’m going to ‘do’ the laundry. I’m going to ‘do’ the dishes. You do it, then it’s done. You can proceduralize the shit out of it. I can’t imagine Einstein saying, ‘I’m going to do some physics.’ It sounds so stupid! The nature of the work is experimental, not procedural.”

Glenn and David aren’t contradicting Yoda, Mr. Miyagi, and Ty Webb. The latter three never asked their disciples to “do” a system of ideas. The “do” wisdom applied to discrete actions. The “be” wisdom applied to a state of mind. Lift that stuff with the Force, or don’t. Practice Karate, or stop. Be the ball, Danny.

History is full of people who took a set of ideas too literally and proceduralized them. Trying to “do” DevOps procedurally backfires because you get a Soviet-style system where you don’t make the rules, but the rules make you.

What can we say instead then?

How about we study DevOps, do experiments, and be adaptable? If that interests you, a good starting point would be our new ebook, Contested Development.

Cassidy Knight
Cassidy Knight
Agile Coach, Cprime