But that’s not agile.
David, the developer, is hammering code in a project with Carl the Coder. A Sprint of two weeks has been rolling at a fast pace and the final days took a lot of overtime. When the boys finish their work, the software gets sent to Tina the Tester. And quite often this is called Agile.
Too often firms say that they develop new software with agility. Despite that, getting a closer look at the core of their software development reveals the scenario above. Often what is going on is an incremental or iterative (IID) way of creating software.
Developers withdraw into their chambers to work on the epics, stories, and tasks for the spring. And once finished, they deliver the software for testing.
Suddenly, a work claimed to be Agile seems quite like a series of small waterfalls.
Incremental software development is not automatically Agile even though we might insist on using the term. Agile, on the other hand, might be incremental as well.
The main differences come from the nature of teamwork and the significance of fast feedback. Feedback is not fast if the team works in cycles of development after testing after development after testing.
In that scenario, the question is not about teamwork, but instead, the cooperation of two teams. Confusing, is it not?
So what then, makes testing agile?
I admit it’s a line in the sand. But to me, it’s not a single characteristic of the testing routine. It’s a direction where testing process evolves up the stream. Ever closer the development work on the timeline, closing the loop of feedback ever shorter.
I’d say that for testing to become agile; it needs to move from gatekeeping the production releases; towards testing the outcomes of every sprint; towards testing the epics, stories and finally tasks at the time of their development.
Your testing routine evolves too. So can you tell the direction?
