LeSS

Blitzschnellen Zugriff auf die verschiedenen Themen, die Sie interessieren
LESS Grundlagen und Wissenstest
LeSS - Eine Zusammenfassung, Grundlagen und Wissenstest
Unterschiede FAST und LESS

LESS Grundlagen und Wissenstest

Large Scale Scrum = LeSS

LESS in a Nutshell

LeSS (Large Scale Scrum) ist ein agiles Framework, basierend auf Scrum - “LeSS ist Scrum” (ein zentrales Prinzip von LeSS), für die Organisation mehrerer Scrum Teams. Dabei ist LeSS auf zwei bis acht Teams ausgelegt, wohingegen LeSS Huge einen Ansatz für mehr als acht Teams bietet. Entwickelt wurde LeSS von Bas Vodde und Craig Larman.

LeSS stellt einen Prozessrahmen zur Verfügung der von den agierenden Teams individuell und vielfältig ausgestaltet werden kann. Der Grundgedanke des Frameworks ist folgender: anstelle zu versuchen viele Scrum-Teams zu koordinieren wird nur das Entwicklungsteam vergrößert. Das hat zur Folge dass es nur einen Product Owner gibt. Der Product Owner ist verantwortlich für das zentrale Backlog aus dem sich alle Entwicklungsteams bedienen, Ausnahme - LeSS Huge.

LeSS Huge verfügt über ein Konzept das “Feature-Areas” genannt wird. Jede Feature Area hat seinen eigenen Product Owner der ein sogenanntes “Area Product Backlog” (APB sind Teilmenge des Gesamt Backlogs) verantwortet. Feature Areas stellen spezielle Aspekte eines Produkts dar, die unabhängig lieferbar sind.

Wichtig: Scrum wird häufig als Projektmanagement-Framework betrachtet. Tatsächlich haben wir es hier mit einem Produkt-Entwicklungs-Framework zu tun. Das bedeutet, dass sich der gesamte Prozess darauf fokussiert, ein Produkt wachsen zu lassen, das den Wert für den Kunden maximiert. Scrum ist nicht dafür optimiert, Laufzeit, Budget und Ressourcen zu managen. LeSS ist ein Framework, das Produktentwicklung im Fokus hat und nicht Portfoliosteuerung

LeSS - Eine Zusammenfassung, Grundlagen und Wissenstest

LeSS in a Nutshell

LeSS (Large Scale Scrum) ist ein agiles Framework, basierend auf Scrum - “LeSS ist Scrum” (ein zentrales Prinzip von LeSS), für die Organisation mehrerer Scrum Teams. Dabei ist LeSS auf zwei bis acht Teams ausgelegt, wohingegen LeSS Huge einen Ansatz für mehr als acht Teams bietet. Entwickelt wurde LeSS von Bas Vodde und Craig Larman.

LeSS stellt einen Prozessrahmen zur Verfügung der von den agierenden Teams individuell und vielfältig ausgestaltet werden kann. Der Grundgedanke des Frameworks ist folgender: anstelle zu versuchen viele Scrum-Teams zu koordinieren wird nur das Entwicklungsteam vergrößert. Das hat zur Folge dass es nur einen Product Owner gibt. Der Product Owner ist verantwortlich für das zentrale Backlog aus dem sich alle Entwicklungsteams bedienen, Ausnahme - LeSS Huge.

LeSS Huge verfügt über ein Konzept das “Feature-Areas” genannt wird. Jede Feature Area hat seinen eigenen Product Owner der ein sogenanntes “Area Product Backlog” (APB sind Teilmenge des Gesamt Backlogs) verantwortet. Feature Areas stellen spezielle Aspekte eines Produkts dar, die unabhängig lieferbar sind.

Wichtig: Scrum wird häufig als Projektmanagement-Framework betrachtet. Tatsächlich haben wir es hier mit einem Produkt-Entwicklungs-Framework zu tun. Das bedeutet, dass sich der gesamte Prozess darauf fokussiert, ein Produkt wachsen zu lassen, das den Wert für den Kunden maximiert. Scrum ist nicht dafür optimiert, Laufzeit, Budget und Ressourcen zu managen. LeSS ist ein Framework, das Produktentwicklung im Fokus hat und nicht Portfoliosteuerung

