“So, ab heute testet ihr agil!” 

Der Testleiter schüttelt dem Entwicklungsleiter die Hand. Er ist entzückt, denn sie haben die Lösung für alle Probleme bei Entwicklung und Test, die ihr Unternehmen belasten, gefunden. Das, was sie heute bei dem Vortrag gehört haben, klingt verlockend: agile Entwicklungsprozesse. Gleich ist es auch beschlossene Sache. Ab Montag werden sie das Vorgehen ändern und Entwickler und Tester auf die neue Marschrichtung einschwören. Kein Gezeter mehr, dass Tester zu lange auf Software warten und dann zu wenig Zeit haben, zu testen. Sie testen ja jetzt laufend mit. Kein Gejammer mehr, dass die Software so unreif an den Test übergeben wird. Die Entwickler werden ja ab sofort Pair Programming und Test-Driven-Development praktizieren. Keine Streitereien über Fehler mehr, die werden jetzt jeden Tag kollegial im Team diskutiert. Und vielleicht kommt ja damit auch der „Flow“ der früheren Tage zurück – als alles ohne Prozess viel effizienter und effektiver schien. Und die Vorteile der vielen Praktiken und Methoden sind ja so einleuchtend, da muss ja jeder im Team mitziehen.

…werden sie aber nicht – weil auch Tester und Entwickler nur Menschen sind. Die meisten sehen Veränderung zuerst skeptisch. Und der Wechsel in ein agiles Vorgehensmodell ist eine große Veränderung – vor allem wenn es vorher keines gab. So gibt es im agilen Vorgehen, z.B. in Scrum, „Prozessbestandteile“, die zum Teil strenger als in klassischen Modellen sind: z.B. Timeboxing oder die Definition of Done.

Dazu kommt, dass agiles Vorgehen viel mehr auf eine Eigenschaft fußt, die individueller kaum sein könnte: Das Mindset der einzelnen Mitarbeiter. Und das lässt sich nicht von heute auf morgen wie ein Schalter umschalten. Ein Tester, der jahrelang darauf gepocht hat, dass die Anforderungen – seine Testbasis – eindeutig, konsistent, umfassend und im Voraus bekannt sein müssen, wird sich in einem agilen Projekt vielleicht verloren fühlen, wenn ihn keine 200seitige Spezifikation erwartet, die er zur Testfallerstellung nutzen kann.

Damit der Wechsel also gelingt, muss vielmehr auf die einzelnen Tester und Entwickler eingegangen werden, um ihnen das „Aha-Erlebnis“ zu ermöglichen, den Nutzen und die Vorteile in den agilen Methoden zu erkennen. Ich hatte in meinen Projekten immer wieder Mitarbeiter, die sich zuerst gesträubt haben, dann aber durch ihren Aha-Moment zu den Zugpferden der Methodik geworden sind. Doch da muss der Mitarbeiter hingeführt werden, manchmal auch sanft gestubst – und das kostet Energie und Zeit. (Eine schöne Aufgabe übrigens für den Testmanager, sollte der sich im agilen Team obsolet fühlen – denn er kennt seine Tester).

Ein paar Gedanken/Ideen, die für mich in Projekten erfolgreich waren:

• Keine Gleichmacherei: Das Team besteht aus Individuen, jeder hat andere Fähigkeiten. Wenn noch nicht bekannt, müssen diese erforscht werden und der Mitarbeiter dementsprechend eingesetzt werden. Auch Eigenbrötler können in das Team integriert oder zumindest angedockt werden. Zu versuchen, sie krampfhaft in das Vorgehen zu zwängen, erzeugt auf beiden Seiten nur Frust.
• Gemeinsames Erarbeiten: Schon kleine Kinder freuen sich, wenn sie etwas selbst schaffen, ohne Hilfe der Eltern. Und gerade agiles Vorgehen lebt davon, dass der „Prozess“ durch das Team laufend an die Bedürfnisse angepasst werden kann. In jeder Retrospektive lässt sich nachjustieren. Die Tester können selbst entscheiden, welche Testmethodiken weiterverwendet werden und welche nicht. Sie können im Team gemeinsam ein Automatisierungsframework auswählen. Diese Selbstverantwortung trägt zu einer größeren Identifikation und mehr Freude an den Aufgaben bei. Viel mehr als Vorgaben in einem unternehmensweiten Testhandbuch.
• Zeit lassen und Nutzen erkennen lassen: Die Umstellung benötigt Zeit und funktioniert nicht von heute auf morgen. Diese Zeit muss trotz Tagesgeschäft zur Verfügung gestellt werden, sonst klappt es nicht. Entwickler benötigen Zeit, um sich mit vielleicht neuen Themen wie TDD auseinander zu setzen, Tester benötigen Zeit, um sich in Testautomatisierungsframeworks einzuarbeiten und passende Testmethodiken auszuwählen. Mit der Beschäftigung mit den einzelnen Themen und Best Practices kommt auch die Erkenntnis über den Nutzen und aus den Mitarbeitern im Team werden Überzeugungstäter.
• Fehlerkultur: Ein agiles Vorgehen zu schaffen muss auch Fehler zulassen. Sowohl beim Prozess als auch beim Inhalt. Durch die Review-Meetings und Retrospektiven kann immer korrigiert werden, Fehler werden sich nicht so leicht festsetzen. Umso mehr muss man sie zulassen.
• Spaß: Einer der wesentlichsten Faktoren für den Erfolg. Wenn ein Teammitglied Spaß an den Aufgaben hat, wird es sich auch dementsprechend engagieren. Mein Highlight: Ein Software-Entwickler sagte nach einem Planning-Meeting zu mir: „Das Meeting (!) hat heute richtig Spaß gemacht“.

Sicher gibt es noch zahlreiche andere Hebel – ich freue mich, Ihre zu hören!

Für mich sind bei Projekten die schönsten Momente, wenn die Teams und die vielen Methodiken und Best Practices der agilen Welt Stück-für-Stück „einrasten“. Da entsteht aus dem Team heraus ein „Flow“, der jede Iteration mit einem spannenden Review Meeting krönt. Dann machen auch mir Meetings wieder richtig Spaß.