Key Points
Early in my career as an Agile Test Engineer, I worked on a project where the client was transitioning from Waterfall to Agile development. Many of my colleagues were still used to the old way of working, where requirements were defined once, testing didn’t take place until later in the process, and concerns ended up in a document rather than being discussed.
I opened a ticket to test things out and immediately went to the developer to clarify a few things that didn’t make sense to me—or maybe I was just too new to fully understand the ticket. I got an answer and moved on. A little later, I came back with a follow-up question.
What happened next surprised me. The developer raised her voice, clearly frustrated that I was asking another question. To me, this felt like a normal, logical way of working: if something isn’t clear, you ask about it. I thought I must have done something wrong and brought it up with my Test Manager.
My Test Manager, who did have Agile experience, reassured me: I had handled the situation exactly right, and my questions were justified. It was a relief to know that the situation was understood and that steps would be taken to prevent it from escalating further.
It took me years to truly understand what had happened. Good communication skills help, but that wasn’t the root of the problem here. The root of the problem was change.
My colleague was used to being assigned a task, completing it within the agreed-upon time, and being left alone, without having to explain her reasoning or answer questions on a daily basis. In her experience, there was little reason to “discuss a task out loud.” Everything was on paper and was considered self-explanatory. Testing took place later in the process, and any objections were again documented in writing, not discussed in a live conversation.
Agile testing is intentionally different: questions come up early, often, and openly—sometimes daily—because that’s how the team stays aligned.
The transition to Agile is often described as a process change, but the biggest shift is a personal one. Agile development means stepping outside your comfort zone:
None of this is a personal attack. It’s simply what Agile transparency looks like in practice, and it requires adjustment on both sides: testers learning when and how to ask questions, and developers learning that questions aren’t criticism.
A few practical lessons from this experience, for anyone who tests or leads an Agile team:
Why do developers sometimes react strongly to questions from testers in Agile teams? Most of the time, it’s not about the question itself, but about the shift from Waterfall’s “define once, explain later” approach to Agile’s expectation of continuous, real-time communication. Developers who are new to Agile may perceive repeated questions as micromanagement rather than collaboration.
What is the biggest difference in communication between Waterfall and Agile? In the Waterfall model, requirements and concerns are typically documented and discussed at fixed milestones. In Agile, communication is continuous; questions, clarifications, and challenges arise throughout the entire sprint—often on a daily basis—and are addressed openly.
How can teams make the transition from Waterfall to Agile easier? By explicitly acknowledging this shift—recognizing that daily visibility and frequent questions are part of Agile and are not a criticism of an individual—providing support to a Test Manager or Scrum Master in the moment, rather than only after an issue has been escalated, makes a measurable difference.
Darko is an Agile Test Engineer at M2Q, where he works on test strategies within Agile development teams.
