The test manager shakes hands with the development manager. He is delighted because they have found the solution to all the development and testing problems that plague their company. What they heard at the presentation today sounds enticing: agile development processes. In a moment, it's also a done deal. Starting Monday, they'll change the approach and swear developers and testers in to the new march. No more nagging that testers wait too long for software and then have too little time to test. After all, they are now testing on an ongoing basis. No more whining that software is handed over to testing so immaturely. The developers will practice Pair Programming and Test-Driven-Development from now on. No more arguments about bugs, they will now be discussed collegially in the team every day. And maybe this will bring back the "flow" of the earlier 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 view change skeptically at first. And the change to an agile process model is a big change - especially if there was none before. In the agile approach, e.g. in Scrum, there are "process components" that are sometimes stricter than in classic models: e.g. timeboxing or the definition of done.
In addition, the agile approach is based much more on a characteristic that could hardly be more individual: The mindset of the individual employees. And that can't be flipped 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 no 200-page specification awaits him that he can use to create test cases.
In order for the change to be successful, the individual testers and developers must be addressed in order to enable them to have an "aha moment" and to recognize the benefits and advantages of agile methods. In my projects, I have always had employees who resisted at first, but then became the driving force behind the methodology due to their "aha" moment. But that's where the employee has to be led, sometimes even gently nudged - and that costs 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 consists of individuals, everyone has different skills. If not yet known, these must be explored and the employee deployed accordingly. Even mavericks can be integrated into the team or at least docked. Trying to force them frantically into the procedure only creates frustration on both sides.
- Working together: Even small children are happy when they create something themselves, without the help of their parents. And agile procedures in particular thrive on the fact that the "process" can be continuously adapted to the needs by the team. In each retrospective, adjustments can be made. 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.
- Allow time and let benefits be seen: The changeover takes time and does not work overnight. This time must be made available despite day-to-day business, otherwise it won't work. Developers need time to get to grips with perhaps new topics such as TDD, testers need time to familiarize themselves with test automation frameworks and select suitable test methodologies. With the occupation with the individual topics and best practices comes the realization of the benefits and the employees in the team become believers.
- Error culture: Creating an agile approach must also allow for errors. Both in the process and in the content. Through the review meetings and retrospectives, corrections can always be made, errors will not easily take root. All the more you have to allow them.
- Fun: One of the most essential factors for success. If a team member enjoys the tasks, he or she will engage accordingly. My highlight: A software developer said to me after a planning meeting: "The meeting (!) was really fun today".
I'm sure there are numerous 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" piece by piece. A "flow" emerges from the team that crowns each iteration with an exciting review meeting. Then meetings become really fun again for me, too.