LeSS Unterschiede zu Scrum (2017)

  • Das Konzept der Scrum Teams existiert in LeSS nicht

  • Das Development Team in Scrum wird in LeSS einfach als “Team bezeichnet

  • “Self-organizing Teams” werden in LeSS “Self-managing Teams” genannt

  • Sprint Planning in Scrum wird aufgeteilt in “Sprint Planning 1” und “Sprint Planning 2“

  • Backlog Refinement ist keine Aktivität sondern ein Event

  • Die Rolle des Scrum Masters ist eine “full time” Rolle

  • Der Product Owner muss am Daily Scrum oder an der Retro nicht teilnehmen

Das LeSS Framework

Da LeSS weitestgehend auf Scrum basiert werden hier nur die Unterschiede (siehe oben) zu Scrum beschrieben.

Das Produkt

Häufig ist die in LeSS bevorzugte Produktdefinition nicht die gleiche wie die ursprüngliche Produktdefinition, was zu einem Umdenken und schließlich zu einer Änderung in der Organisation führt.

Fragestellungen im Rahmen der Produktdefinition haben Einfluss auf:

  • den Umfang des Product Backlog

  • Wer der Product Owner sein wird

  • die Größe des Teams und damit ob es sich um eine LeSS oder Huge LeSS Adoption handelt.

Ergänzende und einschränkende Fragen drehen sich um:

  • Ist die Produktdefinition Kundenorientiert?

  • Welche Aufgaben liegen bei uns, welche beim Kunden?

  • Was befindet sich außerhalb unserer Kontrolle?

  • Gibt es eine Produkt Vision?

Kontinuierliche Verbesserung bedeutet:

  • Verbesserung der Übersicht und feingranulare Prioritätensetzung

  • Vermeidung von Doppelarbeit zwischen ähnlichen Produkten

  • Abhängigkeiten zwischen kleineren Produkten werden aufgelöst

  • Fokussierung auf die wirklichen Kundenprobleme

  • Reduktion organisatorischer Komplexität

Der Sprint

  • Die Sprint Planung findet für alle Teams gleichzeitig statt (gleich Taktung)

  • Sprint Review und Retro finden gleichzeitig statt

  • Das Backlog Refinement muss nicht gleichzeitig stattfinden

Die Sprint Planung

In LeSS ist Sprint Planning One ein Meeting für alle Teams zusammen, in dem sie entscheiden, welches Team an welchen Items arbeiten wird.
Sprint Planning Two ist ein separates Meeting pro Team, in dem jedes Team den Plan erstellt, um die Items während des Sprints zu "erledigen”

Sprint Review und Retrospektive

Am Ende eines Sprints haben alle Teams gemeinsam das Sprint Review und jedes Team Ihre individuelle Retrospektive - analog zu Scrum.

Neben den einzelnen Team Retros gibt es noch eine übergeordnete, “Overall Retrospective” diese ist LeSS speszifisch und dient dazu, teamübergreifende, organisatorische und systemische Probleme innerhalb der Organisation zu diskutieren. Teilnehmer sind:

  • der Product Owner

  • der Scrum Master

  • Team Repräsentanten

  • Manager (wenn benötigt)

Konzeptionell findet die Gesamt-Retrospektive direkt nach den Team-Retrospektiven statt. In der Praxis kann dies ein Problem darstellen, da die Team-Retrospektiven oft am Ende des Tages am Ende eines Sprints stattfinden. Nicht nur, dass die Leute oft erschöpft sind, sie haben auch keine Zeit für ein weiteres Retrospektive-Meeting.

Der übliche Ausweg ist, die Gesamt-Retrospektive am Anfang des nächsten Sprints abzuhalten

Initial Product Blog Refinement

Am Ende eines Sprints haben alle Teams gemeinsam das Sprint Review und jedes Team Ihre individuelle Retrospektive - analog zu Scrum.

Product Backlog Refinement (PBR)

Hauptaktivitäten des PBR sind:

  • Das Klären von “Elementen” bis sie ohne weitere “WAS” Fragen implementierungsbereit sind

  • Das Schätzen der Größe

  • Das Schätzen des Wertes

  • Das Schätzen der Risiken

Das PBR findet im laufenden Sprint statt und soll nicht mehr als 10% der Sprint-Kapazität verwenden.

Das gesamte Team führt die Klärung durch, nicht in Untergruppen, auf Basis der Scrum Regeln die Untergruppen verbieten. Das Risiko der Übergabe und Informationsstreuung würde sonst erhöht und das würde gegen den Lean Gedanken sprechen.

