respond to changing business needs and technical challenges
reduce handoffs and keep it simple
Quality & Predictability:
real-time and iterative engagement between business, tech experts, QA, engineers, etc.
decisions “live” as closely as possible to the owners of results, and all members are equal
more value delivered faster
You’ll enjoy reading this article about how the Manifesto came to be in 2001. No divine intervention, flashes of light or puffs of smoke, but a bunch of smart and competitive men wrestling with a better way to deliver software. Like all templates or processes, working with Agile means adapting to the people and requirements of the team you are part of, not following a giant pile of rules. This last bit has had some challenges.
People like to make Agile not agile for multiple reasons. If you can convince others that you are the only one who really knows what agile is, your ego is thrilled. Someone told me recently that the Manifesto doesn’t matter anymore – the key points don’t have bearing. Another defined Agile by the toolset (software). Clearly Agile is done differently because people and needs are different. It isn’t perfect because people aren’t.
Agile seeks to drive faster and higher quality solutions that customers need. The slicing of the work is different, the roles are somewhat different, but the purpose is to build stuff for your customer. I wonder what the process will be in another 10 years?