Qualitätssteigerung durch selbstorganisierte Teams – (K)ein Widerspruch?

Agile QS in Agilen Teams

Georg Haupt

„Testmanager? Ach was, die braucht doch heute keiner mehr!“ Solche Sätze liegen dem agilen Entwickler leicht auf der Zunge. Wie ist es um die übergeordneten Stellen und Rollen im agilen Kontext bestellt? Schauen wir da einmal genauer hin: Am Beispiel der agilen Qualitätssicherung (QS) wird die Veränderung sehr deutlich.

Früher und Heute

„Früher” in der klassischen Welt gab es, häufig orientiert am Entwicklungsprozess, diverse Teststufen. Zum Beispiel Systemintegrationstest, End2End-Test, Performanz-Test, Fachtest etc. Normalerweise hatte die Testabteilung eine Art Vogelperspektive auf die zu testenden Ende-zu-Ende-Prozesse. Nicht selten war es nur die QS, die als einzige den Gesamtzusammenhang im Blick hatte. In der klassischen Welt sind Testspezialisierungen wie Performanz-, Security- oder Usability-Tests sehr häufig verbreitet. Wie ist es im agilen Kontext? Verantwortlich für die Qualität ist nun das gesamte Team. Sie entscheiden gemeinsam über die Art, Umfang und Tiefe der Testaktivitäten. Das Empfinden für die Qualität liegt bei jedem einzelnen Mitglied im Team – also bei den Entwicklern. Alle sind verantwortlich – aber keiner macht es? Ich möchte an dieser Stelle anmerken, dass auch Tester für mich ganz klar zu den Entwicklern gehören. Entwickler ist nicht gleich Coder. Da die QS nun nicht mehr auf ein nachgelagertes Team delegiert wird, obliegt das ganze Thema Qualität dem Entwicklungsteam. So die Theorie! „Die testen die Qualität da schon rein” ist ein Satz, der in agilen Teams nicht vorkommt.

Wo bleibt da der Überblick?

Ein wesentlicher Erfolgsfaktor und Grundsatz der agilen Entwicklung ist die Selbstorganisation. Gleichberechtigte und selbstorganisierte Teams haben einen qualitativ höheren Output als hierarchisch geführte Organisationen. „Klingt doch alles super, was ist
denn jetzt das Problem?“, könnte man jetzt fragen. Soweit zum Entwicklungsteam. Aber
wer kümmert sich um End2EndTests, sprintunabhängige Testtermine oder den übergreifenden fachlichen Austausch? Das Team? Wohl kaum. Welches Team überhaupt? Die meisten agilen Teams sind so sehr damit beschäftigt, in der eigenen Suppe zu
rühren, dass sie das komplette Menü aus den Augen verlieren. Die Perspektive des Testmanagements einer klassischen Testabteilung fehlt in vielen agilen Entwicklungsmodellen. Ab einer gewissen Anzahl von agilen Teams gehen häufig die Koordination und die End2End-Prozesse verloren, während die Komplexität steigt und spezielles Testwissen noch wichtiger wird.

Wir brauchen einen Überblick!

Besonders bei agiler Entwicklung kommt das Testwissen im DEV-Team oft zu kurz, denn die einzelnen Teams haben wenig Möglichkeiten Spezialisten auszubilden. Genau die oben
beschriebenen Testspezialisierungen sind in vielen agilen Teams gerade deshalb selten bis gar nicht zu finden. Was brauchen wir also? Genau! Eine übergeordnete Instanz für die Koordination und den Austausch von TestKnow-how. Also doch der Testmanager? Nein!
Ich teile die Meinung, dass das klassische Testmanagement bzw. Managerrollen im Allgemeinen ausgedient haben. Nichtsdestotrotz sind viele der Management-Aufgaben auch in agilen Umfeldern weiterhin von Nöten. Nur sollten diese Aufgaben getrennt von disziplinarer oder sonstiger Vorgesetztenrolle sein. Noch schöner wäre es, wenn die betroffenen agilen Teams sich selbst organisieren könnten. Klingt nach einem Luftschloss?

Die QS-Gilde

Eine valide Methode, um eine übergeordnete Instanz zu schaffen und
gleichzeitig die Vorteile der Selbstorganisation zu haben, ist eine QS-Gildengründung.
Eine QS-Gilde ist eine freie Gruppe
von:

