1. Overview
  2. LeSS-Regeln (Dezember 2020)

LeSS-Regeln (Dezember 2020)

(Was sich seit der letzten Version geändert hat )
Die LeSS-Regeln beinhalten die Definition des LeSS-Frameworks. Sie stellen für uns ein muss dar. Warum? Dies wird im Abschnitt „Warum LeSS?“ erklärt.

LeSS-Framework-Regeln

Das LeSS-Framework gilt für Produkte mit zwei bis ca. acht Teams.

LeSS-Struktur

  • Strukturiere die Organisation mit echten Teams als grundlegenden Organisationsbaustein.
  • Jedes Team ist (1) selbstverwaltend, (2) funktionsübergreifend, (3) am selben Standort und (4) langlebig.
  • Die Mehrheit der Teams sind kundenorientierte Feature-Teams.
  • Scrum Master sind für eine gut funktionierende LeSS-Einführung verantwortlich. Ihr Fokus liegt auf den Teams, dem Product Owner, der Organisation und den Entwicklungspraktiken. Ein Scrum Master konzentriert sich nicht nur auf ein Team, sondern auf das gesamte Organisationssystem.
  • Ein Scrum Master ist eine dedizierte Vollzeitrolle.
  • Ein Scrum Master kann ein bis drei Teams betreuen.
  • In LeSS sind Manager optional, aber wenn Manager existieren, wird sich ihre Rolle wahrscheinlich ändern. Ihr Fokus wird sich vom produktorientierten Tagesgeschäft wegbewegen, hin zur Verbesserung der Fähigkeit des Produktentwicklungssystems, um einen Mehrwert zu liefern.
  • Die Rolle von Führungskräften liegt darin, das Produktentwicklungssystem durch das Praktizieren von Go See zu verbessern, zum Vorgehensmodell „Stop & Fix“ zu raten und Experimente höher als Konformität zu bewerten.
  • Etabliere in der Produktgruppe die komplette LeSS-Struktur „von Anfang an“; Dies ist für eine LeSS-Einführung von entscheidender Bedeutung.
  • Für die größere Organisation, die über die Produktgruppe hinausgeht, führe LeSS schrittweise ein, indem „Go & See“ eingesetzt wird, um eine Organisation zu formen, in der Experimentieren und Verbessern die Norm sind.

LeSS-Produkt

  • Es gibt nur einen Product Owner und ein Product Backlog für das komplette, auslieferbare Produkt.
  • Der Product Owner sollte nicht alleine das Product Backlog verfeinern; dies geschieht meistens durch die vielen Teams, die direkt mit den Kunden, den Nutzern und anderen Stakeholdern zusammenarbeiten.
  • Die gesamte Priorisierung geht über den Product Owner, aber die Klärung der Inhalte erfolgt so weit wie möglich direkt zwischen den Teams und den Kunden, den Nutzern und anderen Stakeholdern.
  • Die Produktdefinition sollte so weit gefasst und so endnutzer-/kundenzentriert sein, wie es praktikabel ist. Im Laufe der Zeit mag die Produktdefinition umfassender werden. Weiter gefasste Definitionen werden bevorzugt.
  • Es gibt eine Definition of Done für das gesamte Produkt, die für alle Teams gilt.
  • Jedes Team kann durch die Erweiterung der allgemeinen Definition of Done seine eigene, stärkere Definition of Done haben.
  • Das Perfektionsziel ist es, die Definition of Done dahingehend zu verbessern, dass nach jedem Sprint (oder sogar noch häufiger) ein auslieferbares Produkt vorliegt.

