BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Do Agile Practices Make it an Agile Project?

Do Agile Practices Make it an Agile Project?

Bookmarks

Use of Agile methodologies is growing, with recent surveys showing that approaches like XP, Scrum and FDD are being adopted more widely than ever.  There's a down side, however: Agile also risks what one practitioner calls "dying the death of a thousand copies," if teams copy practices rather than growing them, implementing what worked elsewhere without understanding how to use continuous improvement to make the process suitable for their own unique context.

Unfortunately, this "bad Agile" may be a natural side effect of increased popularity, and some will form their opinion of Agile software development based on these pale examples.  For example, in a recent essay called Egomania Itself (a clever anagram of "Agile Manifesto"), Steve Yegge picks up where he left off last month, complaining about Agile.  He uses the term "The Church of Agile" and likens Agile practice to superstition:

 

... there are probably some people who practice witchcraft to help their projects out, and a great many of those projects — probably the majority — wind up being successful.

If you do a rain dance for enough days in a row, it will eventually work. Guaranteed.

So I'm not saying Agile doesn't work. It does work! But it's plain, unadulterated superstition.

Certainly, Agile could be, and sometimes is, implemented in that way. However, this "faith-based" application of Agile practices - we believe this will work, we don't need to know why - ignores one of the most powerful tools used by Agile software development: reality.  Agile "embraces change" by applying empirical process.  Jim Highsmith, in Agile Project Management, describes it this way: "Agile projects are exploration projects, and as such, success depends upon reality-based feedback."  Agile's short  plan-do-inspect-adapt cycles are intended to increase understanding and so ensure that ineffective process not be repeated ad infinitum.  In fact, this inspect-and-adapt cycle could reveal to a team, under certain circumstances, that Agile is not what they need to use at all.

As Yegge asserts, even this form of Agile can work - but along the way there are stories of groups ordered to implement practices they don't need or want, teams hogtied with fixed date and scope and budget, and managers who strip developers of hard-won office space simply to get more done for less.  In these cases, even if they do produce working software, they are also producing angry and demoralized developers - and sometimes they're burning them out, too.  It's hard to reconcile this with the Agile Manifesto's first value of "people over process."

An interesting theme appeared in the conversation thread that followed on Yegge's blog page, talking about what makes the Agile practices work.  Here are a few snippets from that 10,000-word conversation - unfortunately, few commenters reveal who they are, so we're left to guess at who's saying what.

Geoff, aka "gilligan" warned Yegge against faulty syllogisms, and further wrote:

There is a type of person that I call an Agilista. Agilistas are nothing more than opportunists that have jumped on the Agile bandwagon and they shout "come down to the river and be healed". These Agilistas don't understand development, they don't know why Beck, Cockburn, Jeffries, Fowler, or whom ever suggest specific practices. These Agilistas don't even know what the real problems are! ...

When I first heard of XP I did some quick study of it and I started a paper. The title was "XP eXposed". I wanted the paper to be sound so I was doing my homework. As I experimented with XP I soon found that it wasn't as stupid as I first thought. Eventually I found that there were many good things to learn (for the novice) and to be reminded of (for the seasoned). I never finished the paper. Why? Because I found it better to focus on the good than to focus on the negative.

to which jiblet replied (in part):

These [agile and other] methodologies are the result of skilled developers refining their own process... The problem is: mediocre programmers won't get anything out of the methodology if they don't understand why. Otherwise it's just blind obedience without reason...

Cory Foy appealed to this same "return to the roots" approach, an idea he also talked about on his recent blog entry Principles, Not Processes:

It's a shame that what you've seen of XP has given you the impression it has. No matter how completely amusing your blog posts are.

Because, in my world of XP, one of the most important things for the teams to remember is that it is their process, not anyone else's, and it is their responsibility for ensuring that they understand the principles behind the practices so they can tweak them to fit their needs.

Agile teams ideally need to learn Agile Practices and Agile Values together, to make their process their own and to really excel.  The Agile Manifesto consists of four values supplemented by twelve principles. These are not suggestions: they define Agile software development, just as the Java api defines the behaviours of application servers that implement it.  The methodologies are simply different implementations, interpretations, so one would expect them to evolve and improve over time.

The four Agile Values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan 1

Perhaps it's time to talk more about how failure to teach and practice these basics can lead to the the destruction of the most important assets a team has: the integrity, creativity and engagement of its members, and the trust of its customers.  It doesn't matter how many of the core practices a team uses - if their voices are stifled or ignored and their ability to produce real value is systematically obstructed, real agility probably isn't in the cards.

1 The Agile Values form a portion of the complete Agile Manifesto, where its authors place these values in context.  It's a very brief document: if you've never taken the time to read it, please follow the link and have a look.

About the author

Deborah Hartmann is an Agile practitioner living in Toronto and working in Canada and the US.  She's been the Agile Community Editor for InfoQ.com since April 2006.

Rate this Article

Adoption
Style

BT