• gleichgestellten Mitarbeitern, die zwar fachlich/thematisch zusammengehören, aber
• aus verschiedenen Abteilungen oder Teams zusammenkommen, um
• sich gemeinsam Regeln zu geben und
• teamübergreifende Aufgaben zu koordinieren.

Darüber hinaus fördert sie den sozialen Zusammenhalt teamübergreifend. Eine Gilde ersetzt das klassische Testmanagement und wird zusammengestellt aus den Mitgliedern der ihr untergeordneten Teams.

Was benötigt eine Gilde?

• Im Grunde ist es nicht sehr kompliziert, eine Gilde benötigt nur vier einfache Dinge:
  Handlungsfreiheit und Unterstützung
  durch das Management, um Entscheidungen, Anschaffungen und Maßnahmen
  durchzusetzen.
• Aus jedem (agilen) Team jeweils möglichst ein Mitglied, um die Meinungen und Bedürfnisse aller Teams gleichermaßen zu berücksichtigen.
• Eine (selbst gewählte) Gildenführung als Repräsentant und Moderator, um u.a. die Treffen zu koordinieren, die Tagesordnung festzulegen oder zu moderieren. Ganz gleich, ob man die Rolle nun Testarchitekt, Testevangelist oder Testlead nennt, sie ist vergleichbar mit der Leitung eines Parlaments.
• Freie (freiwillige) Teilnahme der Mitglieder – ist die Grundvoraussetzung für echtes Interesse und das Voranbringen von Themen.

Wie trifft eine Gilde ihre Entscheidungen?

Ein Grundsatz der selbstorganisierten Entscheidungsfindung ist, dass nicht alle alles mitentscheiden müssen. Alle dürfen, niemand muss. Jede selbstorganisierte Gruppe, so auch eine Gilde, sollte ihre Entscheidungsregeln nach den sieben Level der Delegation ausrichten.

• Level 1 – Verkünden (Ich werde es Euch mitteilen): Der Entscheider trifft selbstständig eine Entscheidung und teilt diese dann allen Beteiligten mit.
  • Beispiel: Der Gildenlead legt Datum und Uhrzeit für das nächste Treffen fest.
• Level 2 – Verkaufen (Ich werde versuchen es Euch zu vermitteln/begründen): Der Entscheider trifft eine Entscheidung, aber begründet den Beteiligten die Entscheidung
  • Beispiel: Ein Gildenmitglied ist Experte für modellbasiertes Testen und empfiehlt ein Werkzeug. Die Auswahl des Werkzeugs begründet er für alle Beteiligten.
• Level 3 – Befragen (Ich frage Euch um Rat, um die beste Lösung zu finden): Der Entscheider erkundigt sich bei den Betroffenen und sammelt Informationen und Lösungsvorschläge, um darauf basierend eine Entscheidung zu treffen.
  • Beispiel: Die Gilde erfragt in den Teams Vorschläge für die besten Styleguides mit dem Ziel, daraus einen übergeordneten Styleguide abzuleiten.
• Level 4 – Einigen (Wir werden einen Konsens finden): Alle an der Entscheidung
  Beteiligten erarbeiten gemeinsam Vorschläge und einigen sich gemeinsam auf die beste Lösung.
  • Beispiel: Es werden drei Vorschläge für eine End2End-Testfabrik vorgestellt und per Fist2Five (s.u.) abgestimmt.
• Level 5 – Beraten (Ich werde Euch beraten, aber ihr entscheidet selbst): Die Entscheidung wird nicht in der Gilde getroffen, aber sie berät die Teams und hilft ggf.
  bei der Entscheidungsfindung.
  • Beispiel: Ein Team möchte den CI-Test auf eine zu erstellende Integrationstestumgebung ausweiten. Ein Gildenmitglied ist Architekt und Wissensträger und berät das Team. Das Team entscheidet selbst, welche Architektur es wählt.
• Level 6 – Erkundigen (Ich werde nach einer Entscheidung fragen): Die Gilde
  erkundigt sich bei den Teams, wie sie entschieden haben. Die Entscheidungsfreiheit liegt in den Teams. Die Gilde fragt lediglich Information ab.
  • Beispiel: Die Gilde möchte ein gemeinsames Anreisen zum QS-Barcamp in Hamburg planen. Dafür leitet sie den Link zur Webseite an die Teams weiter und erfragt, welche Teams oder Mitglieder dorthin reisen möchten.
