The head of testing shakes hands with the head of development. He’s delighted, because together they’ve found the solution to every development and testing problem weighing on their company. What they heard in today’s talk sounds tempting: agile development processes. The decision is made on the spot. Starting Monday, they’ll change the way they work and rally developers and testers behind the new direction. Agile developers, agile testers. No more grumbling that testers wait too long for the software and then have too little time to test it. After all, they’ll be testing continuously now. No more moaning that the software arrives in test half-baked. From now on, the developers will practice pair programming and test-driven development. No more arguments about bugs, because they’ll be discussed amicably in the team every day. And maybe this will even bring back the “flow” of the old days, when everything seemed so much more efficient and effective without any process. And the advantages of all these practices and methods are so obvious that everyone on the team is bound to go along.
…except they won’t, because testers and developers are only human too. You can’t order the switch to agile testing. It works when testers and developers see the benefit for themselves, and for that they need time, individual support, a healthy error culture and fun.
Why Agile Testing by Decree Fails
Most people are skeptical of change at first. And moving to an agile process model is a big change, especially if there wasn’t a model before. Agile approaches such as Scrum contain “process elements” that are in some cases stricter than in traditional models, for example timeboxing or the Definition of Done.
You Can’t Flip a Switch on Mindset
On top of that, agile work rests much more on something that couldn’t be more individual: the mindset of each team member. And that can’t be switched over from one day to the next. A tester who has insisted for years that the requirements (the test basis) must be unambiguous, consistent, complete and known in advance may feel lost in an agile project when there’s no 200-page specification waiting to derive test cases from.
Meeting People Where They Are: A Job for the Test Manager
So for the switch to succeed, you have to engage much more with the individual testers and developers, so they can have that “aha” moment and see the benefits of agile methods for themselves. In my projects, I’ve repeatedly had people who resisted at first and then, after their aha moment, became the driving force behind the approach. But people have to be led there, sometimes with a gentle nudge, and that takes energy and time. (A fine job, by the way, for a test manager who feels obsolete in an agile team, because the test manager knows the testers.)
Five Levers That Help Testers Become Agile Testers
Here are a few thoughts and ideas that have worked for me in projects:
- No one-size-fits-all: The team is made up of individuals, and everyone has different skills. If you don’t know them yet, find them out and deploy each person accordingly. Even lone wolves can be integrated into the team, or at least brought on board. Trying to force them into the process only frustrates both sides.
- Working things out together: Even small children are happy when they manage something by themselves, without their parents’ help. And agile work in particular thrives on the team continuously adapting the “process” to its needs. Every retrospective is a chance to adjust. Testers can decide for themselves which test methods to keep using and which to drop. They can choose an automation framework together as a team. That sense of ownership leads to stronger identification and more enjoyment of the work, far more than rules in a company-wide test manual.
- Giving it time and letting people see the benefit: The transition takes time and doesn’t happen overnight. That time has to be made available despite day-to-day business, or it won’t work. Developers need time to get into topics that may be new to them, such as TDD. Testers need time to learn test automation frameworks and choose suitable test methods. As people work through the individual topics and best practices, they come to see the benefit, and the team members turn into true believers.
- Error culture: Building an agile way of working also means allowing mistakes, both in the process and in the content. Review meetings and retrospectives always offer a chance to correct course, so mistakes don’t take hold as easily. That’s all the more reason to allow them.
- Fun: One of the most important success factors. When team members enjoy their work, they commit to it accordingly. My highlight: after a planning meeting, a software developer said to me, “That meeting (!) was really fun today.”
There are certainly many other levers. I’d love to hear yours!
For me, the best moments in projects are when the teams and the many methods and best practices of the agile world “click into place” bit by bit. A flow emerges from within the team and crowns every iteration with an exciting review meeting. That’s when I start enjoying meetings again, too.
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.
