“So, from today you are testing agile!” 

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.