I think it’s important to define “Agile” when I talk about “Agile Testing.”
Agile is one of those capitalized umbrella terms, like Quality, that means many things to many people. And given that Agile Testing involves testing in an Agile context, it’s hard to talk about it if we have not established a shared understanding of the term “Agile.”
I define Agile in terms of results. Specifically, Agile teams:
- Deliver a continuous stream of potentially shippable product increments
- At a sustainable pace
- While adapting to the changing needs and priorities of their organization
(Tip ‘o the hat due to various sources that inspired my definition, including the APLN’s Declaration of Interdependence for the phrase “continuous flow of value”, Scrum for the phrase “potentially shippable product increment”, XP for the core practice of “Sustainable Pace”, and Jim Highsmith plus too many other people/sources to mention for the idea of adapting to changing needs.)
Teams that are consistently able to achieve those results typically exhibit the following characteristics:
- A high degree of Communication and Collaboration.
- Seeking and receiving fast Feedback.
- Seeking mechanisms to support Visibility so everyone knows what’s going on at any given time.
- A high degree of Alignment so everyone is working toward the same goals.
- A shared Definition of Done that includes Implemented, Tested, and Explored before being Accepted by the Product Owner.
- A relentless Focus on Value.
And teams that manifest these characteristics typically have adopted a combination of Agile management and engineering practices including:
- Prioritized Backlog
- Short Iterations (or Sprints)
- Daily Stand-ups (or Scrums)
- Integrated/Cross-Functional Team
- Continuous Integration
- Collective Code Ownership
- Extensive Automated Tests
Too many people equate practices (e.g. Prioritized Backlog) and methods (e.g. Scrum) with Agile. But that’s backwards. Agile practices and methods increase the odds of achieving Agility, but they’re not a guarantee. The practices serve the desired outcome, not the other way around.