What is “Agile” all about? Really?

This is actually post that I did over at forum.agilesoftwaredevelopment.org in a tread with the above name. Finally I was prompted to articulate some of my thinking around this “popular” issue.

Ursprugligen inlagt av RonJeffries

Originally posted by red2
Wouldn’t you also say that Agile was a framework for enabling intuition to be quantified within an environment which prefers more empirical measurements? After all Agile would seem to be about divesting control from procedure to people.

I would certainly agree that agile is about moving the center of control away from procedure and toward people working together.

I would also say that partof what Agile does is enable “intuition” to be applied.

However, I’d want to be careful with the term “intuition”. It’s a weak, and perhaps dismissive term when we use it to describe the combined experience of a group of people, brought to bear on some problem, when they are freed from their cubes and are enabled to work together.

Who am I to disagree with one of the original signatories 😉 but I am not sure that I agree that the “agile is about moving control away from procedure”. I think is actually an effect of the fact that most procedures used currently does not make it easy to become “agile” enough.

What I mean is that since most current procedures are stipulatory, rigid and founded in other values than the “true agile values” (which I’ll come to in a second), they will not be possible to follow to achieve true agility. But there is no inherent conflict in procedure and agility, just look at XP. It is full of procedures, but achieves high degree of agility. Daily stand-ups is certainly procedure!

Agile is not about techniques either. Techniques are, as procedures, just a tool to get to the result, so we must look beyond both to find the “true agile values”.

*I* belive that the true values of agile is what it delivers to the stakeholders of the activities. E.g. delivering software that is usable for purpose, delivering business values or whatever the primary stakeholders require.

The techniques, and tools and procedures, that we apply are only secondary. However, there are some techniques, tools and procedures that we agile people think *must* be applied to deliver on that stakeholder interest, which are different than what we previously have thought, and been taught. Namely, an intense closed feedback loop! To optimize this feedback loop we find that it does not work to do big design upfront, waterfall projects, etc. etc.

Instead, to tighten this loop, we communicate directly with customers and users, develop a single feature at a time, get concrete feedback, and so on. The more we can tighten this loop the more efficient we are able to deliver the best result possible to our stakeholders.

Agile is not about a fuzzy feeling of people getting together. It is based on hard, cold evidence that tight feedback loops are the best way to deliver in this world of constant changing requirements, “I know it when I see it!”, and developing features no one can imagine the full impact of. One of the most important factor in tightening this loop is to get people to talk to each other, but that is not an agile value. It is a necessity to deliver on the true agile value: best possible working software/system/product with the given resources!

Would agile have developed if Waterfall would have worked? I would say no. Agile has evolved because previous thinking did not perform to our satisfaction!