5 Agile Scaling Frameworks im Vergleich: Welches sollten Sie verwenden?

Stellen Sie sich folgendes vor: Zu Beginn eines Projekts stellen Sie ein einzelnes, effektives, funktionsübergreifendes Team von Personen zusammen, die sich der Erreichung der Produktziele verschrieben haben. Um die Leistung zu verbessern, stellen Sie sicher, dass das Team Agile beherrscht. Die Nachfrage nach dem Produkt wächst, die Anforderungen steigen und der Auftragsbestand wächst. Sie und andere Stakeholder erkennen, dass das Team skaliert werden muss. Klingt bekannt?

Durch die Skalierung können mehrere Teams zusammenarbeiten, um ihre Agilität aufrechtzuerhalten. Wenn mehr Arbeit zu erledigen ist, als Ihr Team in einem angemessenen Zeitraum bewältigen kann, ist es an der Zeit zu skalieren. Dazu müssen Sie jedoch das richtige Framework auswählen, und es stehen mehrere zur Auswahl. Wählen Sie schlecht, und die Implementierung könnte fehlschlagen, was die Produktivität beeinträchtigt und erhebliche finanzielle Auswirkungen hat.

Das für Ihr Team am besten geeignete Framework hängt von Faktoren wie verfügbarer Finanzierung, organisatorischem Ansatz und Produktkomplexität ab.

Wann sollten Sie skalieren?

Es gibt eine Reihe von Schlüsselkriterien, die erfüllt sein müssen, bevor Sie eine Skalierung in Erwägung ziehen:

Können Sie die Entwicklung mit nur einem Team bewältigen?

Die Implementierung skalierter agiler Frameworks kann komplex und zeitaufwändig sein, also skalieren Sie nicht, wenn Sie es nicht müssen. Wenn die Arbeitsbelastung Ihres Teams seine Möglichkeiten übersteigt, ist eine Skalierung erforderlich.

Ist Ihr Team agil?

Das vielleicht wichtigste Kriterium ist die Kompetenz Ihres Teams in agilen Ansätzen. Wenn Ihr Team keine Erfahrung mit Agile hat, wird die Skalierung weitere Probleme verursachen.

Müssen die Entwicklungspraktiken Ihres Teams verbessert werden?

Wenn die Engineering-Praktiken Ihres Teams nicht effizient sind, führt die Skalierung möglicherweise nicht zu den gewünschten Ergebnissen. Praktiken wie die ordnungsgemäße Implementierung von DevOps und eine CI/CD-Pipeline sind für die teamübergreifende Konsistenz von entscheidender Bedeutung. Außerdem kann es ohne standardisierte Qualitätssicherung schwierig sein, neue Funktionen zu testen.

Liefert Ihr Team integrierte Inkremente?

Skalierung beinhaltet die Integration mehrerer Teams, die an demselben Produkt zusammenarbeiten, wobei jedes Team Funktionen erstellt, die zusammenarbeiten. Die folgende Tabelle zeigt die vier möglichen Konfigurationen von Teams und Produkten. Beachten Sie, dass nur eine Skalierung erforderlich ist.

Auswählen eines Skalierungsframeworks

Es stehen zahlreiche agile Skalierungsframeworks zur Auswahl, aber wir konzentrieren uns auf fünf der am häufigsten verwendeten Lösungen: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale und Disciplined Agile (DA). . Ich habe festgestellt, dass dies die effektivsten Frameworks sind, und sie können auf eine Reihe von Szenarien und Organisationen angewendet werden. In den folgenden Abschnitten erhalten Sie die Informationen, die Sie benötigen, um die beste Wahl für Ihren einzigartigen Skalierungskontext zu treffen.

1. Skaliertes agiles Framework (SAFe)

SAFe ist das beliebteste Framework für die agile Skalierung. Eine Umfrage aus dem Jahr 2021 ergab, dass 37 % der agilen Praktiker es verwenden, hauptsächlich aufgrund seiner vielfältigen Konfigurationen, die sich alle auf Wertströme konzentrieren und über klar definierte Leitfäden und Verfahren verfügen.

Da SAFe verwendet wird, um komplexe Lösungen bereitzustellen, die mehr als 50 Personen erfordern, organisiert es Teams in Agile Release Trains (ARTs). Um die Teams in einem ART zu synchronisieren, verwendet SAFe Programminkrement-Iterationen – ähnlich wie Scrum-Sprints – und jede Iteration dauert in der Regel acht bis zwölf Wochen. Dieser Ansatz ermöglicht es Produktmanagern, sich auf die Gesamtziele zu konzentrieren und eine komplexe Produkt-Roadmap effizient zu überwachen, ohne übermäßige Änderungen vorzunehmen.

