Mit LeSS zum Erfolg: Ist es das Richtige für Dein Projekt?

In der dynamischen Welt der Softwareentwicklung, in der Komplexität und Ungewissheit allgegenwärtig sind, stehen Unternehmen vor einer entscheidenden Herausforderung: Wie führen sie ihre Projekte zum Erfolg?

Agile Methoden werden als Kompass eingesetzt, um Teams durch turbulente Gewässer zu führen.

In diesem Artikel teilen wir unsere Erfahrungen mit Large-Scale Scrum (LeSS) in einem Kundenprojekt. Wir zeigen die Herausforderungen, denen wir begegnet sind und wie wir sie gemeistert haben. Bevor wir in die Details gehen, möchten wir ein gutes Verständnis von LeSS (Large-Scale Scrum) entwickeln und seine zusätzlichen Funktionen im Vergleich zu traditionellem Scrum erkunden.

Was ist LeSS?

LeSS (Large Scale Scrum) ist ein agiles Framework für die Verwaltung mehrerer Scrum-Teams[1], die gemeinsam an einem Produkt arbeiten. Ziel von LeSS ist es, die Anwendung der Scrum-Prinzipien in großen Unternehmen durch die Verwendung von definierten Regeln und Leitfäden zu vereinfachen[2]. Je nach Unternehmensstruktur können in einem Unternehmen zwei Arten von LeSS umgesetzt werden[3]:

Basic LeSS: mit 2 bis 8 Teams
LeSS Huge: mit mehr als 8 Teams

Diese Teams haben die Aufgabe, in Zusammenarbeit mit anderen Teams qualitativ hochwertige Produkte zu erstellen.

LeSS vs Scrum

LeSS hat immer noch viele der Praktiken von One-Team Scrum. Die folgenden Elemente sind auch in LeSS[4] zu finden:

Produkt-Backlog
Product Owner
Eine Definition of Done für alle Teams
Ein potenziell auslieferbares Produktinkrement am Ende jedes Sprints.
Es gibt mehrere Teams, die aber alle als ein Scrum-Team zusammenarbeiten
Alle Teams arbeiten gleichzeitig im gleichen Sprint-Rhythmus

Was bei LeSS anders ist, sind folgenden Punkte[5]:

Im Gegensatz zu einem Sprint Planning wie bei One Team Scrum gibt es bei LeSS zwei Sprint Plannings. Im ersten Sprint Planning arbeitet der Product Owner mit allen Teammitgliedern zusammen, um Entscheidungen über die Verteilung der Product Backlog Items zu treffen (hier wird das, „Was“ besprochen) und das zweite wird dann in den Teams durchgeführt, wo das „Wie“ besprochen wird. Das zweite Sprint Planning und das Daily Scrum werden von jedem Team unabhängig voneinander durchgeführt und können manchmal zwei oder mehr Teams zu Lernzwecken einbeziehen. Ein Mitglied von Team A kann das Daily Scrum von Team B beobachten, um den Informationsaustausch zu verbessern.
Bei LeSS gibt es ein optionales und kurzes Overall Product Backlog Refinement (PBR) mit einem Product Owner und Vertretern aus allen Teams. Ziel ist es, die Items für das nächste ausführliche Single Team PBR auszuwählen. Das Overall PBR bietet die Möglichkeit, die Abstimmung zwischen dem Product Owner und allen Teams zu erhöhen. Das Single Team PBR ist analog zu dem One Team Scrum PBR. Bei LeSS gibt es jedoch auch die Möglichkeit eines Multi Team PBR. Hierbei sind zwei oder mehr Teams anwesend, um mehr Wissensaustausch, mehr Verständnis und Transparenz zwischen den Teams zu erzielen.
Das Sprint Review ist analog zum Scrum Sprint Review, jedoch mit mehreren Teams. Für die Phase der Überprüfung des Produktinkrements wird ein Review Bazaar durchgeführt, bei dem verschiedene Teams ihre Ergebnisse an verschiedenen Orten präsentieren und jeder Interessierte die Ergebnisse sehen kann.
Ein weiteres Meeting, das nicht Teil des One-Team-Scrum ist, ist die Overall Retrospective. Es umfasst den Product Owner, den Scrum Master und rotierende Vertreter aus jedem Team. Hier geht es darum, die Verbesserungen am Gesamtsystem zu erkunden.

LeSS in einem Kundenprojekt

Eines unserer Kundenprojekte zur Entwicklung eines E-Commerce-Shops, in dem wir als IT-Designer eingesetzt waren, war ursprünglich nach dem Scrum-Framework strukturiert. Es bestand aus einem Feature Team, das aus Entwicklern, IT-Designern und UX-Designern zusammengesetzt war. Da es nur ein Team gab, hatten die IT-Designer:innen eine gewisse Flexibilität bei ihrer Arbeit. Das Projekt wurde dann nach der agilen Methode LeSS umstrukturiert, wobei sie mehrere Feature Teams bildeten. Jedes Feature-Team setzte sich aus Entwickler:innen, UX/UI-Designer:innen, Tester:innen und IT-Designer:innen zusammen.

