[geebee]

This article really addresses the need for agile development to be a two way street [1]. I loved the manifesto when I first read it, and I still do. But I've noticed it really goes wrong when both sides don't adhere to the principle - when one side tries to be "agile" and the other side lawyers up, the agile side will get railroaded if (and probably when) the relationship turns sour.

"Individuals and interactions over processes and tools" means "we come by your office to interact with you as an individual about why your story points haven't velocitized properly in the time tracking system" [2]

In a similar vein, "Customer collaboration over contract negotiation" becomes "we'll hold your feet to the fire about deadlines and estimates, but we reserve the right to change our minds at any point."

In this sense, agile becomes unilateral disarmament in the face of a heavily armed… neighbor. I wouldn't say "foe", yet, but good relationships can turn bad. It's like one side saying "let's do this with trust and work together", but they're the only ones with a lawyer at the table.

In some ways, the agile manifesto almost says "peace and cooperation over fighting and coercion". Yeah! I'm for it. But we both need to do this!

[1] I feel a little embarrassed using the word "agile", but I figure that as long as it's an adjective, I preserve some dignity. [2] I'm not technically a certified scrum master, so I may have some of that slightly wrong.

[AnimalMuppet]

Let's step away from the contracting scenario for a minute. Let's say it's purely in-house, and the team is committed to agile. That's great... until you run into a layer of management that doesn't understand agile. They still want the old waterfall-style progress reports, and they still make decisions based on them - decisions that can kill your project. This can force you to suddenly be less agile, or to present an interface to those outside your team as if you were not agile.

Back to contracting. If you're a contractor, even if the team you're working with is fully on board with being agile, you can still get burned by higher layers of their organization.

[thirdtruck]

Seconded. This is just the kind of framing I use when trying to explain why, at our workplace, our "Agile" (or even our "Scrum") process seems so ineffective.

My favorite metaphor: asking for hard numbers from an Agile team makes as much sense as asking Columbus exactly how long it would take to reach India. Software development often resembles cartography work even more so than architecture work.

[mgkimsal]

In projects I've seen (both inside and from the outside), one side usually wants to use the term "agile" as a synonym for "we don't write anything down", nothing more.

[pekk]

Thank you. This is a large part of where the much-derided "waterfall" comes from.