Multi-Term Product Backlog Refinement

Laut www.less.works das wichtigste Ereignis um effektive Sprints mit gut ausgerichteten, koordinierten und adaptiven Teams voranzutreiben

Mehrere Teams sind im gleichen Raum und führen ein PBR durch (sind die Teams über mehrere Standorte verteilt gibt es in der LeSS Literatur entsprechende Beispiele für einen solchen Fall).

Zu den Teilnehmern gehören die Mitglieder aller teilnehmenden Teams. Auch Fachexperten, User, Kunden und der Product Owner können dazu geholt werden. Es wird empfohlen das ein erfahrender, mit entsprechenden Moderationsskills ausgestatteter, Scrum Master diesen Workshop moderiert.

PBR mit mehreren Teams verbessern das gemeinsame Verständnis, die Koordinationsmöglichkeiten Schätzungen abzustimmen und die Anpassungen zwischen den Teams.

Folgendes Vorgehen wird empfohlen:

  • Aufteilung der Teilnehmer in N Teams zu N Gruppen, wobei die Personen in jeder Gruppe aus jedem Team stammen.

  • Jede gemischte Gruppe klärt parallel verschiedene Items im Rahmen eines vorher definierten Zeitraums.

  • Rotieren der Gruppen über die Items, so dass im Laufe der Zeit alle Gruppen alle (oder zumindest die meisten) Items verfeinert haben

Für das Multi Term PBR wird keine Timebox angegeben, es wird allerdings immer von einem langen und ausführlichem Termin gesprochen.

Overall PBR

Ein Overall PBR bietet sich für folgende Situationen an:

Wenn die Gruppe verwandte Themen in z.B. 2 große Teilmengen aufteilen möchte. Im Weiteren arbeiten dann jeweils 4 Teams an einer Teilmenge.

In so einem Fall wird ein Overall PBR mit Vertretern aus allen Teams und dem Product Owner abgehalten. Vertreter werden genommen um das Meeting kleiner zu halten. Der Verlust von Transparenz (Informationsweitergabe und Streuung) wird dafür in kauf genommen.

Ebenfalls kann ein overall PBR stattfinden, wenn der Product Owner am Multi Term PBR nicht teilnehmen kann (Urlaub, Krankheit, etc.). In so einem Fall bietet ein overall KBR-Event zumindest eine gewisse Interaktion mit dem Product Owner über alle relevanten anstehenden Punkte.

Single Term PBR

PBR’s für Einzelteams sollten in LeSS selten sein, da sie das Lernen der Gruppe hemmen, die Koordination und Ausrichtung schwächen und die Anpassungsfähigkeit verringern. Eine Situation, in der es relevant sein könnte, ist der Einsatz des LeSS Guide Leading Teams, in der frühen Phase seiner Arbeit.
Ein Leading Team wird verwendet wenn ein Thema noch nicht vollständig ausformuliert ist und das Ziel des Produktes noch nicht vollständig geklärt ist. In dieser Zeit führt das Leading Team bis zur Beseitigung aller Unklarheiten Single Term PBR’s durch. Nach Abschluss dieser Phase kommen mehrerer Teams dazu und es wird umgestellt auf Multi-Term-PBR’s

Koordination und Integration

LeSS-Koordination und -Integration konzentriert sich darauf, wie man dezentrale Koordination unterstützt und gleichzeitig genug Grenzen und Struktur bietet, um Chaos zu vermeiden.

Just Talk - einfach reden

Die einfachste Art der Koordination zwischen den Teams ist - Reden. Es wird erwartet, dass jedes Teammitglied in der Lage ist sich bei Problemen an ein anderes Teammitglied zu wenden, persönlich, per Mail, per Telefon, etc. LeSS benötigt keine formellen offiziellen Meetings.

Kommunizieren per Code - (Entwicklungsprojekte!)

Regelmässiges synchronisieren mit dem gemeinsamen Repository wird im Rahmen des von Continous Integration erwartet.

Scouts

Eine einfache Koordinierungsmethode besteht darin, dass Teams ihre Umgebung erkunden und Scouts zu anderen Teams schickt.

Komponentengemeinschaften und Mentoren (Entwicklungsprojekte!)

Besprechungen mit mehreren Teams