LeSS Sprint

  • Es gibt einen produktweiten Sprint und keine verschiedene Sprints für jedes Team. Alle Teams starten und beenden den Sprint zur gleichen Zeit. Jeder Sprint endet mit einem integrierten Gesamtprodukt.
  • Die Sprint-Planung besteht aus zwei Teilen: Sprint-Planung 1 für alle Teams gemeinsam, wohingegen typischerweise jedes Team für sich die Sprint-Planung 2 durchführt. Wenn man mehrere Teams hat, die an eng zusammenhängenden Dingen arbeiten, führt man mit diesen Teams eine gemeinsame Sprint-Planung 2 durch.
  • An der Sprint-Planung 1 nehmen der Product Owner und die Teams oder Stellvertreter der Teams teil. Diese wählen die Einträge vorläufig aus, die ihr jeweiliges Team im nächsten Sprint umsetzen wird. Die Teams identifizieren Möglichkeiten der Zusammenarbeit und klären letzte Fragen.
  • Jedes Team hat sein eigenes Sprint Backlog.
  • Die Sprint-Planung 2 dient dazu, dass die Teams entscheiden, wie sie die ausgewählten Einträge umsetzen werden. Dies beinhaltet in der Regel das Design und die Erstellung ihrer Sprint Backlogs.
  • Jedes Team hat sein eigenes Daily Scrum.
  • Teamübergreifende Koordination wird von den Teams entschieden. Bevorzuge dezentrale und informelle Koordination vor zentraler Koordination. Setze den Schwerpunkt auf „Einfach Reden“ (Just Talk) und informelle Netzwerke durch Kommunikation mittels Code, teamübergreifende Meetings, Komponentenmentoren, Travelers, Scouts und Open Spaces.
  • Product Backlog Refinement (PBR) wird vorzugsweise mit mehreren Teams durchgeführt, um das gemeinsame Verständnis zu verbessern und Möglichkeiten der Zusammenarbeit zu identifizieren.
  • Es gibt ein Produkt-Sprint-Review gemeinsam für alle Teams. Stelle sicher, dass geeignete Stakeholder daran teilnehmen, um Informationen einzubringen, die für ein effektives Inspizieren und Adaptieren notwendig sind.
  • Jedes Team hat seine eigene Sprint-Retrospektive.
  • Eine Gesamtretrospektive findet im Anschluss an die Retrospektiven der Teams statt, um team- und systemübergreifende Themen zu diskutieren und Verbesserungsexperimente zu beschließen. Der Product Owner, die Scrum Master, Stellvertreter aus den Teams und Manager (sofern vorhanden) nehmen daran teil.

LeSS Huge Framework-Regeln

LeSS Huge gilt für Produkte mit „acht und mehr“ Teams. Die Anwendung von LeSS Huge für kleinere Produktgruppen ist zu vermeiden, da es zu mehr Overhead und lokalen Optimierungen führt.

Alle LeSS-Regeln gelten für LeSS Huge, sofern nicht anders angegeben. Jeder Requirement Area agiert gemäß dem einfachen LeSS-Framework.

LeSS Huge Struktur

  • Kundenanforderungen, die aus Kundenperspektive stark zusammenhängen, sind in Requirement Areas gruppiert.
  • Jedes Team spezialisiert sich auf ein Requirement Area. Teams bleiben für eine lange Zeit in einer Requirement Area. Wenn es in anderen Bereichen mehr Wert gibt, wechseln Teams möglicherweise die Requirement Area.
  • Jede Requirement Area hat einen Area Product Owner.
  • Jede Requirement Area hat zwischen „vier bis acht“ Teams. Vermeide es, diese Spannbreite zu verletzen.
  • LeSS-Huge-Einführungen, einschließlich der strukturellen Änderungen, werden mit einem evolutionären inkrementellen Ansatz durchgeführt.
    Nicht vergessen: LeSS-Huge-Einführungen dauern Monate oder Jahre und bedürfen einer unendlichen Geduld und einem Sinn für Humor.

LeSS Huge Produkt

  • Ein (Gesamt-)Product Owner ist verantwortlich für die produktweite Priorisierung und die Entscheidung, welche Teams in welchen Bereichen arbeiten. Sie arbeitet eng mit den Area Product Ownern zusammen.
  • Area Product Owner agieren gegenüber ihren Teams als Product Owner.
  • Es gibt ein Product Backlog; jeder Eintrag darin gehört zu genau einer Requirement Area.
  • Es gibt ein Area Product Backlog pro Requirement Area. Dieses Backlog ist vom Konzept her eine detailliertere Sicht auf das eine Product Backlog.

LeSS Huge Sprint

  • Es gibt einen produktweiten Sprint und keine verschiedene Sprints für jede Requirement Area. Der Sprint endet in einem integrierten Gesamtprodukt.
  • Der Product Owner und die Area Product Owner synchronisieren sich häufig. Stelle vor der Sprintplanung sicher, dass die Teams an den wertvollsten Einträgen arbeiten. Ermögliche nach dem Sprint Review und darüber hinaus produktweite Anpassungen.