Mit Lernstorys im Backlog zum Erfolg

Agiles Lernen in Scrum Teams

Im Gespräch über Scrum Teams entsteht manchmal der Eindruck, viele haben eine Gruppe Avengers Super Heroes vor Augen. Die erlebte Realität sieht dann meist anders aus, gerade wenn man die Mitglieder von Scrum Teams fragt. Doch beides ist wichtig: Ein Idealbild gibt Orientierung und ein ehrliches Bild von der Realität weist den Weg zu einer positiven Entwicklung – sofern man die Stärken im Team fokussiert. In unserem Beitrag möchten wir anhand eines praktischen Beispiels zeigen, wie Lernen mithilfe von Lernstorys ein junges Scrum Team zum erfolgreichen Team machte.

Einfach untrennbar: Agilität, Qualität und Lernen

Wenn es um agile Softwareentwicklung geht, ist Lernen eines der wichtigsten und wertigsten Themen – u. a. gut sichtbar in den beiden Schlagworten “inspect and adapt”. Da wir QualityMinds als IT-Dienstleister mit dem Schwerpunkt Softwarequalität sehr viele unterschiedliche Projekte, Teams und Transformationen begleiten dürfen, sehen wir diese Notwendigkeit tagtäglich.

Wer Softwarequalität umfassend begreift, erkennt, dass Qualität mit der Haltung, den Kenntnissen und Fertigkeiten der Menschen beginnt, die sie planen, entwickeln und testen. Weder lässt sich Qualität kurz vor dem Roll Out in ein Produkt “hineintesten”, noch fällt ein “High Performing Team” vom Himmel. Aus unserer Sicht ist Lernen in der agilen Welt ein wesentlicher Erfolgsfaktor. Einen Einblick in unseren Ansatz des agilen Lernens und des agilen Lerncoachings auf einer individuellen Ebene haben wir vergangenes Jahr hier im t2informatik Blog gegeben. Doch Lernen funktioniert auch sehr gut in Scrum Teams.

Die Challenge: Team Zero

In agilen Teams gilt es, durch regelmäßige Rückkopplungsschleifen das Lernen anzustoßen, um z. B. den Einsatz agiler Praktiken schrittweise anzupassen. Transformations- und Change-Prozesse sind unserer Erfahrung nach immer und vor allem Lernprozesse. Am besten ist es, wenn man Fehler als Lernchancen begreift – als Chancen, sich, das Team und das Produkt weiterzuentwickeln. So viel zur Theorie.

In der Praxis ist allerdings kein Scrum Team von Anfang an eines dieser High Performing Teams, die wir oft in Blogartikeln oder in der Literatur als Idealbild vorgestellt bekommen. Das ist völlig in Ordnung, muss aber berücksichtigt werden, um überzogene Erwartungen und Frustrationen zu vermeiden.

Diese Erfahrungen konnten wir vor einiger Zeit in der Unterstützung eines Kundenteams sammeln. Wir wollen es hier “Team Zero” nennen, denn es sollte das erste Team im Unternehmen werden, das agil nach Scrum arbeitet. Es wurde zu diesem Zweck neu zusammengesetzt und mit der Aufgabe betraut, einen Prototypen für die Testautomatisierung einer neuen Anwendung zu bauen, die parallel in anderen, noch klassischen Teams entwickelt wurde.

Die Zusammenstellung von Team Zero war heterogen: Ein Teil war sehr jung und hatte nur wenig Erfahrung im Bereich der Softwareentwicklung. Der andere Teil verfügte zwar über langjährige Erfahrung in der Softwareentwicklung, war aber im Thema Testautomatisierung unerfahren. Von unserer Seite waren ein Entwickler, eine Scrum Masterin und ein Product Owner mit an Bord.

Das Management gab dem Team und uns, als externe Unterstützung, viel Freiraum, um in ein gemeinsames Arbeiten zu finden. Doch schon die ersten Sprints waren nicht frei von Herausforderungen. Immer wieder kam es vor, dass Routine-Tasks aufgrund fehlender Erfahrung zu Showstoppern wurden. Dann wieder wurden User Storys, die dem Team im Planning harmlos erschienen, aufgrund mangelnder Expertise völlig falsch geschätzt, so dass das Sprintziel nicht erreicht wurde.

Ähnliches hatten wir in der Begleitung agiler Transformationen schon zuvor erlebt. Doch bei Team Zero stellte sich zusätzlich eine kontraproduktive Dynamik ein, die als Social Loafing oder auch Ringelmann-Effekt bekannt ist: Anstatt dass das Team gemeinsam und miteinander Aufgaben bewältigte und sich gegenseitig aushalf, wo es notwendig gewesen wäre, begannen einzelne sich zurückzunehmen und sich in eine Komfortzone der Nicht-Zuständigkeit zurückzuziehen: “Das kann ich nicht, also muss ich es auch nicht bearbeiten!”.

