Here's what I always believed was the original manifesto<p><a href="http://agilemanifesto.org" rel="nofollow">http://agilemanifesto.org</a><p>While I don't see any specific mention of stand up meetings or scrum masters, I can see how these things emerged from the initial concept. The idea, as I always understood it, was that the massive up-front design of the waterfall method would be replaced with a highly collaborative and iterative process that turns developers into members of a team rather than far away people who receive a spec flung over a wall. I found the approach very promising when I first read about it.<p>Unfortunately, at this point I have to agree that the term "agile" almost always refers to processes and tools, though they are inspired by the original manifesto. Problem is, those processes and tools are often applied in a way that longer accomplishes the original goal - and in many ways amounts to a "bait and switch" on developers who thought the process would be collaborative (and are the only ones who didn't realize one of the tools and processes of an agile project is "CYA").<p>Daily standups, for example, did seem like a good idea to me at the start, and handled right, they still could be. If you're going to do iterations and respond to change, and place less (or no) emphasis on a massive spec, it's a good idea to stay in constant communication.<p>But to me, "agile" turned out to be a mass scale bait and switch. Daily stand ups lost their value as a quick check in with everyone to see what issues have arisen. Deadlines still loom, daily stand ups involve project management software shown on a large overhead projector, and developers asked for status reports based on estimates made on fuzzy tasks with limited information (because the developer thought they were being "agile"). Daily stand ups often morph into a daily application of pressure about why deadlines aren't being met. There's a contract (the project plan), just one that wasn't properly negotiated.<p>To me, the clearest sign of the corruption of the agile manifesto is how "Customer collaboration over contract negotiation" happens. Many of us aren't specifically dealing with external clients and formal legally binding contracts, but if there is project management software with tasks, assignments, deadlines, and estimates, all with names (perhaps your name) attached, trust me, there is a "contract". You are a party to this contract. Litigation is replaced with status meetings with your manager and perhaps a disgruntled stakeholder who may very well hold a copy of the project plan (ie., contract). It's unpleasant, you don't want to be in this spot. If a contract is inevitable (again, presence of project management software with tasks, names, and deadlines = contract), you'd better negotiate it.<p>I still think that for many projects, the ideas behind "agile" really would to lead to better software. But a lot of supposedly "agile" projects are just waterfall projects involving a daily status report. If that's the case, honestly, I'd rather just do a waterfall project and be open to it. If someone is going to hold my feet to the fire about exactly what was done and when, I'm going to want them to specify exactly what needs to be done, and if things are unclear or I need more time to research, I'm going to want that <i>in the contract</i>.