Im ersten Teil und zweiten Teil wurden die Aufgaben des Testmanagers erfolgreich einer agilen Transition unterzogen und für kleine Scrum-Teams nachgewiesen, dass kein Testmanager mehr benötigt wird. Eine andere Herausforderung ergibt sich bei mehreren Scrum-Teams, die gemeinsam an einem Produkt arbeiten. Lassen sich die beschriebenen Überlegungen, welche sich alle auf ein kleines Scrum-Projekt mit einem Team beziehen, auch auf die großen Projekte übertragen?

Benötigen wir für große Scrumprojekte wieder einen Testmanager?

In vielen Unternehmen, die Scrum einsetzten, arbeiten mehrere Teams gemeinsam an der Entwicklung eines Produkts. Es gibt bereits Überlegungen zu skalierten Scrum auf Unternehmensebene und wie die agilen Prinzipien trotz wachsender Komplexität eingehalten werden können. Boris Gloger sieht dabei zwei Problemfelder: “Einhaltung des skalierten Scrum Frameworks” und “Skalierung des Anforderungsprozesses”. Als Lösung führt er weitere Rollen ein: den Company Scrum Master und den Company Product Owner, die übergreifend die Scrum Master bzw. Product Owner des Projektes begleiten. Beide Rollen stimmen sich mit ihren Gegenstücken in den einzelnen Scrum-Teams ab und verwalten die Scrum-Werkzeuge auf Unternehmensebene wie Company Product Backlog und Company Scrumboard.

Lässt sich dieses Konzept auch auf den Test übertragen: Benötigen wir quasi einen Company Test Owner oder Company QA Master? Aufgabe dieses neuen Werkzeuges wäre die Abstimmung und Verantwortung für den übergreifenden und integrativen Testprozess, das Aufsetzen der notwendigen gemeinsamen Test-Strukturen sowie die Befüllung des Backlogs mit Stories, Tasks und Incidents rum um das Thema QA.

Für Projekte mit einer übersichtlichen Anzahl (2 bis 8) von Scrum-Teams lassen sich diese Koordinationsaufgaben innerhalb des übergreifenden Abstimmungsmeeting, dem Scrum of Scrums, bewerkstelligen. Sollten die Abstimmungen testspezifischer und langwieriger werden, dann sollte bei Bedarf ein eigenes Test Meeting aufgesetzt werden. Dazu wird von jedem Team ein Teammitglied mit dem notwendigen Testwissen entsandt. Ist die Anzahl der Teams größer oder müssen Abstimmungen zwischen mehreren Projekten zu QA-Themen durchgeführt werden, dann können auch hier die Gilden zum Einsatz kommen. Die Gilden sammeln Best Practice Beispiele, die Sie allen Projekten zur Verfügung stellen oder benennen Coaches, die neuen Projekten agiles Testvorgehen näherbringen. Die Gildenmeister koordinieren wichtige Entscheidungen und moderieren die Scrum Teams, sofern die Definition von gemeinsamen Regeln und Lösungen notwendig ist.

Es lässt sich festhalten, dass ein Testmanager in agilen Unternehmen auch für große Projekte nicht mehr benötigt wird. Erreicht wird dies aber nur durch die vollständige Agile Transition der Aufgaben eines Testmanagers. Denn es ist notwendig jeder Aufgabe des Testmanagers speziell auch in der Kommunikation und Abstimmung ein agiles Werkzeug gegenüberzustellen.

Im ersten Teil wurden die operativen Aufgaben des Testmamagers erfolgreich einer agilen Transition unterzogen und für kleine Scrum Teams nachgewiesen, dass kein Testmanager mehr benötigt wird. Doch funktioniert das auch mit den strategischen Aufgaben eines Testmanagers bzw. Wer übernimmt die strategischen Aufgaben des Testmanagers?

Wer übernimmt die strategischen Aufgaben des Testmanagers in agilen Unternehmen?

Das strategische Aufgabenfeld eines Testmanagers ist das Qualitätsmanagement (QM), welches laut DIN ISO 8402 „alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagements verwirklichen“ umfasst.

Ob eine Firma nach klassischen oder agilen Methoden entwickelt, das Qualitätsmanagement bleibt in der Verantwortung der Geschäftsführung des Unternehmens. Dieser Aufgabenbereich kann, sollte und darf nicht vom Scrum Team übernommen werden. Auf den ersten Blick ändert sich grundsätzlich nichts in Organisation und Aufgabenteilung. Auf dem zweiten Blick ergibt sich eine Problemstelle für agile Firmen. In der klassischen Welt diente der Testmanager als Schnittstelle zwischen operativer und strategischer Ebene. Er verteilte die Informationen zwischen dem Management und der operativen Ebene, übermittelte strategische Vorgaben und Methoden in die Testteams oder spielte Entwicklungen und Verbesserungen in Richtung Management.

Aber wie kommen Informationen im agilen Umfeld von der strategischen Ebene in die operative und zurück? Die Antwort ist: Die agile Transition ist nicht mit der Zuordnung der operativen Tasks des Testmanagers an das Scrum Team abgeschlossen. Die Lösung für die agile Transition der „Schnittstelle“ zwischen den Ebenen ist gleich der agilen Transition der operativen Aufgaben des Testmanagers. Für die vorhandenen Aufgaben der Unternehmenskommunikation stehen neue Konzepte und Werkzeuge bereit.

Eines der neuen Konzepte ist die sogenannten Gilde. Gilden (oder in unserem Unternehmen Kompetenzteams genannt) sind ein Werkzeug, welches das Wissens- und Informationsmanagement in geordnete Bahnen lenkt. Sie sind als Matrixorganisation aufgebaut und stehen neben der normalen Unternehmensstruktur. Die Gilden haben die Aufgabe die Knowhow-Träger des Unternehmens zu bündeln und bieten den Mitarbeitern einen Platz zum Austausch von Wissen oder der Umsetzung von Weiterbildungsmaßnahmen oder stimmen übergreifende Projektentscheidungen wie Testumgebungsaufbau oder Codequalitätsregeln ab. Je nach Zielsetzung des Unternehmens können der Aufbau und die Gliederung der Gilden unterschiedlich sein: So können die Gilden sich nach Kompetenzfeldern aufteilen wie Java-Entwicklung, .NET-Entwicklung, Test oder Prozessanalyse. Es können aber auch komplette Scrum Teams in Gilden zusammengefasst werden, die sich im Projekt gemeinsam einem bestimmten Thema widmen wie QA, Datenbankanbindung, GUI oder Schnittstellen (siehe Abbildung 1).

Die Gilden arbeiten nach folgenden Muster: Für jeden Mitarbeiter wird seine primäre Rolle (zum Beispiel Entwickler, Tester (QAlas), Product Owner und Scrum Master), die er im täglichen Arbeitsleben wahrnimmt, ermittelt. Mit dieser Rolle wird er einer passenden Gilde zugeordnet. Hier tauschen sich die Mitglieder nach Aufgabenfeldern aus, führen interne Schulungen durch, sammeln das vorhandene Wissen in Portalen oder tauschen sich über Best Practice in einzelnen Projekten aus. Die Moderation und Koordination innerhalb der Gilde übernimmt ein Gildenmeister. Er besitzt nach dem Motto „primus inter pares“ keine höheren Rechte als seine Gildenkollegen und wird aus dem Kreis der Gildenmitglieder gewählt. Der Gildenmeister ist zentraler Ansprechpartner für seine Gildenmitglieder, die anderen Gildenmeister und das Management. Dies ist notwendig, da die Gilden sich aktiv interdisziplinär austauschen, aber auch Feedback aus der operativen Ebene wie neue Entwicklungen oder Technologien an den Vertrieb weitergeben oder Hinweise für Schulungen an das Personal geben sollen.