Im Team wirkt Social Loafing negativ verstärkend. Damit drohte nicht nur die Umsetzung des Prototyps zu misslingen, sondern auch die Pilotierung agiler Zusammenarbeit. Es war also höchste Zeit, den Blick darauf zu richten, was die Ursachen waren und was getan werden musste.

Inspect and Adapt: Learning!

Einer der vielen Vorteile des Scrum Frameworks ist bekanntlich, dass Probleme schnell sichtbar gemacht werden können – so auch in Team Zero. Bereits nach zwei Retrospektiven war klar, dass das Team als Ganzes, aber auch die meisten Mitglieder persönlich, noch viel lernen musste: Hauptsächlich galt es, Fachlichkeit und entsprechende Routinen aufzubauen. Es brauchte daneben aber auch soziale Kompetenzen für die agile Teamarbeit sowie Sprachkenntnisse, da die Arbeitssprache wegen der internationalen Besetzung Englisch war.

Aufgrund unserer Erfahrung mit agilem Lernen konnten wir hier schnell eine Lösung erarbeiten, die das Lernen fest im Sprintzyklus von Team Zero verankerte. Wir griffen bei der Lösungserarbeitung einerseits auf im Lernkontext bewährte agile Prinzipien zurück – so z. B. das fünfte Prinzip des agilen Manifests (“Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.”). Lernen sollte also kollaborativ und soweit wie möglich selbstorganisiert stattfinden.

Andererseits griffen wir auf Ergebnisse der Lehr-Lern-Forschung und Organisationsentwicklung zurück, wie etwa die sieben Dimensionen einer lernenden Organisation (u.a. „continious learning“ oder „Empowerment“, Marsick & Watkins: Demonstrating the Value of an Organization’s Learning Culture – The Dimensions of the Learning Organization Questionnaire. ADHR 1/2003). Lernen sollte in einem lernfreundlichen und fördernden Ermöglichungsraum stattfinden, idealerweise in die tägliche Arbeit des Teams integriert.

Die Lösung: mit Lernstorys Wert schöpfen

Der Kerngedanke bei der Umsetzung war, den Lernbedarf in Team Zero so zu handhaben, wie in manchen Teams mit der “technischen Schuld” einer Anwendung umgegangen wird.

Mit diesem Ausdruck wird der zusätzliche und im Nachhinein anfallende Aufwand bezeichnet, der für die Verbesserung sehr schnell und handwerklich schlecht geschriebener Software anfällt. Die Beseitigung technischer Schuld ist nicht unmittelbar produktiv, denn sie führt nicht direkt zu einem neuen Element funktionierender Software. Dem Management und/oder Fachabteilungen ist sie daher manchmal eher schwer zu vermitteln. Doch indirekt und mittel-, ggf. erst langfristig haben diese Verbesserungen entscheidenden Einfluss auf die Wertschöpfung.

Auch Lernaufwand bringt nicht unmittelbar ein neues Inkrement funktionierender Software hervor, schafft aber mittel-/langfristig einen mess- und sichtbaren Mehrwert – sowohl für das Team als auch für das Produkt. Wichtig ist beim Lernen genau wie bei der Verbesserung an Produkten, dass es stattfindet und Ressourcen (vor allem Zeit) dafür bereitgestellt werden. Glücklicherweise haben die verantwortlichen Führungskräfte im Fall von Team Zero das erkannt und hier den nötigen Freiraum gegeben. So konnten wir mit folgenden fünf Aspekten eine treffende Lösung verwirklichen:

1. Lernen zum priorisierten Thema machen: Der Aspekt Lernen wurde offen mit dem gesamten Team Zero sowie den Abteilungsverantwortlichen angesprochen und eine Team-Lernvision erstellt. Aus ihr ergaben sich übergreifende Lernthemen und Aufgaben spezifische Lernfelder (z.B. die sprachliche Sicherheit oder die Fachlichkeit im Bereich Testautomatisierung).
2. Lernbedarf im Backlog abbilden und berücksichtigen: Da Lernen ebenfalls durch die Aspekte Zeit, Komplexität und Risiko charakterisiert ist, haben wir im Product Backlog Epics zum “Team-Improvement” angelegt. Denn was im Backlog steht, wird regelmäßig in den Blick genommen.
3. Lernziele als “Team-Lernstorys” einplanen: Im Gespräch mit dem Team (z. B. in den Reviews) aber auch in Einzelabsprache haben wir von da an genau untersucht, ob und welche Kenntnisse / Kompetenzen in Team Zero nötig, aber noch nicht vorhanden waren. Aus den Beobachtungen haben wir anschließend Lernziele abgeleitet und sie als “Team-Lernstorys” im Planning – genau wie User Storys – in das Sprint Backlog aufgenommen (z. B. Kenntnisse über Schnittstellen-Testing).
4. Konkretisieren und Umsetzen in “Individual-Lernstorys”: Darüber hinaus haben sich bei einzelnen Teammitgliedern zusätzlich individuelle Lernziele gezeigt. Im persönlichen Gespräch mit der Scrum Masterin wurden dann auch individuelle Lernziele als Individual-Lernstorys präzisiert und die Umsetzung geplant.
5. Kollaboratives Lernen im Sprint: Selbstorganisiertes, kollaboratives Lernen wurde zum Schlüssel bei der Umsetzung der Lernstorys. Natürlich gab es auch Selbstlernphasen, in denen Teammitglieder für sich recherchiert, gelesen und ausprobiert haben. Aber die Devise war stets: Gemeinsam bringen wir uns weiter. Damit dies erfolgreich sein konnte, wurden Team-Lernstorys ganz selbstverständlich in der Sprint-Arbeitszeit bearbeitet.

Die Überlegung hinter Lernstorys in der beschriebenen Form ist recht einfach: Wer sich Wertschöpfung zum Ziel setzt, muss sich auch fragen, wer aus welcher Quelle diesen Wert schöpfen soll. Lernstorys sind ein Investment in Menschen und ihre Fähigkeiten. Bringen Lernstorys dann automatisch bessere Produkte? Nicht immer! Bei richtiger Umsetzung haben sie aber in jedem Fall ein großes Potenzial dazu. Und umgekehrt war und ist es keine Lösung, nicht ins Lernen zu investieren und dann zu erwarten, dass Teams wie Team Zero sich von selbst in ein High Performing Team verwandeln.

Die praktische Umsetzung: ACC, DoD, Abnahme und Lerncoaching

Der Einsatz von Lernstorys warf auch praktische Fragen auf, wie z. B.: Wer formuliert Lernstorys? Wann sind sie zufriedenstellend bearbeitet? Wer nimmt sie ab? Bei der Beantwortung dieser Fragen war hilfreich, dass wir bei QualityMinds sowohl auf langjährige Erfahrung in der agilen Softwareentwicklung als auch auf die Expertise in der Lehr-Lern-Forschung zurückgreifen können.

Der Impuls zum agilen Lernen in Team Zero ging von unserer Scrum Masterin aus, die über Erfahrung in der Formulierung von Lernzielen verfügt. Sie überzeugte nicht nur den Product Owner von dem neuen Ansatz, sondern formulierte dann auch jeweils die Lernstorys für den nächsten Sprint. Der Product Owner las diese kritisch gegen und nahm sie anschließend ins Product Backlog auf.

Dem Product Owner kam also eine wichtige Korrektivfunktion zu: Er prüfte die Sinnhaftigkeit, Notwendigkeit und den Umfang der Lernstorys und er priorisierte sie auch im Verhältnis zu den Backlog Items. Besonders wichtig waren in diesem Zusammenhang der Austausch zwischen Scrum Masterin und Product Owner. Hier klärte sich, warum und in welchem Umfang Lernaufwand bestand und wie dieser mit weiteren Items oder der Arbeit im Team verknüpft war. Zunächst stand die Überlegung im Raum, ein Dual Track Board mit einer Lane für User und einer für Lernstorys aufzusetzen. Doch wegen der Übersichtlichkeit und vor allem einer klaren Priorisierung entschieden wir uns dagegen. Der Scrum Masterin wiederum übernahm zusätzlich Facetten eines agilen Lerncoachs, der Teammitglieder auf ihrer Lernreise begleitet.

Für jede Lernstory definierte sie – ähnlich wie in User Storys – Akzeptanzkriterien, die im Einzelfall fachlich mit Experten abgestimmt wurden. Diese Kriterien hatten die Funktion, einerseits den Lernenden Orientierung im Lernprozess zu geben, andererseits beobachtbare Kriterien zu benennen, an denen eine erfolgreiche Bearbeitung sichtbar wurde: z.B. “Ich kann die Vorteile von API-Tests erklären.”.

Mit Team Zero wurde zudem eine Definition of Done für Team-Lernstorys entwickelt, die für alle verbindlich war und in der die Nachhaltigkeit des Erarbeiteten eine große Rolle spielte. So war z. B. ein essenzieller Bestandteil der DoD, wichtige Erkenntnisse im Team zu diskutieren und anschließend in einem Wiki festzuhalten.

