If You Have DevOps, Do You Need Agile?

Today when I hear that someone wants an Agile coach, they almost always add that it is highly desirable that the person also know something about DevOps.

What’s really going on there? Do they really want DevOps? Is it that DevOps folks aren’t good coaches? Is it that Agile and DevOps need each other? Is it that Agile is becoming DevOps? What do people really need?

One must be careful when discussing this, because if you ask two different “Agilists” what “Agile” is, you will get two different answers. The same is true of DevOps. And people can get quite emotional about Agile, particularly with regard to Scrum’s place in Agile.

It also depends--it really does. For example, what works for a startup almost never works for a large organization that has a complex digital platform containing many multi-component products. It’s a different scale. Just today a reviewer of a book manuscript that I am also reviewing wrote,

“When I worked at a startup, a single team definitely did implement an entire business feature. Now that I’m at a large enterprise, I feel the pain of needing multiple distributed teams to collaborate to deliver a new business feature. Size of company and org structure has to do with this.”

The reality is that there is no such thing as “Agile”, in a definitive sense. The Agile Manifesto proclaims some “values” and “principles”, but the interpretation of these spans a very wide range. What we have is a community of people--“Agilists”--who collectively have a set of ideas. Some of those ideas work in some situations.

And then there is DevOps, which does not even have a manifesto. DevOps also is a collection of ideas, and some of them apply in certain situations, and others don’t.

The ideas that one tends to find within the Agile community generally focus on team issues, particularly the human side of things. There are also ideas about how to organize and manage multiple teams, but there are multiple divergent and irreconcilable viewpoints.

Also, many of the ideas of the Agile community are pretty extreme, and are often advocated in their most extreme form: “self organizing teams” is one such idea.

Although, if one presses someone who advocates self-organizing teams, it is eventually revealed that they don’t really mean fully self-organizing: They will exclaim in exasperation, “Well of course self organizing does not mean completely self organizing!”--as if you are stupid for taking the phrase at face value. Or they will try to explain that “self organizing” and “self managing” are two completely separate things--as if “organizing” means something obviously different from “managing”.

And all this ambiguous vocabulary is only about a single team--let alone a collection of teams!

In contrast, the DevOps community’s ideas are mostly about very tangible things: how to build and rapidly deploy and test software at scale. It’s about the nuts and bolts, although there are some concepts that are key, beautifully articulated by Gene Kim’s “Three Ways”.

If DevOps is about actually building and delivering software, then why not just go with that? Unfortunately software is built by people, and DevOps does not say much about human interaction within a team and how to organize many teams. So if we were all robots, then yes, we could just go with DevOps.

Could we just use Agile and not DevOps? No, because Agile, which had technical roots early on, left those behind, and became almost entirely a touchy-feely idea space, focused on things like “team happiness” and human collaboration. Those are important things, but they are not enough to build software. The Agile community’s answer to the nuts and bolts of building software is generally “Leave it to the team, to self organize and figure it out”.

So really we need both Agile and DevOps; except that some of Agile is - honestly - somewhat cockeyed. Extremists took over the Agile movement early on: witness, the first book about what became “Agile” was Extreme Programming Explained, by Kent Beck. Note the word “extreme”, and it is--I think--no coincidence that ideas with extremes had cachet in those days, which also saw the birth of “extreme sports”.

But while extreme sports might be fun, if you do not get injured, in software development extremes usually don’t work--not unless your situation is an extreme one. The Agile Manifesto, written two years after Beck’s seminal book, was intentionally not extreme: it expressed a set of values and principles that one could interpret thoughtfully and apply in a rational and contextual way.

So much for that: What then happened is that people tried to monetize Agile, and created methodologies and certification programs to make money, and blogs and books to become famous (I wrote one), and there is no better way to get attention than by going to an extreme. Pretty soon we saw people advocating things like “mobbing” in which a whole team codes together, and Agilists claiming that one should not look ahead any farther than the current two-week iteration.

Well, those ideas can work sometimes, but they usually don’t. They have their place, but that place is not everywhere, for every team, all the time.

So Agile needs to be revisited. But I don’t think we should chuck it. Instead, we should view the pool of Agile ideas as just that--a set of ideas. Consider each one, along with other ideas, such as those provided by people like Peter Drucker, W E Deming, Eliyahu Goldratt, Kelly Johnson, Susan Cain, Cal Newport, Daniel Pink, behaviorists such as Prochaska and DiClemente, and countless others, as well as the methods of some of today’s successful tech entrepreneurs such as Elon Musk and Jeff Bezos--the latter who famously rejects some of today’s popular methods yet is highly successful in his endeavors.

We need to think for ourselves. Never adopt a methodology. Never put a label on what you are doing. Everything is contextual. But we still need ideas, to enable us to think through our situation and decide what to do.