Am I Agile or Mini Waterfall? Do I care?

After our development team migrated to agile, we assumed that we are an agile test team.  After some time and belly button staring, we came to the conclusion that we were a mini-waterfall test team and not very agile.

We tested and delivered code every four weeks, and we went to scrum meetings.  It looked agile, but our mini waterfall approach was very traditional.  Programmers and product owners designed and implemented the product enhancements, and testers stood against the wall waiting for code to test at the end of the sprint.  We were second-class members of the development team.

The move to agile testing started by dealing with the denial that we were not already there and by trying to articulate what exactly agile testing is.  While not everything changed (we still analyze and test software), we changed our testing philosophy.  We found ways to change our role from tester to “developer.”  We took steps to own the early days of a sprint be taking on more of a business analyst role.  We engaged the product owners earlier and more often, changing from software watchdog to advocate for functionality and usability.  And we actively sought ways to provide immediate feedback throughout the sprint, reducing the end-of-sprint rush.

So, should you care if you are mini waterfall or agile?  Agile testing gave us something that we lacked with mini waterfall, a way to become full share members of the development team.