Team-Lernstorys wurden im Planning genau wie User Storys geschätzt und in diesem Zuge auch gleich die Zuständigkeit geklärt (da ja manche Lernstorys nur einzelne Teammitglieder betrafen).

Das Review einer Lernstory erfolgte auf unterschiedliche Weise z. B. in Form von einer Aufbereitung als kleine Übersicht für alle anderen Teammitglieder oder in Form kurzer Impulsvorträge. Wichtig war hier, das Gelernte sichtbar und für das Team insgesamt nutzbar zu machen.

Ein Erfolg: Social Learning statt Social Loafing

Erfolge und Hindernisse im Lernen reflektierte Team Zero intensiv in den Retrospektiven. So wuchs sehr schnell die Selbstentwicklungs- und Lernkompetenz im Team, die metakognitiven Fähigkeiten und die Motivation bei jedem Teammitglied. Und das war vermutlich der wichtigste Erfolg, der sich durch die Einführung des agilen Lernens einstellte. Denn die positive Erfahrung der individuellen, wie auch der kollektiven Wirksamkeit im Lernen wurde zu einem universellen Erfolgsrezept im Umgang mit neuen Herausforderungen.

Auch wenn am Anfang viel Reibung und lange Diskussionen standen: Bereits nach drei bis vier Wochen wurden greifbare Lernerfolge erzielt. Und am Ende der Pilotierung war der Prototyp zur Testautomatisierung fertig gestellt.

Erfolgsfaktoren für die Arbeit mit Lernstorys in Scrum Teams

Damit das Lernen in einem Scrum Team funktionieren kann, müssen bestimmte Rahmenbedingungen gegeben sein und Stakeholder das Vorhaben unterstützen.

• Die Führungsetage: Sie muss erkennen, dass Lernen und die Weiterentwicklung des Teams gleichwertig ist mit der Weiterentwicklung des Produkts. Die Bereitstellung von Ressourcen, das Vertrauen in die Mitarbeitenden und eine positive Fehlerkultur sind hier unabdingbar.
• Das Team: Es muss offen für Veränderungen sein und das Thema Lernen aktiv in die eigene Arbeit integrieren. Das Eingeständnis, etwas (noch) nicht zu können, sollte im geschützten Rahmen des Teams frei geäußert werden können. Ein gemeinsames Verständnis, was Teamverantwortung und Ziel betrifft, sind eine Grundvoraussetzung.
• Der Product Owner: Er muss erkennen, dass die Wertschöpfung im Team (= Lernen) auch direkt eine Wertschöpfung für das Produkt darstellt. Die Arbeit mit Lernstorys kann gerade bei jungen und weniger erfahrenen Teams ein wichtiges Instrument des Product Owner sein, diesen Aspekt von Scrum zu veranschaulichen. Daher sollte der Product Owner offen für die vorbereitende Arbeit an Lernstorys und für ihre gleichwertige Platzierung im Backlog sein. Er muss zugunsten der Teamentwicklung ggf. kleinere Inkremente am Ende des Sprints akzeptieren.
• Der Scrum Master: Er muss auf Augenhöhe mit dem Product Owner sein und auf seine Einschätzung vertrauen. Gleichzeitig sollte er aber das Team und den Product Owner im positiven Sinne herausfordern. Zudem muss er die Bedeutung und den Mehrwert von sozialem Lernen für das Team erkennen. Es hilft, wenn der Scrum Master mit dem Thema Lernen vertraut ist, z. B. durch die Ausbildung zum agilen Lerncoach. Er unterstützt das Team proaktiv beim Aufbau einer Lernkultur, bei der Formulierung von Lernstorys/-zielen und in der Umsetzung (z. B. durch eine geeignete DoD oder die Reflexion in den Retros).

Auch wenn man mit Lernstorys ein Scrum Team nicht über Nacht in ein Avengers-Team verwandeln kann, so war es doch ein wichtiger und entscheidender Schritt auf dem Weg zum Erfolg. Die Mitglieder von Team Zero wurden schließlich zu Pionieren und Multiplikatoren in Sachen Agilität, Scrum und Lernen im eigenen Unternehmen. Sie haben sich auf unterschiedliche Teams verteilt, die nun ihrerseits begannen, nach Scrum zu arbeiten.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Wenn Sie mehr über QualityMinds und den Lernansatz erfahren möchten, oder sich mit den Autorinnen Eva Dirr-Bubik und Dr. Vera Gehlen-Baum oder dem Autor Dr. Manuel Illi über den Erfahrungsbericht austauschen möchten, können Sie gerne unter https://qualityminds.com/de/qm-portfolio/quality-learning/ Kontakt aufnehmen.

Von QualityMinds finden Sie im t2informatik Blog weitere Beiträge:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.