Crossfunktionale Teams in der agilen Entwicklung sind Teams, in denen jedes Mitglied tiefes Spezialwissen mitbringt und damit das Team auch über die eigene Kernrolle hinaus unterstützt. Das Risiko ist Breite ohne Tiefe: Wenn alle alles machen sollen, macht niemand etwas richtig gut. Qualität bleibt nur dann gemeinsame Verantwortung, wenn jede Person ihren eigenen Beitrag dazu kennt.
Das Wichtigste in Kürze
- Wer sagt, alle seien für Qualität verantwortlich, ohne dass jemand konkret zuständig ist, sorgt dafür, dass sich niemand zuständig fühlt. Den meisten agilen Teams fehlt zudem die Testkompetenz, um diese Verantwortung gemeinsam zu tragen.
- Breite Kompetenzprofile, die sogenannte Kammform, führen zu flachem Wissen auf ganzer Linie. Zwei oder drei tiefe Kompetenzen pro Person sind die realistische Obergrenze für echte Exzellenz.
- KI-generierte Tests zu reviewen, ohne Testentwurfsverfahren zu beherrschen, bringt nichts: Wer nicht weiß, wie das richtige Ergebnis aussieht, erkennt auch nicht, was falsch ist oder fehlt.
- Der Kontext bestimmt den Beitrag des Testers: Wer keinen technischen Hintergrund hat, bringt am meisten am Anfang der Entwicklung ein, bei Akzeptanzkriterien und Prozessmodellen, nicht hinten in der Pipeline.
Mechanisch agil: Woran crossfunktionale Teams scheitern, bevor sie anfangen
Viele Unternehmen führen Agilität ein, indem sie die Oberfläche kopieren und den Sinn dahinter überspringen. Sie lesen einen Teil des Scrum Guides, führen ein paar Rollen und Meetings ein und nennen das Ergebnis agil. Gitte Ottosen nennt das mechanisch agil, und genau hier beginnen crossfunktionale Teams zu scheitern.
Der Test ist einfach. Frag einen Scrum Master oder sogar manche Coaches, was im Agilen Manifest steht oder wie die zwölf Prinzipien lauten. Oft kommt keine Antwort. Dieses Wissen ist aber das Fundament eines funktionsübergreifenden Teams, denn es erklärt, warum das Team so arbeitet, wie es arbeitet.
Agil machen und agil sein sind zwei verschiedene Dinge. Wer agil macht, schraubt die Methode als Hack an. Wer agil ist, versteht den Zweck hinter der Praxis und handelt danach.
Braucht ein Scrum Team noch Tester?
Ja. Scrum sagt nirgends, dass Tester überflüssig sind. Der Scrum Guide spricht zwar von “Developers”, aber gemeint ist damit jedes Teammitglied, dessen Spezialwissen dem Team hilft, Wert zu liefern. Dazu gehören Tester, Business-Analysten und andere.
Das Missverständnis hat reale Folgen. Gitte hat erlebt, wie Unternehmen ihre Testmanager und Tester entlassen haben, mit der Begründung, Scrum verlange ein Entwicklerteam und die Entwickler sollten jetzt eben alles machen. Diese Entscheidung beruht auf einem Begriff, der aus dem Zusammenhang gerissen wurde.
Die Aufgabe eines Teammitglieds ist, mit tiefem Können zum gelieferten Wert beizutragen. Testen ist eine dieser Spezialdisziplinen und keine Aufgabe, die verschwindet, sobald sich das Organigramm ändert.
Quality Engineering: eine starke Idee für eine Welt, in der kaum ein Team lebt
Quality Engineering als gemeinsame Haltung, bei der das ganze Team die Qualität verantwortet, ist ein lohnendes Ziel. Das Ideal ist ein leistungsstarkes Team, das die volle Verantwortung übernimmt und gut testen kann. Das Problem ist der Abstand zwischen diesem Ideal und den meisten echten Teams.
Den meisten agilen Teams fehlt die Testkompetenz dafür. Wenn Quality Engineering einfach auf alles gepackt wird, was das Team ohnehin schon tut, und niemand das nötige Können hat, wird das Ergebnis schlechter, nicht besser. Die Haltung stimmt. Die Reife fehlt.
“Qualität ist Wert für eine Person, auf die es ankommt, zu einem bestimmten Zeitpunkt.” Diese Definition, die Gitte auf Jerry Weinberg zurückführt und die James Bach und Michael Bolton erweitert haben, gibt der Arbeit eine Richtung: die Menschen finden, auf die es ankommt, und ihnen zur richtigen Zeit Wert liefern.
“Wir dürfen nicht vergessen, dass die meisten von uns nicht in einer perfekten Welt leben. Wir leben in der echten Welt. Nicht in einer Welt voller Einhörner.”
(Gitte Ottosen)
Wenn in crossfunktionalen Teams “alle verantwortlich” sind, ist es oft niemand
Wenn allen etwas gehört, löst sich die Verantwortung schnell auf. Manche Teams nehmen die gemeinsame Verantwortung ernst. Viele nicht, und die Qualität fällt durch die Lücken zwischen den Rollen.
Für die meisten Entwickler ist Testen jenseits von Unit- und Unit-Integrationstests keine Herzensangelegenheit. Sie haben ihren Beruf gewählt, um Software zu bauen, nicht um sie in der Breite zu testen. Das ist kein Makel, dort liegen einfach ihr Können und ihr Interesse.
Es gibt aber auch Menschen, die Testen lieben. Klüger ist es, die Leute dort arbeiten zu lassen, wo ihre Leidenschaft liegt, denn aus Leidenschaft wächst Können. Wer jemanden zu einer Arbeit zwingt, die ihn nicht interessiert, bekommt keine guten Ergebnisse. Entwickler sollen trotzdem testen, aber sie brauchen das nötige Handwerkszeug und jemanden, der ihnen hilft, es aufzubauen.
Wer zu breit wird, kann am Ende nichts richtig
Der Weg vom I-förmigen zum T-förmigen Spezialisten hat sich immer weiter gedehnt. Aus der T-Form wurden Pi-Form und M-Form, also drei tiefe Kompetenzen, und das ist noch machbar. Dann kam die Rede von kammförmigen Menschen: viele Zinken, jeder davon kurz.
Das Bild trägt die Warnung schon in sich. Ein Kamm hat viele Fähigkeiten und keine Tiefe. Wenn alle alles machen sollen, macht niemand etwas wirklich gut.
Der Druck lastet nicht nur auf den Testern. Entwickler tragen die Tools, die Pipeline und die kognitive Last der gesamten Lieferkette. Gitte verweist auf einen Cartoon von Comic Agile mit dem Titel “The Agile Team’s Cognitive Overload”, der zeigt, wie breit die Last verteilt ist.
Ziel ist eine N- oder M-Form: zwei oder drei Bereiche mit echter Tiefe, dazu die Fähigkeit, Kollegen außerhalb des eigenen Kerns zu unterstützen. Genau das beschreibt Scrum, und es ist besser, als sich zu verzetteln.
Wie ein Tester im agilen Team Mehrwert schafft
Finde heraus, an welcher Stelle du am meisten zum gelieferten Wert beiträgst, und arbeite dort. Die Antwort hängt vom Kontext ab, ist nicht fix und ändert sich mit Team und Projekt.
Ein Tester ohne technischen Hintergrund kann keine Unit Tests reviewen und die Pipeline nicht unterstützen. Derselbe Tester kann aber dem Product Owner helfen, gute Akzeptanzkriterien zu schreiben, Feature-Beschreibungen zu prüfen und die Anforderungsaufnahme zu verbessern. Der Wert wandert an den Anfang des Entwicklungsmodells, bevor es überhaupt Code gibt.
Ein Tester mit technischem Hintergrund kann Testautomatisierung übernehmen, Unit- und Unit-Integrationstests unterstützen und an der Pipeline mitarbeiten und bringt trotzdem Testentwurfsverfahren und exploratives Testen ein. Gleiche Rolle, anderer Beitrag, je nach Können.
Auf der Kundenseite eines Projekts, wo eine klare Grenze zwischen dir und den Entwicklern des Dienstleisters verläuft, liegt der Wert beim Business. Du bildest Abläufe ab, zeichnest Prozessdiagramme und nutzt sie, um zu testen und den Entwicklern zu zeigen, was das System leisten soll. Tester verstehen den vorgesehenen Einsatz eines Systems oft besser als alle anderen.
Wo du anfängst: erst das Fundament, dann die oberen Stockwerke
Du kannst nicht alles auf einmal reparieren, also fang ganz unten an, bei Unit- und Unit-Integrationstests. Wenn das Team dort reifer wird, verlagerst du deinen Schwerpunkt.
Das kann ein Tester vorantreiben, ohne selbst Code zu schreiben. Du kannst strukturiertes Testen erklären, den Entwicklern bei der Entscheidung helfen, was getestet werden soll, und dafür sorgen, dass die Tools das unterstützen, was sie brauchen. Investiere eine Weile in die Reife der Entwickler und konzentriere dich danach auf die Arbeit, die nur ein Tester gut kann.
Der Ausgangspunkt in der Praxis ist selten sauber. User Stories und Feature-Beschreibungen sind oft dürftig oder fehlen, Akzeptanzkriterien gibt es nicht, und manche Entwickler haben jahrzehntelang nie mit Testen zu tun gehabt und auch keine Lust, damit anzufangen. Verschaff dir zuerst ein Bild von deinem Kontext und entscheide dann, wo du beginnst.
Zwei Mappings, mit denen das Team die Qualität selbst in die Hand nimmt
Der TMAP-Ansatz bietet zwei Workshop-Werkzeuge für kontinuierliche Verbesserung: Quality-to-Activity-Mapping und Quality-to-People-Mapping. Beide machen sichtbar, welchen Anteil jedes Teammitglied an der Qualität hat.
Für das Quality-to-People-Mapping führst du einen Workshop mit sechs Schlüsselbereichen durch, darunter Qualitätsbewusstsein, Automatisierung und Infrastruktur. Die Bereiche kommen in die erste Spalte einer Matrix, die Rollen im Team in die oberste Zeile: Entwickler, Tester, Business-Analyst und weitere. Jede Person sammelt, welchen Anteil sie in jedem Bereich hat und was sie beitragen kann.
Sobald die Wand voller Klebezettel ist, priorisiert das Team, denn nicht alles lässt sich gleichzeitig verbessern. Priorisieren kannst du nach Personen oder nach den DevOps-Aktivitäten, bei denen Qualität eine Rolle spielt.
Es geht um Eigenverantwortung. Die Verbesserung wird nicht von außen hineingedrückt. Sie macht dem Team bewusst, wo es steht, und zeigt den Einzelnen, was sie beitragen können. Außerdem durchbricht sie den Reflex, Qualität mit Testen gleichzusetzen, obwohl Qualitätssicherung, Qualitätssteuerung und Testen drei verschiedene Dinge sind.
KI verschiebt die Arbeit, sicher wird das nur mit Können
KI kann User Stories reviewen, Akzeptanzkriterien entwerfen und Gherkin-Szenarien erzeugen. Ob das Ergebnis stimmt, muss trotzdem ein Mensch mit Urteilsvermögen prüfen. Kritisches Denken ist hier die wichtigste Fähigkeit.
Dabei steckt ein Widerspruch in der Entwicklung. Berichte zeichnen eine Zukunft, in der Tester als Reviewer und Gatekeeper von KI-Ergebnissen arbeiten, während die gemessene Kompetenz von Testerinnen und Testern sinkt. Wer nicht weiß, wie gutes Testen aussieht, kann das Tor nicht bewachen.
Testentwurfsverfahren klingen altmodisch und bleiben trotzdem unverzichtbar. KI-generierte Testfälle zu reviewen, ohne das zugrunde liegende Verfahren zu verstehen, bringt nichts, weil du nicht beurteilen kannst, ob das Ergebnis taugt. Gitte hat die Basisversion von ChatGPT dabei ertappt, wie sie für eine einfache Anfrage viel zu viele Testfälle erzeugt hat, gerade weil sie das Verfahren gut genug kannte, um den Fehler zu sehen.
Testen schafft Vertrauen. Damit Stakeholder sicher sein können, dass das Gelieferte sicher ist und den erwarteten Wert bringt, muss das Team prüfen können, ob die Anforderung richtig verstanden wurde und ob die KI dieser Richtung gefolgt ist.
Was Tester lernen sollten, um im Zeitalter von KI wertvoll zu bleiben
Tiefe statt Breite. Die Basis sind ein, zwei Handvoll Testentwurfsverfahren, die du so gut verstehst, dass du sie täglich einsetzt und merkst, wenn die KI danebenliegt.
Gittes vollständige Liste:
- Testentwurfsverfahren. Kenne genug davon, um sie im Alltag anzuwenden und KI-generierte Tests an dem zu messen, was du erwartest.
- Exploratives Testen. Viele behaupten, es zu tun, und testen in Wahrheit ad hoc. Exploratives Testen ist trotzdem strukturiert und nutzt kritisches Denken und Testentwurfsverfahren. Es wird nur nicht in geskripteten Testfällen dokumentiert.
- Testentwurf aus Anforderungen. Nutze Verfahren, um von einer Prozesszeichnung zu Tests zu kommen, sodass die Überdeckung ausreicht, weder zu wenig noch zu viel.
- Risikobasiertes Testen. Viele sagen, sie machen es, wenige tun es. Eine Analyse der Produkt- oder Qualitätsrisiken ist nur der Anfang. Der schwierigere Schritt ist, daraus die wirksamsten Tests abzuleiten, denn Teams testen oft zu viel oder das Falsche zu intensiv.
- Prompting. Nutze ChatGPT, Copilot und ähnliche Tools als Unterstützung, nicht als Ersatz. Verstehe, wo sie stark sind und wo nicht, und übernimm ihre Ergebnisse nie unkritisch per Copy-and-paste.
Vielleicht brauchst du gar keinen weiteren Kurs. Lies das Material, das du schon hast, noch einmal, such dir Videos oder E-Learning, setz dich dann mit einem Kollegen über echte Unterlagen und frag, welches Verfahren passt. Ausprobieren ist der schnellste Weg zum Lernen. Gelerntes, das nie in die Praxis kommt, ist verschenkt.
Häufig gestellte Fragen
Bedeutet Scrum, dass ein Team keine Tester mehr braucht?
Nein. Der Scrum-Leitfaden verwendet den Begriff „Entwicklerteam“, aber ein Entwickler in diesem Sinne ist jedes Teammitglied, dessen Fachwissen die Fähigkeit des Teams unterstützt, Wert zu schaffen, einschließlich Tester und Business-Analysten. Gitte Ottosen hat erlebt, dass Unternehmen Testmanager und Tester mit der Begründung entlassen haben, dass Entwickler nun alles selbst erledigen sollten. Diese Entscheidung beruht auf einem Begriff, der aus dem Zusammenhang gerissen wurde.
Woran erkennst du, ob ein Unternehmen Agilität nur mechanisch umsetzt?
Frag den Scrum Master oder sogar den Coach, was im agilen Manifest steht oder wie die zwölf Prinzipien lauten. Oft kommt keine Antwort. Das Unternehmen hat die Oberfläche von Agilität kopiert und deren Sinn übersehen: Ein paar Rollen und Rituale wurden eingeführt, der Zweck fehlt. Das ist der Unterschied zwischen „agil machen“, als Hack angeschraubt, und „agil sein“.
Ist gemeinsame Verantwortung für Qualität für die meisten agilen Teams realistisch?
Als Denkweise ist es sinnvoll, in der Praxis sind die meisten Teams noch nicht dafür bereit. Gemeinsame Verantwortung funktioniert nur dort, wo das Team tatsächlich die Kompetenz besitzt, gut zu testen, und die meisten agilen Teams haben diese nicht. Quality Engineering einfach auf alles andere zu stapeln, ohne dass jemand über die entsprechenden Fähigkeiten verfügt, verschlechtert die Ergebnisse eher, als dass sie besser werden. Das Ziel ist richtig, aber die Reife fehlt.
Wie viele tiefgehende Kompetenzen kann ein Teammitglied realistisch gesehen haben?
Zwei oder drei. Der Weg von der I-Form zur T-Form, dann zur Pi-Form und zur M-Form bleibt praktikabel bei drei tiefgehenden Kompetenzen plus der Fähigkeit, Teamkollegen außerhalb des eigenen Kernbereichs zu unterstützen. Kammförmige Profile (viele Zinken, aber jeder Zinken zu kurz) sind das Warnzeichen: Breite ohne Tiefe. Wenn von jedem erwartet wird, alles zu tun, macht niemand etwas wirklich gut.
Sollten Entwickler das Testen übernehmen, wenn kein dedizierter Tester im Team ist?
Entwickler sollten testen, aber sie brauchen die entsprechenden Fähigkeiten und jemanden, der sie dabei unterstützt, diese aufzubauen. Für die meisten Entwickler ist das Testen über die Unit- und Unit-Integrationsebene hinaus nicht ihre Leidenschaft; sie haben diesen Beruf gewählt, um Software zu entwickeln. Leidenschaft führt zu Kompetenz, daher ist es besser, Menschen dort arbeiten zu lassen, wo ihr Interesse liegt, als ihnen breit gefächertes Testen aufzuzwingen.
Wo bringt ein Tester ohne technischen Hintergrund den größten Mehrwert?
Im Vorfeld, bevor überhaupt Code existiert. Jemand, der keine Unit-Tests überprüfen oder die Pipeline unterstützen kann, kann dem Product Owner dennoch helfen, gute Akzeptanzkriterien zu verfassen, Feature-Beschreibungen zu überprüfen und die Erfassung von Anforderungen zu verbessern. Auf der Kundenseite eines Anbieterprojekts liegt der Mehrwert eher im geschäftlichen Bereich: das Erstellen von Workflow- und Prozessdiagrammen, die sowohl Tests vorantreiben als auch Entwicklern die beabsichtigte Nutzung vermitteln.
Brauchen Tester noch Testentwurfstechniken, wenn KI Testfälle generiert?
Ja, sonst bringt die Überprüfung der Ergebnisse nichts. Ohne Kenntnis der zugrunde liegenden Technik kannst du nicht erkennen, ob generierte Tests stichhaltig sind oder was fehlt. Gitte Ottosen hat entdeckt, dass die Basisversion von ChatGPT bei einer einfachen Anfrage viel zu viele Testfälle erzeugt hat, weil sie die Technik gut genug kannte, um die Fehlhandlung zu erkennen. Berichte stellen Tester als Gatekeeper der KI-Ergebnisse dar, während die gemessene Kompetenz abnimmt.
Wie kann ein Team „Qualität“ konkret umsetzen, statt sie nur als Slogan zu betrachten?
Indem man den Beitrag jedes Einzelnen in einem Workshop sichtbar macht. Beim Quality-to-People-Mapping werden sechs Schlüsselbereiche, darunter Qualitätsbewusstsein, Automatisierung und Infrastruktur, in die erste Spalte einer Matrix gesetzt und die Teamrollen in die oberste Zeile. Jedes Mitglied überlegt sich, was es in jedem Bereich beiträgt, dann legt das Team Prioritäten fest. Die Verbesserung kommt von innen, und Qualität bedeutet nicht mehr nur das Testen.