• Level 7 – Delegieren (Ich werde es komplett delegieren): Viele Aufgaben können komplett delegiert werden. Die Gilde ist nicht mehr an der Durchführung oder dem
  Ergebnis beteiligt
  • Beispiel: Zur Parametrisierung von Testfällen muss eine Sammlung von Wertepaaren erstellt werden. Die Gilde überlässt es den beteiligten Teams, über die Form, Herleitung und Anwendung dieser Listen zu entscheiden. Das jeweilige Ergebnis wird nicht weiter geteilt.

Müssen sich immer alle einig sein?

Nein, im Gegenteil: Reibung und gegenteilige Meinungen sind wichtig. Nur darf in solchen Fällen nicht versucht werden, eine Konsententscheidung zu treffen. Viele beachten bei
Entscheidungsfindungen nicht den Unterschied zwischen Konsens- und
Konsententscheidungen. Dabei ist dieser in selbstorganisierten Strukturen essentiell:
Eine Konsensentscheidung ist einvernehmlich, alle sind dafür. Eine Konsententscheidung besteht wenn nichts mehr dagegen spricht. Es gibt verschiedene Möglichkeiten, eine Entscheidung herbeizuführen: Beispielsweise mit Pro/Contra-Abfragen. Diese Art von Abstimmung zielt auf einen Konsent in einem Umfeld, das viele Meinungen und Bedürfnisse
hat, ab. Das ist aber der falsche Weg, besser wäre es, eine Konsensentscheidung herbeizuführen. Zum Beispiel eine Trendentscheidung nach Fist2Five: Die Vorschläge werden dem Auditorium kurz vorgestellt. Für jeden Vorschlag wird eine Abstimmung durchgeführt. Hierfür fordert der Moderator von den Beteiligten einen „Fingerzeig” ihrer Zustimmung.
Die Ergebnisse werden wie folgt bewertet:

• 5 Finger: Ein hervorragender Vorschlag und ich werde helfen, ihn umsetzen.
• 4 Finger: Ein guter Vorschlag und ich bringe mich ein, ihn umzusetzen.
• 3 Finger: Ich bin nicht begeistert, aber kann mit dem Vorschlag leben.
• 2 Finger (Ich kann gehört werden): Ich habe noch Kleinigkeiten, die ich an dem Vorschlag ändern möchte.
• 1 Finger (Ich muss gehört werden): Ich habe noch größere Punkte zu diskutieren und an dem Vorschlag zu ändern. D.h. ich verpflichte mich, an einer Alternative mitzuarbeiten. (Dadurch wird eine potentielle Verweigerungshaltung in positive Mitarbeit umgelenkt.)
• Faust/ 0 Finger – Veto (Ich bin dagegen): Wenn der Vorschlag so umgesetzt wird, dann verlasse ich das Team, schlimmstenfalls die Firma. (Ein Veto genügt um einen Vorschlag zu entkräften.)

Der Vorschlag mit der höchsten Zustimmung wird jetzt versucht, so zu modifizieren, dass auch aus den Reihen der Abstimmenden mit der Faust, 1 Finger und 2 Finger eine etwas höhere Zustimmung erfolgt. Möglichkeiten wären beispielsweise, den Vorschlag probehalber anzuwenden, z.B. mit einer zeitlichen Befristung und der Zusage, nach Ablauf eine Retrospektive durchzuführen, um die Bedenken zu verifizieren und gegebenenfalls Nachbesserungen durchzuführen. Auf diese Art können die Meinungen der Beteiligten in die Vorschläge einfließen und jeder Einzelne muss keine vorschnelle Entscheidung treffen. In der Regel werden solche Ergebnisse besser von den Beteiligten mitgetragen. Damit sind auch die Vorgaben, die eine Gilde trifft, häufig in den Teams anerkannter.

Was bleibt noch?

Ist ja alles gut und schön, aber wo lassen wir jetzt unsere Testmanager? Die Expertise und das Organisationstalent eines erfahrenden Testmanagers sind goldrichtig aufgehoben in einer QSGilde. Entweder ist er übergreifend in beratender Funktion oder als Gildenlead tätig. Wer, wenn nicht unser Testmanager kann die End2End-Sicht am besten in die Gilde tragen? Auch der risikobasierende Ansatz eines QS-Managers ist wichtiger Input für die Priorisierung und Entscheidungsfindung einer Gilde. Ich glaube, dass es noch lange und vor allem viel zu tun gibt für die ehemaligen Testmanager!

Ich wünsche Euch viel Spaß mit Eurer Selbstorganisation und dem Gründen Eurer QS-Gilde.