Im letzten Teil gehen wir der Frage nach, was passiert, wenn mehrere Scrum Teams an einem Projekt gemeinsam arbeiten und der Abstimmungsaufwand auch für den Bereich QA zunimmt.

Ein Kollege stellte mir vor einiger Zeit die Frage, ob wir im agilen Entwicklungsprozess wie Scrum noch einen Testmanager benötigen. Meine erste Antwort war nein, da das Agile Manifest und das Scrum Framework nur drei Rollen kennt: Product Owner, Entwicklungsteam und Scrum Master. Im Scrum Team – der Gesamtheit der drei genannten Scrum-Rollen – ist also kein Testmanager vorgesehen. Aber auf den zweiten Blick ergab sich die Frage, wer aus dem Scrum Team übernimmt die Aufgaben des Testmanagers in und um den Sprint herum?

Studien wie der ASQF Branchenreport 2014^[1] und Standish Chaos Report 2011 zeigen, dass agile Methoden bereits in den Unternehmen ein fester Bestandteil sind. Außerdem zeigt der Standish Chaos Report auf, dass Projekte in denen agile Verfahren zum Einsatz kommen, höhere Erfolgschancen haben als „klassische Projekte“.  Grundlage dieser Entwicklung war das Agile Manifest von Ken Schwaber und Jeff Sutherland. In ihm wurden Grundregeln und Vorgaben definiert, die „bessere Wege auf[zeigen], Software zu entwickeln, indem [die Prozessbeteiligten] es selbst tun und anderen dabei helfen, es zu tun“[²].

Die wichtigsten Grundsätze aus dem Agilen Manifest sind:

• Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
• Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.

Unternehmen, die ihre Entwicklung auf die agile Arbeitsweise umstellen, haben einen Wettbewerbsvorteil gegenüber Firmen, die nach klassischen Vorgehen arbeiten. Aber die Umstellung der Prozesse auf Entwicklungsmethoden, wie Scrum – auch agile Transition genannt – stellt eine große Herausforderung dar. Agilität erreicht man nicht mit der Aufteilung der Entwicklungsmeilensteine in Sprints und der Benennung eines Product Owners (siehe Abbildung 1). Es müssen umfangreiche Änderungen der Organisation, hin zu einer agilen Arbeits- und Lebensweise, stattfinden.

Am Beispiel des Testmanagers lässt sich die Herausforderung der agilen Transition sehr schön nachvollziehen. Die Frage lautet: Wenn wir in Scrum keinen Testmanager benötigen, wer übernimmt seine Aufgaben? Der Product Owner? Der Scrum Master? Das Team?

Nach der Scrum Alliance ist der Product Owner die Person, die für die punktgenaue und pünktliche Erstellung des Produktes verantwortlich ist. Der Product Owner füllt und verfeinert das Product Backlog und stellt sicher, dass jeder weiß was darin enthalten und mit welcher Priorität es versehen ist. Damit ist er in der Regel am nächsten an der “Business-Seite” des Projekts. Scrum erfordert, dass das Entwicklungsteam eine nach Funktionen gemischte Gruppe ist – die alle notwendigen Fähigkeiten vereint – die für die Entwicklung des Produktes notwendig sind. Das Team organisiert sich selbst: das heißt es wählt selbständig den umzusetzenden Inhalt des Sprints und kümmert sich um die Planung, Steuerung und Umsetzung. Der Scrum Master ist der “Lotse” durch die Untiefen des Scrum Frameworks. Er hilft dem Rest des Scrum Teams bei der Einhaltung der Scrum-Regeln. Eine weitere Aufgabe des Scrum Masters ist es, Hindernisse für den Fortschritt des Teams aus den Weg zu räumen.