Für Teams, die eng zusammenarbeiten, ist es üblich, LeSS-Meetings mit mehreren Teams abzuhalten. Einige Beispiele wären:

  • Produkt-Backlog-Refinement mit mehreren Teams

  • Sprint-Planing mit mehreren Teams

  • Multi-Team-Design-Workshops

  • Austausch von Mitgliedern in Daily Scrum.

Weitere Bestandteile des LeSS Frameworks …

…auf die nicht weiter eingegangen wird weil sie im folgenden noch genauer beschrieben sind

  • Daily Scrum

  • Definition of done

  • Scrum master

oder weil sie analog zu Scrum verwendet werden:

  • Scrum master

  • Team

     

LeSS Principles

Die LeSS-Regeln definieren das LeSS Framework. Die Regeln sind bewusst minimalistisch gehalten und geben keine Antwort darauf, wie LeSS in einem speziellen Umfeld zu verwenden ist. Die LeSS Prinzipien liefern die Grundlage für eine solche Entscheidung

 
  • Large-Scale Scrum ist Scrum - es ist kein "neues und verbessertes Scrum". Bei LeSS geht es darum, die Prinzipien, Elemente und den Zweck von Scrum in einem groß angelegten Kontext anzuwenden. Scrum mit mehreren Teams, nicht mehrere Scrum-Teams.

  • Empirische Prozesssteuerung - Untersuchung und Anpassung des Produkts, der Prozesse, des Organisationsdesigns und der Praktiken, um eine situationsgerechte Organisation auf der Basis von Scrum zu schaffen, anstatt einer detaillierten Formel zu folgen. Eine empirische Prozesssteuerung erfordert und schafft Transparenz.

  • Transparenz - basierend auf greifbaren "done"-Items, kurzen Zyklen, gemeinsamer Arbeit, gemeinsamen Definitionen und dem Vertreiben von Angst am Arbeitsplatz.

  • More with LeSS- In der empirischen Prozesssteuerung: mehr Lernen mit weniger definierten Prozessen. Im Lean Thinking: mehr Wert mit weniger Verschwendung und Overhead. Bei der Skalierung: mehr Eigenverantwortung, Zweck und Freude mit weniger Rollen, Artefakten und speziellen Gruppen.

  • Fokus auf das gesamte Produkt - ein Product Backlog, ein Product Owner, ein potenziell auslieferbares Produktinkrement, ein Sprint - unabhängig davon, ob es 3 oder 33 Teams gibt. Kunden wollen das Produkt, nicht einen Teil.

  • Kundenzentriert - Identifizieren Sie Wert und Verschwendung in den Augen des zahlenden Kunden. Reduzieren Sie die Zykluszeit aus deren Sicht. Erhöhen Sie die Feedback-Schleifen mit echten Kunden. Jeder versteht, wie seine Arbeit heute direkt mit dem zahlenden Kunden zusammenhängt.

  • Kontinuierliche Verbesserung auf dem Weg zur Perfektion - Erzeugen und liefern Sie stets ein Produkt ohne Fehler, dass die Kunden vollends begeistert, die Umwelt verbessert und das Leben besser macht. Führen Sie in jedem Sprint bescheidene und radikale Verbesserungsexperimente in diese Richtung durch.

  • Systemdenken - Sehen, verstehen und optimieren Sie das ganze System (nicht Teile) und erforschen Sie die Systemdynamik. Vermeiden Sie die lokale und suboptimale Fokussierung auf die "Effizienz" oder "Produktivität" von Einzelpersonen und einzelnen Teams. Kunden interessieren sich für die gesamte Konzept-zu-Cash-Zykluszeit und den Fluss, nicht für einzelne Schritte.

  • Lean thinking - Schaffen Sie ein Organisationssystem, dessen Grundlage “Manager-as-teacher” ist, die Systemdenken und schlankes Denken anwenden und lehren, die auf Verbesserung hin managen und die "Go to Gemba" (Verwand “mit dem Management by walking arround”) praktizieren. Fügen Sie die beiden Säulen des Respekts für Menschen und der kontinuierlichen Verbesserung hinzu. Alles mit dem Ziel der Perfektion.

  • Queuing theorie - Verstehen Sie, wie sich Systeme mit Warteschlangen im F&E-Bereich verhalten, und wenden Sie diese Erkenntnisse auf die Verwaltung von Warteschlangengrößen, Work-in-Progress-Grenzen, Multitasking, Arbeitspakete und Variabilität an.

LeSS Structure

Wissenstest

Unterschiede FAST und LESS