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.
Dieser Beitrag wurde verfasst von:
