Why Agile works?

Here are some notes that I made from a Martin Fowler presentation on why Agile works (http://www.universite-du-si.com/fr/conferences/6/sessions/909):

• First, when do traditional methodologies, like waterfall, work?
  They work when you have stable, complete and clear requirements (which is almost never). The reason for needing stable and clear requirements is that the waterfall methodology is based on predictive planning: you predict the course of the project and you plan accordingly.
• What do you do when you have requirements that are not clear, incomplete and are not stable?
  The above statement describes probably 90% of all software development projects (and it describes 100% of all projects that I have worked on). Agile methodologies are perfect for such circumstances. The reason for this is that it is based on adaptive planning: You iterate many times over the cycle of planning, implementing, observing measuring, adapting, thus making it easier to change the path of your project as the requirements change or new ones come in while old ones get taken out.
• Traditional methodologies are process centric.
• Agile methodologies are people centric. It works only when you have a really good team that work well together. It is communications heavy.
• In an Agile methodology, everyone involved in a project understands and contributes to the project plan. (Its not just maintained and understood by the project manager).
• Agile methodologies rely heavily on feedback. At the end of every iteration, you perform a retrospective of what you did well and what you didn’t and you adapt your process to make the next iteration better. Being able to track and measure work being done during an iteration is extremely important, because this information is what is used during the retrospective. (The retrospective is a unique part to the agile methodology and one of the reasons for why it works).
  Ken Beck’s statement is extremely pertinent to this aspect of Agile: ”Perfect, is a verb and not an adjective”. (Its not something we are trying to achieve, but something we are constantly doing).
• Agile measures success by measuring the amount of software that is in a “production ready” state.

“Unit tests can prove the presence of a defect, but cannot prove the absence of defects” – Dijkstra.

“A bad process will beat a good person everytime”. – Edward Demings.

If your process is the same as one year before, then you are not using an Agile methodology – Martin Fowler.

Software development is unique as a profession, because it is a combination of engineering as well as creativity.

Cubicles make you dumber. – Neal Ford.

The Agile Manifesto:

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

Interesting comments in the video about Pair Programming: (36 minutes into the video)
The person working on the computer is the driver, the person working with the driver is the navigator.
Typically, the driver is thinking of the HOW, whereas the navigator is thinking of the WHY. (Each is using a different half of the brain). (left side is more logic oriented, the right side is more romantically oriented)
Its not about using 2 developers to get the work done, but getting one full brain to get the work done right.