“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ß.

Häufig gestellte Fragen

Warum scheitert der Umstieg auf ein agiles Vorgehen häufiger an den Menschen als an der Methode?

Weil agiles Arbeiten stark am Mindset der einzelnen Mitarbeiter hängt, und das lässt sich nicht wie ein Schalter umlegen. Die meisten sehen Veränderung zuerst skeptisch, besonders wenn es vorher gar kein Vorgehensmodell gab. Ein Tester, der jahrelang auf eindeutige, vollständige Anforderungen gepocht hat, fühlt sich ohne 200-seitige Spezifikation als Testbasis zunächst verloren.

Ist agiles Arbeiten weniger diszipliniert als klassische Vorgehensmodelle?

Nein. Agile Modelle enthalten Prozessbestandteile, die zum Teil strenger sind als in klassischen Modellen. In Scrum gehören dazu Timeboxing und die Definition of Done. Wer Agilität als Rückkehr zum prozesslosen Arbeiten der früheren Tage verkauft, weckt falsche Erwartungen im Team.

Braucht ein agiles Team noch einen Testmanager?

Ja, wenn auch mit verschobener Aufgabe. Der Testmanager kennt seine Tester und kann jeden Einzelnen zu dem Aha-Erlebnis führen, an dem der Nutzen der agilen Methoden sichtbar wird. Genau dieses Hinführen, manchmal auch sanftes Anstupsen, kostet Energie und Zeit und ist eine sinnvolle Rolle für jemanden, der sich sonst obsolet fühlt.

Wie geht man mit Mitarbeitern um, die sich gegen die neue Arbeitsweise sträuben?

Nicht durch Gleichmacherei. Das Team besteht aus Individuen mit unterschiedlichen Fähigkeiten, die zuerst erforscht und dann passend eingesetzt werden müssen. Auch Eigenbrötler lassen sich integrieren oder zumindest andocken. Der Versuch, sie krampfhaft in das Vorgehen zu zwängen, erzeugt auf beiden Seiten nur Frust. In den beschriebenen Projekten wurden aus anfänglichen Skeptikern später die Zugpferde der Methodik.

Sollten Testmethoden und Werkzeuge zentral vorgegeben werden?

Besser nicht. Das Team sollte selbst entscheiden, welche Testmethodiken es weiterverwendet und welches Automatisierungsframework es auswählt. Der Prozess wird in jeder Retrospektive nachjustiert. Diese Selbstverantwortung erzeugt deutlich mehr Identifikation und Freude an den Aufgaben als Vorgaben aus einem unternehmensweiten Testhandbuch.

Wie viel Zeit muss man für die Umstellung auf agile Arbeitsweisen einplanen?

Mehr, als das Tagesgeschäft freiwillig hergibt. Entwickler brauchen Zeit, um sich mit neuen Themen wie Test-Driven Development auseinanderzusetzen, Tester brauchen Zeit für die Einarbeitung in Testautomatisierungsframeworks und die Auswahl passender Methodiken. Wird diese Zeit nicht bereitgestellt, klappt die Umstellung nicht. Aus der Beschäftigung mit den Themen entsteht die Erkenntnis über den Nutzen.

Welche Rolle spielt der Umgang mit Fehlern beim agilen Arbeiten?

Ein agiles Vorgehen muss Fehler zulassen, sowohl im Prozess als auch im Inhalt. Review-Meetings und Retrospektiven sorgen dafür, dass sich Fehler nicht festsetzen, weil laufend korrigiert werden kann. Gerade deshalb darf man sie zulassen, statt jede Abweichung sofort zu unterbinden.

Ist Spaß im Team ein ernstzunehmender Erfolgsfaktor?

Ja, einer der wesentlichsten. Wer Spaß an seinen Aufgaben hat, engagiert sich entsprechend stärker. Als Beleg schildert der Autor einen Software-Entwickler, der nach einem Planning-Meeting sagte, dass ihm ausgerechnet dieses Meeting richtig Spaß gemacht habe. Wenn Methoden und Praktiken Stück für Stück einrasten, entsteht aus dem Team heraus ein Flow.