Hacker News Reader

Comment by snarf21 | Hacker News Reader

Exactly, here are the principles of agile:

  -- Value individuals and interactions over processes and tools
  -- Value working software over comprehensive documentation
  -- Value customer collaboration over contract negotiation
  -- Value responding to change over following a plan

That doesn't sound like "agile" anywhere I've seen it implemented. The issue is that you need real buy-in from all levels of the company for any process. I've always said that a "bad" process executed consistency and with real buy-in will outperform any "good" process with only lip service commitment.

View on HN

You know the problem with those principles? They are not a methodology.

Most of the problem described in the article -and everywhere- is precisely that "the theory is good but everybody is doing it wrong".

But that doesn't really help, because it overlooks the fact that the origin of all this is just a pile of generic, hard-to-argue small-time guru ruminations. I mean, it is not necessarily bad advice: "These are valuable things and we think that in particular these ones are more valuable than those other ones". Okay. Probably. They do look good. Let's say they are. Now what? Oh, that's left as an exercise to the reader.

It's funny. Just yesterday I almost had an argument over one of these things. I heard Karen say to the guy on my left that "Agile means less documentation", so I raised my eyebrow. "Agile means less defined documentation, more open, because documentation has no value at all" - she added. I was about to point out that that is not at all what it means, but then she went further and told him that what he needed to do was to "work as a team and become more involved in collaboration". That, right there, is the problem: pretending a bunch of cool sounding expressions can be a substitute for actual things like writing down what they wanted the guy to do.

It seems like the problem might be that people assume agile software development is, in and of itself, supposed to be a methodology. As I understand it, agile software development is meant to be a set of principles describing any methodology that serves those principles. As such, Extreme Programming is an agile methodology, intended to serve those principles when employed well, and Scrum is a pseudo-agile methodology that serves as the halfway point to which one might be able to drag management, but more often ends up being an excuse to measure developer productivity in story points.

There's value in enumerating important principles for consistently pursuing quality work product. That's why the Agile Manifesto has value. The manifesto is just a manifesto, a statement of intent and principle, and not a methodology in and of itself. One doesn't need a published, monetized methodology to engage in agile software development. One simply needs a methodology -- whether unique to one's project, or widely known -- that reinforces those principles to engage in agile software development.

The biggest problem with agile software development as a concept is that it, like any other elaboration of any principles of quality work, is that most people will fail to see the forest for the trees, will marry themselves to some well-marketed thing that pretends to be about principles, and will end up largely doing the same dumb crap they've always done.

The documentation one is the one that completely throws me for a loop, and why I will never be on-board with anything claiming to be Agile. You know what? sometimes the documentation is more important than the working code. We're not all building crappy web properties as an agency, sometimes we are building stuff that is supposed to last longer than any one developer's career.

Sometimes just documenting what the thing is supposed to do and why would solve so many issues, but since people have gotten hooked on capital-A Agile so much has gone by the wayside, or been delegated to non-technical roles.

I agree. Over time, I've come, in my cynical moments, to see the agile manifesto as reading:

-value trust over plotting and scheming

-value open communication over hoarding information and deception

-value disarmament over preparing for battle

While we value the things on the left, we value not getting steamrolled by people who practice the things on the right even more.

> You know the problem with those principles? They are not a methodology.

No, that's not the problem with the five values and twelve principles.

In fact, the problem is the desire to have a single, divinely ordained methodology (which both the first value and twelfth principle reject, and that rejection is arguably the central basis of Agile.)

OTOH, while it is good that the Manifesto and Principles don't ordain a methodology a it's bad that they are written in a way which makes it harder to extract actionable direction than is necessary.

The only place I've worked where Agile was like this was, surprisingly, one of New Zealand's major banks. The buy-in for Agile started at the executive level, and they made a call that everything was Agile. Obviously, this would've been an absolute mess for most teams. But my team functioned perfectly. The woman who was our scrum master was originally a project manager in the bank. But with the Agile reshuffle she went over-the-top with her retraining. This was horrible in some areas, where she would follow processes to a T, but she would catch herself, and recognise the importance of those principles. She grew into the role well, and the team was eventually working great!

> -- Value individuals and interactions over processes and tools

And we're going to do agile! It will be great! How are we going to do so? According to this rigidly-defined process, that's how.

Reply on news.ycombinator.com