The test manager shakes the development manager’s hand. He is delighted because they have found the solution to all the development and testing problems that are plaguing their company. What they heard today at the presentation sounds tempting: agile development processes. It’s about to be a done deal. From Monday, they will change their approach and commit developers and testers to the new direction. No more nagging that testers wait too long for software and then have too little time to test it. After all, they are now constantly testing. No more whining that the software is handed over to the tester so immaturely. The developers will be practicing pair programming and test-driven development from now on. No more arguments about errors, they will now be discussed collegially in the team every day. And perhaps this will also bring back the “flow” of the old days - when everything seemed much more efficient and effective without a process. And the advantages of the many practices and methods are so obvious that everyone in the team has to go along with them.
…but they won’t - because even testers and developers are only human. Most people are skeptical about change at first. And switching to an agile process model is a big change - especially if there wasn’t one before. There are “process components” in the agile approach, e.g. in Scrum, some of which are stricter than in classic models: e.g. timeboxing or the definition of done.
In addition, an agile approach is based much more on a characteristic that could hardly be more individual: The mindset of the individual employees. And this cannot be changed overnight like a switch. A tester who has insisted for years that the requirements - his test basis - must be clear, consistent, comprehensive and known in advance may feel lost in an agile project if he does not have a 200-page specification that he can use to create test cases.
In order for the change to succeed, the individual testers and developers must be addressed in order to give them the “aha moment” to recognize the benefits and advantages of agile methods. In my projects, I have always had employees who were initially reluctant but then became the driving force behind the methodology thanks to their “aha” moment. But the employee has to be led there, sometimes gently nudged - and that takes energy and time. (A nice task for the test manager, by the way, should he feel obsolete in the agile team - because he knows his testers).
A few thoughts/ideas that have been successful for me in projects:
- No egalitarianism: The team is made up of individuals, everyone has different skills. If these are not yet known, they must be researched and the employee deployed accordingly. Even mavericks can be integrated into the team or at least docked on. Trying to force them into the process will only cause frustration on both sides.
- Working together: Even small children are happy when they can do something themselves, without help from their parents. And an agile approach in particular thrives on the fact that the “process” can be continuously adapted to requirements by the team. Adjustments can be made in every retrospective. The testers can decide for themselves which test methodologies to continue using and which not. They can select an automation framework together as a team. This self-responsibility contributes to greater identification and more enjoyment of the tasks. Much more than specifications in a company-wide test manual.
- Take your time and recognize the benefits: The changeover takes time and does not work overnight. This time must be made available despite day-to-day business, otherwise it will not work. Developers need time to get to grips with possibly new topics such as TDD, testers need time to familiarize themselves with test automation frameworks and select suitable test methodologies. By dealing with the individual topics and best practices, the benefits are recognized and the team members become convinced.
- Error culture: Creating an agile approach must also allow for errors. Both in terms of process and content. Corrections can always be made through review meetings and retrospectives, and mistakes will not easily become ingrained. All the more reason to allow them.
- Fun: One of the most important factors for success. If a team member enjoys the tasks, they will also commit themselves accordingly. My highlight: A software developer said to me after a planning meeting: “The meeting (!) was really fun today”.
I’m sure there are many other levers - I look forward to hearing yours!
For me, the best moments in projects are when the teams and the many methodologies and best practices of the agile world “click into place” piece by piece. A “flow” emerges from the team that crowns each iteration with an exciting review meeting. That makes meetings really fun for me again.
Frequently Asked Questions
Why does the transition to an agile approach more often fail because of people rather than the method itself?
Because agile work depends heavily on the mindset of individual employees, and that’s not something you can just flip a switch to change. Most people are skeptical of change at first, especially if there was no process model in place before. A tester who has insisted on clear, complete requirements for years initially feels lost without a 200-page specification as a test basis.
Is agile work less disciplined than traditional process models?
No. Agile models include process elements that are, in some cases, stricter than those in traditional models. In Scrum, these include timeboxing and the Definition of Done. Anyone who portrays agility as a return to the process-less work of the past creates false expectations within the team.
Does an agile team still need a test manager?
Yes, albeit with a shifted role. The test manager knows their testers and can guide each individual to that “aha” moment when the benefits of agile methods become apparent. It is precisely this guidance—and sometimes a gentle nudge—that takes energy and time and serves as a meaningful role for someone who might otherwise feel obsolete.
How do you deal with employees who resist the new way of working?
Not by forcing a one-size-fits-all approach. The team consists of individuals with different skills that must first be identified and then utilized appropriately. Even loners can be integrated—or at least brought on board. Trying to force them into the process creates nothing but frustration on both sides. In the projects described, initial skeptics later became the driving force behind the methodology.
Should testing methods and tools be centrally prescribed?
Better not. The team should decide for itself which testing methodologies to continue using and which automation framework to select. The process is fine-tuned in every retrospective. This sense of personal responsibility fosters significantly more buy-in and enjoyment of the tasks than directives from a company-wide testing manual.
How much time should be allocated for the transition to agile working methods?
More than what day-to-day operations can voluntarily spare. Developers need time to grapple with new topics like test-driven development, and testers need time to familiarize themselves with test automation frameworks and select appropriate methodologies. If this time isn’t allocated, the transition won’t succeed. Engaging with these topics leads to an understanding of their benefits.
What role does handling errors play in agile work?
An agile approach must allow for errors, both in the process and in the content. Review meetings and retrospectives ensure that errors do not become entrenched, because they can be corrected on an ongoing basis. This is precisely why we must allow them to happen, rather than immediately suppressing every deviation.
Is having fun as a team a serious factor for success?
Yes, it’s one of the most essential ones. People who enjoy their tasks are naturally more engaged. As evidence, the author describes a software developer who, after a planning meeting, said that he had actually really enjoyed that very meeting. As methods and practices fall into place piece by piece, a sense of flow emerges from within the team.