Während des Overall Refinement wählten Vertreter der Feature Teams (IT-Designer:innen und einige Entwickler:innen) aus, welche User Stories für die nächste Refinement Phase priorisiert werden würden.

Die nächste Refinement Phase fand parallel in verschiedenen virtuellen Räumen statt. Dies war mit Hilfe des Tools Teemyco[6] möglich. Jeder virtuelle Raum bestand aus mindestens zwei, aber auch mehr Teams zusammen. Die priorisierten User Stories wurden beliebig auf die virtuellen Räume verteilt.

Während des Sprint Planning Meetings waren nur die Vertreter der einzelnen Teams anwesend und bei den Sprint Reviews treffen sich einige Entwickler:innen oder Mitglieder der Teams, um ihre Fortschritte zu präsentieren.

Herausforderungen

Diese Umstrukturierung führte zu verschiedenen Herausforderungen für das Team:

Die Projektübersicht war für einige Teammitglieder nicht mehr klar: Da LeSS auf dem Prinzip beruht, dass jeder alles tun kann, mussten die Teammitglieder ein wenig von jedem Thema bearbeiten. Sie konnten nicht an einem Thema von Anfang bis Ende arbeiten, was dazu führte, dass sie den Überblick über operative Themen und Prioritäten verloren.

Wissensmanagement, Kommunikations- und Koordinationsprobleme zwischen den Teams: Etwa zwei bis vier Refinement fanden parallel in virtuellen Räumen statt, daher waren die Experten und Expertinnen für bestimmte Themen oft nicht dort anwesend, wo sie gebraucht wurden. Die IT-Designer:innen, die für die Beschreibung der User Stories verantwortlich waren, wurden einem festen Feature-Team zugeordnet und dieses Team musste ihnen in die virtuellen Räume folgen, in denen die User Story präsentiert wurde. Die Themen der User Stories entsprachen jedoch oft weder dem Fachwissen ihres Feature-Teams noch dem des im virtuellen Raum anwesenden Teams. Dies geschah, da die Themen nicht entsprechend dem Fachwissen in den virtuellen Räumen geteilt wurden. Dies führte zu Kommunikationsproblemen in den Feature-Teams und das Refinement verlief oft sehr langsam und schweigsam.

Umstrukturierung der Teams

Um die Arbeitsbedingungen im Projekt zu verbessern, wurde eine Umstrukturierung durchgeführt, durch die UX/UI- und IT-Designer:innen aufgrund ihrer Rollen unabhängig von den Feature-Teams im Projekt arbeiten mussten. Dies ist wichtig, da der oder die UX/UI-Designer:in einen Überblick über die User Journey haben muss und die IT-Designer:innen unabhängig von den Feature-Teams an den verschiedenen Themen arbeiten können.

Jedem Feature-Team wurde ein bestimmter Abschnitt der Shop User Journey zugewiesen. Z. B.: Team A kümmert sich um alle Funktionen rund um den Warenkorb und den Check-out, Team B um die Produktdetailseiten usw. Jeder Abschnitt aus der User Journey hat eine Reihe von Epics, an denen die Feature-Teams arbeiten mussten. Ein oder eine IT-Designer:in war dann für ein Epic verantwortlich und arbeitete daran in Zusammenarbeit mit den Business-Analysten. Die Refinements fanden in den einzelnen Feature Teams statt und bei Bedarf, wenn z. B. ein oder mehr Feature Teams an sich überschneidenden Themen gearbeitet hat, konnten sie das Refinement feature-Team übergreifend abhalten. Vorteil dieser Anpassung ist, dass die Refinements in kleineren Gruppen stattfinden und dadurch das Expertenwissen in den jeweiligen Themen entsteht, da von Beginn bis zum Abschluss eines Epics an einem Thema gearbeitet wird.

Unsere Einschätzung

Obwohl LeSS die Anwendung von Scrum in mehreren Teams, die an einem einzigen Produkt arbeiten, erleichtern soll, geht es bei der Umsetzung um mehr als die Übernahme eines Frameworks; es ist eine Reise, die ein Bewusstsein für den Kontext erfordert. Die Umstrukturierung unseres Kundenprojekts auf der Grundlage von LeSS brachte Wissensmanagement-, Kommunikation- und Koordinationsprobleme mit sich. Diese Herausforderungen wurden durch eine weitere Umstrukturierung innerhalb der Teams überwunden, wobei die Teammitglieder an Themen arbeiten mussten, die für ihr Fachwissen relevant waren.

Falls du überlegst, LeSS auf dein nächstes Projekt anzuwenden, ist es wichtig, die einzigartige Komplexität deines Projekts zu erkennen und die Dynamik deiner Teams zu verstehen. Die einzelnen Teams können auch miteinander über verschiedene Lösungen diskutieren, die sie zur Verbesserung ihrer Zusammenarbeit mit den anderen Teams nutzen können.

Nimm bei deiner nächsten LeSS-Reise die Herausforderungen an— sie ebnen den Weg zur Weiterentwicklung.

Hole Dir professionelle Unterstützung für Dein IT-Projektmanagement!

Nutze die langjährige Erfahrung und das umfassende Know-how der zertifizierten Projektmanager von doubleSlash. Von der Projektplanung bis zur erfolgreichen Durchführung.