SAFe basiert auf dem Scrum-Framework, jedoch mit einigen wesentlichen Unterschieden: Die Einführung von SAFe erfolgt auf Unternehmensebene und nicht auf Teamebene; und während Scrum dem Product Owner die alleinige Autorität über die Priorisierung gibt, fördert SAFe einen demokratischeren Ansatz.

SAFe hat vier Implementierungsebenen:

Wesentliches SAFe

Essential SAFe ist die Grundlage von SAFe und muss beherrscht werden, bevor mit einer der nachfolgenden Konfigurationen fortgefahren werden kann. Es verwendet etablierte Scrum-Rollen wie Scrum Master, Produktmanager und Produktbesitzer und führt auch eine neue Rolle ein: Release Train Engineer. Diese Person fungiert als dienender Leiter und ART-Coach und leitet Teams an, ihre Ziele auszurichten. Ein ART kann zwischen fünf und 12 Teams umfassen, wobei jedes ART in der Lage ist, eine vollständige Lösung zu liefern.

Große Lösung

Diese Konfiguration sitzt auf Essential SAFe und führt ein Konzept namens „Solution Train“ ein. Es wird verwendet, wenn große und komplexe Lösungen erstellt werden, die die Koordination mehrerer ARTs erfordern – potenziell Hunderte oder sogar Tausende von Menschen – die am selben Wertstrom arbeiten. Wenn Sie beispielsweise bei Microsoft arbeiten und drei separate Teams Excel, Word und PowerPoint programmieren, tragen sie alle zum selben Wertstrom bei: Microsoft Office.

Portfolio

Das Portfolio besteht aus mehreren ARTs, die an verschiedenen Wertströmen arbeiten. Weiter zum Microsoft-Beispiel: Separate Teams arbeiten an den Office-, Skype- oder Xbox-Produkten des Unternehmens.

Volle SAFe

Diese Konfiguration kombiniert alle Ebenen – Essential, Large Solution und Portfolio –, um das unternehmensweite Teammanagement zu koordinieren.

2. Verbindung

Das Nexus-Framework basiert ebenfalls auf Scrum, ist aber leichter als SAFe und erfordert nur kleine Anpassungen, die die Zusammenarbeit zwischen drei bis neun Teams erleichtern. Für die Implementierung von Nexus sind keine zusätzlichen Rollen erforderlich. Vielmehr tritt ein Vertreter jedes Teams einem zentralen Integrationsteam bei, das die Arbeit auf ein einziges Ziel ausrichtet. Ähnlich wie bei Scrum kommen alle Teams zu einer Sprint Planning Session zusammen, deren Ergebnisse das gemeinsame Product Backlog bilden. Um den Fortschritt zu überprüfen, hält jedes Team ein tägliches Meeting ab, das einem Stand-up ähnelt, und das Integrationsteam trifft sich auch, um über den Fortschritt seines Teams zu berichten.

Während eines Sprints nehmen die Teams an einer Verfeinerungssitzung teil, um den Rückstand zu priorisieren und abzuschätzen. Da die Komplexität des Backlog-Managements mit der Anzahl der Teams steigt, schreibt Nexus Verfeinerungssitzungen vor. Die Teams treffen sich nach jedem Sprint zu Reviews und Retrospektiven.

3. Groß angelegtes Scrum (LeSS)

LeSS ist fast identisch mit Nexus, weist jedoch geringfügige Unterschiede auf, wie z. B. Namenskonventionen und zusätzliche, teamspezifische Sprint-Planungssitzungen. Es unterscheidet sich auch in seiner Erweiterbarkeit mit seiner zweiten Konfiguration, LeSS Huge, die die Zusammenarbeit von mehr als acht Teams unterstützt.

LeSS Huge verfolgt bei der Organisation der Entwicklung einen kundenorientierten Ansatz. Um die Arbeit effektiv zu verwalten, muss der Product Owner das High-Level-Produkt-Backlog in kleinere „Bereichs-Backlogs“ mit detaillierteren Elementen aufteilen und sie dann weiter sortieren – in Anforderungsbereiche.

Diese Anforderungsbereiche werden von Area Product Ownern (APOs) verwaltet. APOs spezialisieren sich auf die zum jeweiligen Bereich gehörigen Felder und arbeiten mit mehreren Teams an Lösungen für ihren Bereich. Jede im Backlog gespeicherte Anforderung gehört nur zu einem Anforderungsbereich, und jeder Bereich wird von nur einem APO verwaltet. Zusammen bilden der Product Owner und die APOs ein Team, das für die Priorisierung mit produktweiter Sicht verantwortlich ist.

