What’s Your Agile Value?

The Agile Manifesto was put together in 2001 by a group of agilists, as they later became known, on top of a mountain in Utah. I sometimes wonder if the high altitude had something to do with the outcome. At the resultant website, the following four “agile values” are emblazoned across the front page, in letters of fire 80ft …

[Anonymous Coward]

Must be a strange book

How can someone who claims to have written a book on the agile process have so completely missed the point?

Of course the four principles need explanation and expansion - 10 minutes on Google (or wikipedia) should begin to provide that. It's a pity the author didn't spend that time before writing this drivel, he may them have realised for example that agile teams can be self organising and not need a leader.

A really weak article that adds nothing the body of knowledge about agile from someone who seems to have a personal axe to grind (or should that be book to sell).

[Thomas Guest]

I disagree!

I'm not left hanging by the values in the Agile Manifesto; they ring true to me. Your re-wording is something very different. It doesn't standalone -- it's a comment on the original, and I think it misses the point.

You say: "For example (being tongue-in-cheek here), it wouldn’t matter as much if the team were to launch straight into coding without first eliciting some requirements from the customer. (This would, of course, be a recipe for disaster, quality staff or not)."

This doesn't sound like a recipe for disaster to me. Why shouldn't a team code up a proof of concept of a novel software product, then use this as a vehicle to elicit feedback?

You say: "To gain customer collaboration, you need to negotiate a contract first." I can collaborate with a customer without a contract in place.

[Rob D]

Missed the whole point!

Woah there! Aren’t you missing the whole point in your rant?! You’re trying to take the flexibility out of agile methodologies and re-define them to how it works in your world. The beauty of these values are that they can be applied appropriately on a per-team/organisation basis. Whatever allows a team to work well together, and to be focused on producing working software is a good thing. There are loads of implementations of out there, be it XP, MSF, TDD etc each with their pros and cons to be considered.

One of the key ‘agilists’ themselves, Barry Bohem makes this point in his IEEE paper “Get Ready for Agile Methods, with Care”. This explains that you can’t be dogmatic about agile methods – the correct implementation has to be decided depending on the team, the customer & nature of the project among other things.

Your alternative wording of the manifesto might work for you, but other project managers should implement this as they seem fit.

[amanfromMars]

Second best is never satisfactory in the lead.

Sorry, Matt, but the original four "agile values" are the ones which matter. To soften them as you have done [In Agile Development with ICONIX Process (which I co-authored with Doug Rosenberg and Mark Collins-Cope)]....... is to weaken their effectiveness but then I suppose the problem is a people problem and finding those with the necessary "Right Stuff".

If you want to get into the Virtualisation Field, the Metadata required needs to be RAW and Single Sourced so that Continuity can be Provided and Responsibility Rewarded.

As an aside, does anyone think that Virtualisation has been cracked for Universal Coding yet? And if it had, what do you think IT would be worth or would IT be so valuable as to be priceless? How then would the Programmer/Systems Architect be paid? Or would the Program target Microsoft to get them with the Program?

[Dan]

Extremely Ill Informed...

From agile to arthritic, Matt's take on the agile manifesto kills any sense of agility by willfully (surely?) missing the point, and misreading the manifesto in order to (try and) score points from 'corrections' of that misinterpretation, resulting in a confused, manacled approach to software development.

Every one above has made good points. All I have to add is that the qualifier “while there is value in the items on the right, we value the items on the left more” allows any project to make liberal use of any right-column methods. To misrepresent the agile manifesto as anti-process, anti-tools, anti-documentation, anti-contract and anti-plan Matt must have either made an error in his reading, or, as seems more likely, intentionally misinterpreted the manifesto in order to create problems which he can then 'fix' with his book.

Poor analysis, poor software methodology, poor article.

[Anonymous Coward]

agilists miss the point

What a lot of postmodern nonsense agilism is. You must reject all process except of course the agile process. You must use the core values or you are not agile. If you use the core values and fail, then you are not agile *enough*. This is precisely the same thinking as belief in magic. Cast the spell, just like in the book. If it doesn't work, then you didn't do it right, because it's magic and we already believe in magic. If it does work that proves magic works!

Agilists make straw man arguments about plan-driven methods that are impossibly rigid, then say "see, agile is better." Agilists blame the developer for failure, because it cannot be a weakness in the agile method. Agilists discourage questions about the efficacy of the agile method, and questions about the underlying assumptions of inability to plan effectively.

And here's a little secret just between you and me. Agile doesn't work unless you are doing just the right kind of development. Yeah a lot of agile's core methods work. They were invented by those bacdward, hoary old plan-driven folks, and put to good use when many agilists were in kindergarten. And yeah, agile isn't too bad a choice when you are replacing no-process-at-all, when your staff isn't well trained or experienced, when the project isn't too big, and when you don't face any deadlines. But practically any process at all will work under those very favorable conditions.

Not every software developer enjoys the mental effort of planning and scheduling. And virtually none like being held accountable to a plan or schedule. Agile is the feel-good solution to this problem. But is it the *best* solution?

Yeah, I know, optimizing and planning are part of the same school of philosophical thought, an old school that has been overthrown by glorious new paradigms of thought proclaimed by, amongst others, agilists. Maybe.

Here's a prediction; in 20 years we'll see software development that looks kinda agile, but with requirements capture as a separate step, supported by tools that aren't routinely used yet. Way more emphasis on different ways of testing, and on measuring and improving a process that takes account of differences between teams. Schedules will be back in fashion, but supported by newer notions of how to schedule. And there will be a proclaimation that this method is the *old* way of doing things, and there will be a *new* way supported by a new batch of young impatient consultants, eager to grow rich on your money.

[Anonymous Coward]

Unbelievers shall be smitten!

You are clearly an Unbeliever, who shall be smitten by the legions of True Believers!

(Meanwhile, I shall quietly agree with you.)

[Anonymous Coward]

agile consultants

"See, agilists suck, because we have something that's pretty similar but just better, because it's our flavor of agile and not theirs, and we emphasize these values just a little more than they emphasize those values." I'm probably as disturbed as Mr Stephens about many trends in the "agile" world, but at least I'm not as disingenuous as to create my own agile process with a few variants and then claim it's not agile.

"A flexible process and set of tools is easily as important a factor as the staff who monitor and tailor the process." This comment misses the original point of agile, and the agile manifesto that came out of it. Over the past 15 years, we were all sold this bill of goods that wonderful tools and wonderful processes would eliminate the need for anyone to even think. Just make some pretty pictures in some extremely expensive tools, and the software builds itself. We can partition staff into EJB Deployers, EJB Entity Bean Developers, EJB Ass Wipers, and so on, and each one could magically throw their product over the wall to the next.

"Of course we want working software!" You could have fooled me, Mr Stephens. I spent years in useless meetings, working on useless design documents (including useless diagrams, like Iconix's robustness analysis diagrams), including several efforts where we did everything *but* produce working software. It's not obvious.

Ultimately, most of us could care less about "agile," we just want to build good software. Others so more concerned with selling heavy process, books, and tools that they miss the point entirely.