Ein Schnack über Agile Teams und Qualitätssicherung
Samstagmorgen, Mathilde, Elise und Jakob treffen sich einmal im Monat zum gemeinsamen Frühstück im Café „Liebes Bisschen”, um sich bei Cappuccino und Croissants auszutauschen und über Gott und die Welt zu reden. Das charmante, wie ein Landhauswohnzimmer eingerichtete Café am Ottensener Spritzenplatz in Hamburg war eigentlich eine spitzen Tortenmanufaktur, weshalb es an den Nachmittagen besonders beliebt war. Normalerweise herrscht super Stimmung und allen gelingt es, endlich von der Arbeit abzuschalten. Aber heute ist irgendetwas anders. Mathilde wirkt etwas bedrückt und zerzupft eine Serviette nach der anderen. Jakob sieht ihr eine Weile lang zu, bis er das Gemetzel vor Mathildes Cappuccino nicht mehr aushält und sie fragt, was mit ihr los sei.
„Ach, ich bin gerade bei diesem Kunden, der die Softwareentwicklung agilisiert…”
Elise schmunzelt: „Lass mich raten, läuft nicht so, oder?”
Mathilde lacht, aber es ist eher ein ironisches Lachen: „Wo denkst du hin, Elli, läuft meeega…”, Mathilde seufzt.
„Komm, erzähl mal, wo der Schuh drückt!”, ermuntert sie Jakob und beugt sich zu ihr über den Tisch. „Naja, jetzt sind wir so weit, dass wir in einem skalierten Teilprojekt die gesamte Entwicklungsabteilung in agile Teams aufgeteilt haben. So, aber jetzt kommt‘s.…”, Mathilde zerstückelt eine weitere Serviette, „Könnt ihr euch vorstellen, dass dort die Entwickler die Qualitätssicherung übernehmen sollen?“
Jakob überlegt laut: „Das ist doch theoretisch ein guter Ansatz! Bei mir wurden Wasserfall-Tester dafür ins Team gesetzt und die wollen einfach nicht von ihren gewohnten Strukturen abweichen. Zudem schiebt das Team die Qualitätssicherung immer noch den Testern zu und sieht es nicht als gemeinsame Verantwortung.“
Mathilde erwidert kopfschüttelnd: „Ja gut, das ist auch nicht besser. Bei uns ist nur das Problem, dass die Entwickler gar keine Testing-Erfahrung mitbringen und Qualitätstreiber und -risiken gar nicht überblicken können. Ihnen fehlt das Fachwissen. Unsere Qualitätssicherung ist eine einzige Katastrophe.“
Elise zieht die Augenbrauen zusammen und schaut etwas verwundert. Nach einer kurzen Pause erzählt sie: „Also wir haben einen Tester in ein neues Scrum Team etabliert, der bereits ein agiles Mindset mitbringt. Das hat wunderbar funktioniert. Die anderen Mitarbeiter haben mitbekommen, wie gut es läuft und sind nun richtig motiviert, auch agil zu arbeiten.“
Mathilde überlegt: „Interessant. Wir sollten öfter darüber sprechen, anstatt uns über Klatsch und Tratsch lustig zu machen.” Die drei schauen sich ernst an, bevor sie dann ins Lachen ausbrechen.
Unsere Freunde beschreiben drei unterschiedliche Situationen, die die Autoren so oder so ähnlich schon einmal miterlebt haben. Jetzt der Clou: Alle drei Ansätze können funktionieren, denn im Zentrum dieser stehen die Mitarbeiter mit unterschiedlichen Rollen und Skillsets. Dabei sollte Folgendes beherzigt werden:
Das Rollenverständnis– egal für welche die Organisation sich entscheidet — muss klar definiert und transparent sein und sich stetig mit der Organisation weiterentwickeln.
Dies lässt sich auch noch mal genauer im Kapitel der Säule Rollen aus dem Originalbuch nachlesen (verfügbar auf Amazon). Das wichtigste hierbei ist, dass die Betroffenen ein gemeinsames Bild von den Rollen und damit verbundenen Aufgaben und Verantwortlichkeiten haben. Natürlich sind die Rollen nicht „in Stein gemeißelt“, sondern müssen sich mit der Zeit mitentwickeln. Dies kann nur funktionieren, wenn die Personalabteilung die entsprechende Flexibilität zulässt und ihre Prozesse dementsprechend aufstellt.
Das gesamte Team muss sowohl zu einem agilen als auch qualitätsgetriebenen Mindset befähigt werden.
In Buch 1 haben wir bereits das “ Agile Coaching Kompetenz Framework“ kennen gelernt. In diesem Punkt möchten wir das Zusammenspiel aus Personen mit Skills aus dem Bereich „Lean-agile Practitioner“ und aus dem Bereich „Technical Mastery“ (Technische Expertise) in Qualitätssicherung hervorheben. Damit das unter anderem in SAFe® erwähnte Built-in Quality Konzept funktionieren kann, reicht es nicht, dass einzelne Tester den Qualitätsaspekt in den Fokus rücken. Das ganze Team muss ein Grundverständnis dafür entwickeln. Hierbei spricht man auch häufig von „T-, Pi- oder sogar E-Shaped Skills“. Im Grunde genommen haben diese Konzepte gemeinsam, dass es darum geht, über ein breites Skillset in verschiedenen Bereichen zu verfügen und wenn möglich mehr als eine Hauptexpertise zu vertiefen. Das führt in crossfunktionalen Teams dazu, dass die Teammitglieder sich bei Ausfällen gegenseitig vertreten können. Dies reduziert „Bottlenecks“, ermöglicht eine flexiblere Planung und gleicht Schwankungen aus. Außerdem fördert es das Verständnis der Teammitglieder untereinander. Dies resultiert in weniger Missverständnisse und erhöht letztendlich die Geschwindigkeit und Innovationsfähigkeit des Teams.
Um das erreichen zu können, ist es notwendig, wie in Elises Beispiel, dass Tester in den Teams die Teammitglieder coachen. Zudem gibt es den Ansatz, temporäre System Teams aufzubauen, die Frameworks definieren und die Teams dazu befähigen, diese anzuwenden. Das kann beispielsweise ein Enablementteam sein, dass die Teams in der Anwendung und den Aufbau von Testautomatisierung sowie DevOps-Pipelines vorbereitet und schult. Trainingspläne können aber auch professionelle Vor-Ort- oder Online-Trainings, informelle Trainings, selbstorganisiertes Lernen sowie Mentoring einschließen (für mehr Informationen siehe auch The Life of Pi: Moving Beyond T-Shaped Skills for Agile Teams | Davisbase Consulting (solutionsiq.com)).
Selbstverständlich gilt das gleiche für das agile Mindset. Ohne ein agiles Grundverständnis wird das Entwicklungsteam nicht verstehen, wie wichtig die gemeinsame Verantwortung für Qualität ist und wie wichtig es ist, die Effektivität sowie Effizienz der Prozesse kontinuierlich zu verbessern. Typischerweise werden hierfür oft Agile Coaches sowie Scrum Master zu Rate gezogen.
Für beide Ansätze gilt, dass ein regelmäßiger Austausch unterschiedlichster Stakeholder elementar für die kontinuierliche Verbesserung der Kollaboration und des Qualitätsmanagements ist. Unterstützend wirken hier typische Zeremonien, wie das Scrum of Scrums oder die Community of Practice (CoP) (siehe Abb. 1).
Die CoP ist üblicherweise freiwillig und offen für jeden, der Interesse hat. Die Agenda entscheidet sich bei jedem Termin je nach Teilnehmer und Bedarf. Es kann vorkommen, dass mehrere CoPs eine Relation zur Qualitätssicherung haben. So haben wir schon Projekte erlebt, die zwischenzeitlich sowohl eine CoP für Qualitätssicherung als auch für DevOps und eine weitere speziell für Testautomatisierung hatte. Die CoP sollte in der Theorie ohne Moderation und große Planung funktionieren. Was in der Theorie ganz einfach klingt, ist in der Praxis erfahrungsgemäß ziemlich herausfordernd. Unserer Erfahrung nach kommt eine CoP insbesondere am Anfang nicht ohne Vorbereitung und geplantes Hosting aus. Zudem hängt die Effektivität extrem von den Teilnehmern ab. Diese müssen insbesondere in der frühen Phase der Transformation erst noch lernen, dass ihr Feedback für die gemeinsame Weiterentwicklung und Optimierung von Prozessen wertvoll ist. Als Moderator bietet es sich an, die Teilnehmer mit dem notwendigen Fingerspitzengefühl aus ihrer Komfortzone zu locken, sie beim Namen anzusprechen und konkret nach Input oder etwas Einfachem zu Fragen. Mögliche Themen, mit denen neuer Input herausgekitzelt werden kann, sind z.B. Fragen wie, wie der letzte Sprint lief und ob das Team in letzter Zeit irgendwelche Herausforderungen hatte. Es können auch Fragen gestellt werden, die auf das spezifische Vorgehen im jeweiligen Team abzielen. Dafür können konkrete Themen genannt werden, wie z.B. die Defekt-Kommunikation. Wir haben festgestellt, dass sich für die Starthilfe einer CoP für Quality-Engineering-Themen insbesondere Quality Coaches anbieten. Durch ihr Change-Management-Wissen bringen sie das nötige Fingerspitzengefühl und Moderationswissen sowie durch ihren Background in der QS auch das notwendige Fachwissen mit.
Als eine weitere sinnvolle Zeremonie für die Weiterentwicklung der QS hat sich das Scrum of Scrums herauskristallisiert. Scrum Master können hervorragend als Multiplikatoren fungieren und die Änderungen in den QS-Prozessen oder Good Practices an die Teams tragen. Das ist vor allem dann empfehlenswert, wenn das Produktentwicklungsvorhaben auf mehrere ARTs skaliert ist, nicht in jedem Team ein Vertreter der QS ist und/oder in der CoP für QS nicht jedes Team vertreten ist. Beim Scrum of Scrums kommen die Scrum Master aller Teams zusammen. Diese Zeremonie ist in der Regel verpflichtend. Häufig sind hier auch die Product Owner eingeladen und es findet ein teamübergreifender Austausch statt. Bei einer Skalierung auf mehrere ARTs sollten auch die Release Train Engineers (RTEs) mit eingebunden werden.
Je nach gewählten Zeremonien (die CoP und das Scrum of Scrums sind hier nur beispielhaft angeführt) werden hier unterschiedliche Stakeholder erreicht und involviert. Es sollte gezielt ausgewählt werden, welche Feedbacks und Veränderungen in welchen Zeremonien ausgetauscht werden. Zudem empfehlen wir eine Abstimmung zu Veränderungen aus anderen Bereichen, um keine widersprüchlichen Arbeitsweisen zu kommunizieren und die Mitglieder des Entwicklungsvorhabend nicht mit zu vielen Veränderungen auf einmal zu überfordern. Zauberwort ist hier ein gemeinsames abgestimmtes Change Management.
Experten werden benötigt, die die Prozesse zur Qualitätssicherung den neuen Rahmenbedingungen und der neuen Arbeitsweise anpassen.
Unabhängig von dem gewählten Rollen-Set-Ups ist es wichtig, dass besonders bei der Transformation dediziert daran gearbeitet wird, wie die QS unter den neuen Rahmenbedingungen sinnvoll funktionieren kann. Dabei hat sich bisher sehr gut bewährt, so früh wie möglich mit den theoretischen Überlegungen anzufangen und diese von vorneherein anzuwenden. So sind entsprechende Feedback-Mechanismen (z.B. die Vorstellung von Zwischenständen in Zeremonien wie z.B. die CoP) von großer Bedeutung und sollten eingeplant werden. In einer Produktentwicklung über ARTs haben wir einen eigenen Prozess etabliert, explizit um das Feedback zur vorherrschenden Teststrategie aufzunehmen, zu bewerten und einzuarbeiten. Bevor beispielsweise Änderungen an Teilen der Strategie an alle Teams ausgerollt werden, werden sie mit einzelnen Teams verprobt, um deren Feedback zu sammeln, den Prozess anzupassen und erst dann an die Masse zu kommunizieren. Sehr wichtig ist hierbei, die Prozesse nicht an der Realität vorbeizuplanen. Dafür sollte Input aus den Teams immer die Basis für die Prozessanpassung sein. Die Anpassungen kann dann über gemeinsame Co-Creation und Experimente früh umgesetzt werden, um Feedback zur kontinuierlichen Verbesserung zu sammeln.
Genauso wichtig ist es, eine nachvollziehbare klare Dokumentation und eine Kommunikationsstruktur zu etablieren. Diese stellt sicher, dass alle betroffenen Teams die Prozesse kennen, verstehen und „leben” können. Beispiele dafür folgen in unserem Beitrag zu den Testmethodiken. Bleibe gespannt. In den Folgebeiträgen kommen weitere Beispiele wie sich die Prozesse der Qualitätssicherung im Einzelnen in einer Qualitätstransformation verändern können und Mathilde, Elise, Jakob und Co. erzählen von weiteren Erlebnissen.
