Entwickler-Blog · 12.07.19

LeSS ist mehr

Als Product-Owner bei MACH bin ich für die beiden Scrumteams ECM1 und ECM2 verantwortlich. Beide Teams arbeiten im Wesentlichen an gleicher Fachlichkeit und an gleichem Code. Wie kann ich die Zusammenarbeit der beiden Teams gestalten? Das Skalierungsframework "LeSS" gibt eine Antwort. Ich schreibe über meine Praxiserfahrungen.

Scrum: Das Vorgehen

Die Grundgedanken von Scrum sind darauf ausgerichtet, mit einem Scrumteam an einem Stück Software zu bauen: Ich plane mit dem Team in kurzen Zyklen und das Team setzt den Plan in kurzen Zyklen um. So haben wir mit der MACH E-Verwaltung begonnen – so weit, so gut.

Aber was tun, wenn der Bedarf nach neuer Software immer weiter wächst? Reaktion Nr. 1 ist: Mehr Leute! Gesagt, getan, das Management geht mit und es kommen immer mehr Kolleginnen und Kollegen ins Team. Nach der Einarbeitungsphase landen immer mehr Stories am Sprint-Board. Prima!

Prima? Nein!

Irgendwann wird es plötzlich "ungemütlich": Die Liste der Stories im Sprint wird immer länger, der Sprint wird unübersichtlich, die Daily Meetings benötigen eine halbe Stunde und mehr, die Teammitglieder können sich spätestens in der zweiten Sprintwoche nicht mehr an alle Details erinnern (es sind einfach zu viele Stories), der Flow des Teams gerät ins Stocken. Die erhoffte Erhöhung der Team-Geschwindigkeit bleibt aus.

Was ist los?

Auf diese Frage kann es diverse Antworten geben. Aber in dem oben beschriebenen Szenario aus meiner Praxis als Product-Owner war die Antwort ziemlich eindeutig:

"Das Team ist zu groß! Der Nutzen des kleinen Teams, das in kurzen Zyklen Hand in Hand Ergebnisse erzielt, kann sich eben ab einer gewissen Teamgröße nicht mehr entfalten."

Jan-Hendrik Krause Bei MACH bin ich schon seit über 18 Jahren. Seit Mitte 2015 arbeite ich als Product-Owner für unsere E-Akten-Lösung MACH E-Verwaltung. An meiner Arbeit als Product-Owner gefallen mir die vielfältigen Möglichkeiten, sowohl die Software als auch das Unternehmen zu gestalten. Besonders spannend finde ich, wenn im iterativen Scrum-Prozess aus einer ersten Formulierung "Als ... möchte ich ..., um das Ziel ... zu erreichen" über viele Stufen des Gesprächs mit unterschiedlichen Personengruppen hinweg eine Lösung entsteht, über die mir der Kunde in der Videokonferenz "Das ist gut!" bestätigt.

Was ist der Ausweg?

Wir machen aus einem Scrumteam zwei. Diese banal klingende Lösung wirft allerdings in der Praxis einige Fragen auf:

  • Wer übernimmt welche Rolle?
  • Wie teilen wir das Team auf? Wer nimmt welche Wissens-Schwerpunkte mit?
  • Wie verteilen wir die Stories auf die Teams?
  • Und vor allem: Wie sorgen wir dafür, dass die beiden Teams nicht zu wenig und nicht zu viel voneinander wissen, um sich bei Bedarf angemessen zu synchronisieren?

In dieser Situation machte mich einer unserer Agile Coaches auf das Scrum-Rahmenwerk LeSS aufmerksam. LeSS steht für "Large Scale Scrum" und bietet einen Rahmen, in dem sich (im Prinzip beliebig viele) Scrumteams gemeinsam bewegen und genau die richtige Menge an "Kontaktfläche" haben.

Kurz zusammengefasst heißt Arbeiten in LeSS zunächst, dass zwei oder mehr Scrumteams unabhängig voneinander nach Scrum arbeiten und ihre eigene organisatorische Infrastruktur nutzen.

"Um die notwendige Synchronisation zu erreichen, haben die Teams einige der Scrum-Meetings gemeinsam."