Auch nach Studium der Rollen von Scrum ist nicht ersichtlich: Wer die Aufgaben des Testmanagers übernimmt? bzw. Wie sie verteilt werden? Um die Fragen zu beantworten, ist es notwendig erst einmal festzustellen, welche Aufgaben ein Testmanager im klassischen Test- und Qualitätssicherungsprozess wahrnimmt. Laut dem International Software Testing Qualifications Board (ISTQB), der Zertifizierungsstelle für Tester, gehen die Aufgaben und Einsatzgebiete des Testmanagers über die Steuerung des Testprojektes hinaus. Er leitet die Testabteilung oder das Testteam und damit die Ressourcen für die Tests. Er erstellt Berichte, eskaliert in Richtung Entwicklung, Fachabteilung und Projektleitung, schätzt Testprojekte, setzt die Einhaltung der Qualitätsprozesse und -verfahren des Unternehmens durch, beschafft die Testing-Tools für die Organisation und überprüft die Testpläne, sowie die Testfälle.

Die Aufgabenebenen lassen sich in zwei Felder aufteilen: strategisch und operativ (siehe Abbildung 2). Die operative Ebene beschäftigt sich mit der Planung und Konzeption der Testfälle und Tests, der Steuerung der Testdurchführung, sowie der Kommunikation innerhalb des Projektes. Die strategische Ebene beinhaltet die Aufgaben des Qualitätsmanagements.

Die operativen Aufgaben können nicht vom Scrum Master oder Product Owner übernommen werden. Der Product Owner mischt sich nicht in die Umsetzung ein und der Scrum Master nicht in die Entwicklung. Die Testaufgaben werden in der agilen Entwicklung durch das Team übernommen. Und nach der Definition und Aufteilung der Aufgaben des Testmanagers ist es nun möglich zu untersuchen wie diese in den agilen Prozess eingebracht werden können. Es ergibt sich aber ein Problem: Eine klare Zuordnung zu einer Person ist nicht möglich, da in Scrum alle Aufgaben auf das agile Team verteilt werden.

Die Lösung des Problems liegt im Framework Scrum selbst. Es stellt ein umfangreiches Paket an Werkzeugen und Artefakten bereit. Und diese lassen sich den Aufgaben des Testmanagers gegenüberstellen. Wir haben in unseren Scrum Teams eine vollständige agile Transition der Aufgaben durchgeführt und festgestellt, dass Scrum jeder Aufgabe des Testmanagers ein Werkzeug oder Artefakt gegenüberstellen lässt.

So erfolgen die Überlegungen zur Teststrategie und die im Vordergrund stehenden Qualitätsmerkmale im Planning des Sprints und Backlog Grooming. Die Pass-Fail-Kriterien, also die Kriterien ob ein Sprint erfolgreich bzw. der Test abgeschlossen ist, werden in der Definition of Done definiert (siehe Abbildung 3).

Im Sprint Review wird die Umsetzung der Anforderungen verifiziert und validiert (siehe Abbildung 4).

Zusätzlich ermöglichen die Stories bzw. ihre Repräsentation am Scrum Board und in den Backlogs eine Dokumentation des Fortschritts sowie der Qualitätsgradbemessung (siehe Abbildung 3).

Jeder Aufgabe des Testmanagers lässt sich also ein agiles Werkzeug oder Artefakt gegenüberstellen. Damit ist die vollständige agile Transition der Aufgaben eines Testmanagers erreicht. Unter der Voraussetzung, dass das Scrum Team das notwendige Testwissen für die Umsetzung der anstehenden Entwicklungs- und Testaufgaben besitzt, wird für kleine Projekte kein Testmanager benötigt. Steht das Wissen noch nicht zur Verfügung muss das Team ausreichend gecoacht werden.

Im nächsten Teil wird beleuchtet wer die Aufgaben der strategischen Ebene übernehmen kann und was in Projekten mit mehreren Scrum Teams passiert, die gemeinsam an einem Produkt arbeiten.