Agile software development has come a long way since the Manifesto for Agile Software Development was published in 2001. The original twelve principles still largely hold today:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Now 15 years later, everyone – and we (almost) literally (well, somewhat figuratively) everyone – has taken a wack at molding the essential clay of Agile into a new, branded philosophy often with a dictionary of unique and incompatible TLAs (Three Letter Acronyms) and other terms-of-art. A culmination of this evolutionary radiation can be found in the graphic accompanying this post (click here for a larger version).

So where does your organization fit in this completely easy-to-read, simple-to-understand roadmap of the modern Agile landscape? And where do you fit Quality Assurance into your Agile processes?