Jan-Hendrik Krause Bei MACH bin ich schon seit über 18 Jahren. Seit Mitte 2015 arbeite ich als Product-Owner für unsere E-Akten-Lösung MACH E-Verwaltung. An meiner Arbeit als Product-Owner gefallen mir die vielfältigen Möglichkeiten, sowohl die Software als auch das Unternehmen zu gestalten. Besonders spannend finde ich, wenn im iterativen Scrum-Prozess aus einer ersten Formulierung "Als ... möchte ich ..., um das Ziel ... zu erreichen" über viele Stufen des Gesprächs mit unterschiedlichen Personengruppen hinweg eine Lösung entsteht, über die mir der Kunde in der Videokonferenz "Das ist gut!" bestätigt.

Large Scale Scrum: LeSS

Die Eckpunkte des Scrum-Rahmenwerks:

  • Gemeinsam mit allen Teams finden das Refinement-Meeting, der erste Teil der Sprintplanung sowie der Review der Sprint-Ergebnisse statt. Damit sind alle Teammitglieder über alle Entwicklungsvorhaben und alle Ergebnisse ausreichend informiert.
  • Der Product-Owner steuert beide Teams: Es gibt ein gemeinsames Product-Backlog mit den Entwicklungsvorhaben für das Produkt. Im Refinement-Meeting stellt der Product-Owner beiden Teams die neuen Vorhaben vor, in der Sprintplanung verteilen alle gemeinsam die Stories auf die Teams, erkennen dabei (hoffentlich) Abhängigkeiten zwischen den Team-Sprints und reagieren frühzeitig.
  • Jedes Team hat seine eigenen Stories, sein eigenes Sprint-Board und sein eigenes Daily Meeting, seinen eigenen zweiten Teil der Sprintplanung (technische Detailplanung der einzelnen Stories) und seine eigene Retrospective (Rückblick auf die Zusammenarbeit des Teams im Sprint). Die hier verhandelten Dinge sind in der Regel teamintern und müssen nicht mit dem "Rest der Welt" geteilt werden.

 

Meine Erfahrungen aus der Praxis

Organisatorische Änderungen

Eine Umstellung auf LeSS ist recht einfach, die organisatorischen Änderungen halten sich in Grenzen: Ein wenig Kalender-Arbeit, um Daily Meeting und Retrospective zu verdoppeln und so zu terminieren, dass der Product-Owner in beiden Teams anwesend sein kann. Zwei Sprintboards statt einem Sprintboard. Im Idealfall getrennte Meeting-Bereiche, um Störungen minimal zu halten. Und dann: Losgehen, Erfahrungen sammeln, Richtung anpassen. Scrum eben.

Persönliche Erfahrungen

Für mich als Product-Owner hat sich das Leben mit dem Team ein wenig verändert: Einige Meetings mehr im Kalender und damit weniger Zeit für meine zweite Leidenschaft - das Requirements Engineering - also das Aufarbeiten der Stories, sodass die Scrumteams mit ihrer Arbeit beginnen können. Nach und nach übernehmen diese Aufgabe Kolleginnen und Kollegen, die extra dafür ins Team gekommen sind.

Ein Tipp zum Schluss

Nimm das Team mit in den Aufteilungsprozess, denn das ist kein Selbstläufer. Gemeinsam die Notwendigkeit der Aufteilung in mehrere Teams erkennen, die Varianten der Aufteilung diskutieren (Wer geht in welches Team?), in gemeinsamen Retros auf den Umstellungsprozess schauen - das alles ist notwendig, um die Menschen mitzunehmen.

Karriere bei MACH

MACHer*innen gesucht

Werde auch du MACHer*in und gestalte gemeinsam mit uns die digitale Zukunft der öffentlichen Verwaltung.
Unsere offenen Stellen findest du auf unserer Karriere-Seite.
Entwickler-Blog
#Performance

Das n+1 Problem

Dr. Jonathan Moebius kümmert sich bei MACH u. a. um die Analyse und Behebung von Performance-Problemen. Was es mit dem n+1 Problem auf sich hat, erklärt er in diesem Artikel.