Over a million developers have joined DZone.

Agile Winter Is Coming

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

How do I know?  Well, it seems people try agile, and it doesn't work for them. You can take a couple of examples from Ben Linders' post on InfoQ: "The Flexibility of Agile: Flaw or Strength?"

The first example explains that agile doesn't differentiate between large and small tasks, just by importance. This is completely wrong, of course. That’s not agile’s responsibility, it's the product owner's job to evaluate cost and value, and then decide.

Other misconceptions are that agile is an excuse to neglect proper design / planning / documentation / estimation / etc. This is, of course, false as well. Read the values of the Agile Manifesto, or go even deeper into XP and you'll see that's not true. We, “real” agile people, simply value other stuff more.

Agile is contextual, and matches an environment with many unknowns. If everything is known, a good planning ahead with a good change management process will probably work better. Of course, nothing is ever known completely, so traditional processes won't work.

This is my formal response, anyway.

But if agile is really contextual, how can I (or anyone else) say that it cannot be used as an excuse for bad design? In some situations, I actually saw that happening.

Everybody has an opinion

The main issue here is not the disillusionment with agile. People try it, in different flavors, and succeed or fail to a certain extent. That's not only acceptable, it's expected: I see agile as a process of learning, and on the way you'll have both.

The real failing of agile is what has failed countless methodologies before it. It grew, reshaped by interesting parties, and is now perceived as a dogmatic religion (actually a few of them). For a dogma, it's a binary choice: It's either the "It works" or "It fails" camp. (It wasn't always like that, by the way. Read the original manifesto and it’s language.)

Since a methodology can't work all the time, it can't be a silver bullet. Unfortunately, many people believe that's what agile is. And now, with their actual bad experience, they are taking shots at it.

And these failures are only half the story.

On the other side of the battlefield there people who know exactly what the failed practitioners have done wrong. "You misread the manifesto". "You should go back and understand what the Product Owner really does". "You misunderstood what estimation is".

And like any good religious war, everyone loses, including the original idea, that wasn't half bad.

The Good News

Not today. I warned about it a few years back.  It’s a bad situation, and we’ve got ourselves to blame.

All I can ask of you is what I ask of myself: Keep experimenting until you find what works for you. Then, don't waste your time explaining "the right way" will work for everyone else.

Eliminate waste. That’s a good thing, right?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}