4. Scrum@Scale

Scrum@Scale ist eine Erweiterung von Scrum und wahrscheinlich das am einfachsten zu erlernende und zu verstehende Framework. Es skaliert von einem Team zu einem Team von Teams.

Ein Kernbestandteil des Frameworks ist Scrum of Scrums (SoS). Jedes Team wählt eine Person, die es in SoS-Meetings vertritt, die normalerweise täglich nach den Stand-Ups der einzelnen Teams stattfinden. Ziel des täglichen SoS-Meetings ist es, die Koordination und Kommunikation zwischen den Teams zu unterstützen und ein einfaches Management von Abhängigkeiten oder Überschneidungen zu ermöglichen.

Zu den einzigartigen Rollen innerhalb dieses Frameworks gehören der SoS-Master, im Wesentlichen eine skalierte Version eines Scrum-Masters, und der Chief Product Owner, der mit den Team-Product Ownern zusammenarbeitet, um ein gemeinsames Backlog für den SoS zu erstellen.

Scrum@Scale ist weniger präskriptiv als andere Frameworks und ermöglicht es Unternehmen, in ihrem eigenen Tempo zu skalieren. Wenn die Anzahl der Teams weiter wächst und SoS-Meetings zu groß werden, können Organisationen das Framework zu einem Scrum of Scrum of Scrums (SoSoS) eskalieren.

5. Disziplinierte Agilität (DA)

DA unterscheidet sich von den anderen Frameworks dadurch, dass es eher als Toolbox fungiert, aus der Sie die am besten geeigneten Skalierungsstrategien auswählen können, und nicht als starres Framework mit Regeln, die Sie befolgen müssen. Es ist ein kontextgesteuerter Hybrid aus verschiedenen Frameworks, einschließlich Scrum und Kanban, der auf die Bedürfnisse jedes Projekts zugeschnitten werden kann und sich auf das Prinzip „Entscheidung ist gut“ konzentriert. DA basiert auf der Idee, dass jedes Team und jede Organisation in ihrer Größe, Verteilung und Domäne einzigartig ist, und dass jedes Teammitglied mit seinen eigenen Fähigkeiten und Erfahrungen ebenfalls einzigartig ist.

Es kann auf der Ebene des Softwareentwicklungsteams oder unternehmensweit angewendet werden. Für letztere identifiziert das DA-Toolkit, was verschiedene Geschäftsfunktionen – wie Finanzen, IT-Betrieb und Lieferantenmanagement – ​​ansprechen sollten, und stellt eine Reihe von Optionen dafür vor.

DA unterscheidet drei Projektphasen – Inception, Construction und Transition – und jede umfasst ergebnisorientierte Prozessziele. Da sich dieses Framework auf den gesamten Bereitstellungslebenszyklus und nicht nur auf den Build konzentriert, führt es mehr Rollen ein als die anderen Frameworks. Die primären Rollen, die in jedem DA-Team zu finden sind, sind Stakeholder, Teammitglied, Teamleiter, Produkteigentümer und Architektureigentümer. Außerdem gibt es fünf unterstützende Rollen, die häufig temporär zur Unterstützung der Skalierung verwendet werden: Spezialist, Domänenexperte, technischer Experte, unabhängiger Tester und Integrator.

DA kann zusätzlich zu den anderen Frameworks verwendet werden, um weiter zu skalieren.

Wählen Sie Sorgfältig und skalieren Sie langsam

Agile Teams zu skalieren und ihre Arbeit nahtlos zu integrieren, ist schwierig, kann aber durch die Auswahl des besten Frameworks erleichtert werden. Verwenden Sie das folgende Flussdiagramm als ersten Schritt, um Ihren Entscheidungsprozess zu leiten.

Ich bin zuversichtlich, dass Sie unter den hier vorgestellten das Skalierungs-Framework finden werden, das zu der Erfahrung, dem Ansatz, dem Budget und den Produkten Ihres Unternehmens passt. Für welches Framework Sie sich auch entscheiden, es ist wichtig, nichts zu überstürzen – skalieren Sie schrittweise, um Unterbrechungen zu minimieren, und planen Sie Änderungen weit im Voraus.

Haben Sie diese Frameworks bei Ihren Skalierungsaktivitäten verwendet? Erzählen Sie uns von Ihren Erfahrungen im Kommentarbereich.