Skalieren von Agile auf große Teams

Viele Benutzer würden die Wörter "big" und "Agile" nicht im selben Satz verwenden. Große Softwareorganisationen haben sich den Ruf erworben, groß und langsam zu sein, sich zu ändern. Dies ändert sich jedoch. Viele große Organisationen machen die Transformation zu Agile erfolgreich. Sie lernen, Agile-Prinzipien mit unseren ohne gängige Frameworks wie SAFe, LeSS oder Nexus zu skalieren.

Eine solche Gruppe, die Azure DevOps-Organisation bei Microsoft, erstellt die Produkte und Dienste, die unter der Marke Azure DevOps ausgeliefert werden. Sie verfügen über 35 Featureteams, die alle drei Wochen in der Produktion veröffentlicht werden.

Jedes Team innerhalb Azure DevOps besitzt alles von Anfang bis Ende und darüber hinaus. Sie besitzen Kundenbeziehungen. Sie verwalten ihr eigenes Produktbacklog. Sie schreiben und checken Code in den Produktionszweig ein. Alle drei Wochen wird der Produktionszweig bereitgestellt, und das Release wird veröffentlicht. Die Teams überwachen dann die Systemzustandsüberwachung und beheben Probleme mit Livewebsites.

Gemäß den Agile-Prinzipien sind autonome Teams produktiver. Eine Agile-Organisation möchte, dass ihre Teams bei ihrer täglichen Ausführung eigenständig sind. Aber eine Autonome Ohne Ausrichtung würde zu Chaos führen. Dutzende von Teams, die unabhängig arbeiten, würden kein einheitliches, qualitativ hochwertiges Produkt erzeugen. Ausrichtung gibt Teams ihren Zweck. Die Ausrichtung stellt sicher, dass die Teams die Organisationsziele erreichen. Ohne Ausrichtung würden selbst die Teams mit der besten Leistung fehlschlagen.

Um Agile zu skalieren, müssen Sie die Eigenständigkeit für das Team aktivieren und gleichzeitig die Ausrichtung mit der Organisation sicherstellen.

Um das Gleichgewicht zwischen Ausrichtung und Eigenständigkeit zu verwalten, müssen DevOps-Führungskräfte eine Taxonomie definieren, einen Planungsprozess definieren und Featurechats verwenden.

Definieren einer Taxonomie

Eine klar definierte Taxonomie definiert die Nomenklatur für eine Organisation.

Ein Agile-Team benötigt klar definierte Backlogs, um erfolgreich zu sein. Dies gilt auch für die größere Agile-Organisation, zu der sie gehört. Teams haben Schwierigkeiten, erfolgreich zu sein, wenn die Organisationsziele unklar sind.

Eine agile Organisation muss ihre Ziele klar definieren und festlegen, wie jedes Team zu diesen Zielen beitragen muss. Um dies zu erreichen, muss die Organisation eine Taxonomie definieren.

Eine gängige Taxonomie sind Epics, Features, Storys und Aufgaben.

Eine allgemeine Taxonomie

Epics

Epics deklarieren Initiativen, die für den Erfolg der Organisation wichtig sind. Epics können mehrere Teams und mehrere Sprints dauern, aber sie sind nicht ohne Ende. Epics haben ein klar definiertes Ziel. Nach der Endung wird das Epic geschlossen. Die Anzahl von Epics, die in Bearbeitung sind, sollte verwaltbar sein, um den Fokus der Organisation zu behalten. Epics sind in Features aufgeschlüsselt.

Features

Features definieren neue Funktionen, die erforderlich sind, um das Ziel eines Epics zu erreichen. Features sind die Releaseeinheit. sie stellen dar, was für den Kunden freigegeben wird. Veröffentlichte Versionshinweise können basierend auf der Liste der vor Kurzem abgeschlossenen Features erstellt werden. Features können mehrere Sprints dauern, sollten jedoch dimensioniert werden, um einen konsistenten Wertfluss für den Kunden sicherzustellen. Features werden in Storys unterteilt.

Storys

Storys definieren den inkrementellen Wert, den das Team bereitstellen muss, um ein Feature zu erstellen. Das Team unterteilt das Feature in inkrementelle Teile. Eine einzelne abgeschlossene Story bietet dem Kunden möglicherweise keinen sinnvollen Nutzen. Eine abgeschlossene Geschichte stellt jedoch Software in Produktionsqualität dar. Storys sind die Arbeitseinheit des Teams. Das Team definiert die Storys, die zum Abschließen eines Features erforderlich sind. Storys können optional in Aufgaben unterteilt werden.

Tasks

Aufgaben definieren die Arbeit, die zum Abschließen einer Story erforderlich ist.

Initiativen

Diese Taxonomie ist kein allumgebliches All. Viele Organisationen führen eine Ebene oberhalb von Epics ein, die als Initiativen bezeichnet werden.

Eine gängige Taxonomie mit Initiativen

Die Namen der einzelnen Ebenen können auf Ihre Organisation zugeschnitten werden. Die oben definierten Namen (Epics, Features, Storys) sind jedoch dem Branchenstandard recht nahe.

Line of Autonomy

Sobald eine Taxonomie festgelegt ist, definieren Sie die Autonomy-Linie. Die Linie der Eigenständigkeit ist der Punkt, an dem das Team der klare Besitzer ist und die Verwaltung nicht beeinträchtigt.

Im folgenden Beispiel wurde die Unten dargestellte Linie der Eigenständigkeit gezeichnet. Die Verwaltung besitzt Epics und Features, die eine Ausrichtung ermöglichen. Teams besitzen Storys und Aufgaben und sind in bezug auf ihre Ausführungen eigenständig.

The Line of Autonomy

Die Verwaltung erweitert den Besitz nicht unterhalb der Linie der Eigenständigkeit. Die Verwaltung sagt dem Team z. B. nicht an, wie storys zersetzt, der Sprint geplant oder seine Arbeit ausgeführt werden soll.

Das Team muss jedoch sicherstellen, dass seine Ausführung den Verwaltungszielen entspricht. Während ein Team seinen Story-Backlog besitzt, muss es sein Backlog an den ihnen zugewiesenen Features ausrichten.

Planung

Zum Skalieren der agilen Planung benötigt ein Team einen Plan für jede Ebene der Taxonomie. Die Planung von rollierender Welle ist entscheidend. Der Plan stellt die Richtung für einen festen Zeitraum mit erwarteter Kalibrierung in regelmäßigen Intervallen dar. Beispielsweise kann ein 18-Monat-Plan alle 6 Monate kalibriert werden.

Hier ist ein Beispiel für Planungsmethoden für jede Ebene einer Taxonomie: Epics, Features, Storys, Aufgaben.

Planen von Intervallen

Bildanalyse

Die Vision wird durch Epics ausgedrückt und legt die langfristige Richtung der Organisation fest. Die Verwaltung besitzt den Plan und kalibriert ihn alle sechs Monate. Epics definieren, was die Organisation in den nächsten 18 Monaten abschließen möchte. Die Vision wird in einer Besprechung mit allen Händen präsentiert. Da die Vision für eine Agile-Organisation in diesem Zeitraum beweglich sein soll und sich viel ändern kann, sollten Sie davon ausgehen, etwa 60 % der Vision zu erreichen.

Saison

Eine Saison wird anhand von Features beschrieben und legt die Strategie für die nächsten 6 Monate fest. Features bestimmen, was die Organisation für ihre Kunden aufleuchten möchte. Die Verwaltung ist Besitzer des saisonalen Plans und stellt die Vision und die saisonalen Pläne bei einem All-Hands-Meeting vor. Alle Teampläne müssen mit dem saisonalen Plan der Verwaltung übereinstimmen. Erwarten Sie, dass etwa 80 % des saisonalen Plans erreicht werden.

3-Sprint-Plan

Der 3-Sprint-Plan definiert die Storys und Features, die das Team in den nächsten drei Sprints abschließen wird. Das Team besitzt den Plan und kalibriert ihn bei jedem Sprint. Jedes Team präsentiert seine Pläne der Verwaltung über den Featurechat (siehe unten). Der Plan gibt an, wie die Ausführung des Teams mit dem 6-Monat-Saisonplan übereinstimmt. Erwarten Sie, dass ungefähr 90 % des 3-Sprint-Plans erreicht werden.

Sprintplan

Der Sprintplan definiert die Storys und Features, die das Team im nächsten Sprint abschließen wird. Das Team ist der Eigentümer des Sprintplans und sendet ihn zur vollständigen Transparenz an die gesamte Organisation. Der Plan umfasst, was das Team im letzten Sprint erreicht hat, und den Fokus für den nächsten Sprint. Erwarten Sie, dass etwa 95 % des Sprintplans erreicht werden.

Line of Autonomy

Die Linie der Autonomie wird gezeichnet, um zu zeigen, wo Teams über Planungsautonomie verfügen. Der obige Planungsprozess zeichnet die Linie der Autonomie wie folgt:

Eine weitere Ansicht der Autonomen Linie

Wie oben erwähnt, erweitert die Verwaltung den Besitz nicht unterhalb der Autonomen Linie. Sie bieten Anleitungen zur Verwendung der Visions- und Saisonpläne und geben Teams die Möglichkeit, 3-Sprint- und Sprintpläne zu erstellen.

Featurechats: Wo die Autonomie die Ausrichtung erfüllt

Bei einem Featurechat handelt es sich um eine besprechungsfreie Besprechung, bei der jedes Team seine 3-Sprint-Pläne für die Verwaltung vorstellt. Diese Besprechung stellt sicher, dass Teampläne mit den Organisationszielen übereinstimmen. Darüber hinaus hilft es der Verwaltung, über die Arbeit des Teams informiert zu bleiben. Während der 3-Sprint-Plan bei jedem Sprint kalibriert wird, werden Featurechats nach Bedarf gehalten, in der Regel alle 1-3 Sprints.

Ein Featurechatbesprechung ordnet jedem Team 15 Minuten zu. Mit zwölf Featureteams können diese Besprechungen in etwa drei Stunden geplant werden. Jedes Team bereitet eine 3-Foliengruppe mit den folgenden Folien vor:

Features

Die Features, die das Team in den nächsten drei Sprints aufleuchten wird.

Schulden

Wie das Team seine technischen Schulden verwaltet. Schulden sind alles, was den Qualitätsbalken der Verwaltung nicht entspricht. Der Director of Engineering legt die Qualitätsbalken fest, die für alle Teams gleich sind (Ausrichtung). Beispiele für Qualitätsindikatoren sind # Fehler/Techniker, bestandene Komponententests in Prozent und Leistungsziele.

Probleme/Abhängigkeiten

Alles, was sich auf den Fortschritt des Teams auswirkt. Probleme, die das Team nicht beheben kann, oder Abhängigkeiten von anderen Teams, die eine Eskalation erfordern. Jedes Team präsentiert seine Folien direkt der Verwaltung. Das Team zeigt, wie sein 3-Sprint-Plan mit dem 6-Monat-Saisonplan übereinstimmt. Die Führungskraft stellt klare Fragen und schlägt Änderungen in der Richtung vor. Sie können auch Folgebesprechungen anfordern, um tiefergehende Probleme zu beheben.

Wenn der Plan eines Teams nicht den Erwartungen des Managements entspricht, kann die Verwaltung einen neu geplanten Plan anfordern. In diesem seltenen Fall plant das Team einen zweiten Featurechat neu, um ihn zu überprüfen.

Vertrauensstellung: Der Glue, der die Ausrichtung und Die Eigenständigkeit zusammenhält

Wenn Agile im großen Stil trainiert wird, ist Vertrauen eine Zwei-Wege-Straße:

Die Verwaltung muss teams vertrauen, um das Richtige zu tun. Wenn die Verwaltung den Teams nicht vertraut, gibt sie den Teams keine Eigenständigkeit.

Ein Team erhält Vertrauen, indem es konsistent qualitativ hochwertigen Code liefert. Wenn Teams nicht vertrauenswürdig sind, gibt ihnen die Verwaltung keine Eigenständigkeit.

Die Verwaltung muss klare Pläne für Teams bereitstellen, die sich an der Ausführung ihrer Teams ausrichten und darauf vertrauen können. Teams müssen ihre Pläne an der Organisation ausrichten und auf vertrauenswürdige Weise ausführen.

Wenn Organisationen Agile auf größere Szenarien skalieren möchten, besteht der Schlüssel darin, Teams Dies zu ermöglichen und gleichzeitig sicherzustellen, dass sie den Organisationszielen entsprechen. Die wichtigen Bausteine sind klar definierter Besitz und eine Vertrauenskultur. Sobald eine Organisation über diese Grundlage verfügt, wird sie feststellen, dass Agile sehr gut skaliert werden kann.

Nächste Schritte

Es gibt viele Möglichkeiten für ein Team beliebiger Größe, um noch heute Vorteile zu erkennen. Sehen Sie sich einige dieser Methoden zur Skalierung von an.

Erfahren Sie mehr über Azure DevOps Features für die Portfolioverwaltung und Sichtbarkeit in teamsübergreifend.

Microsoft ist eines der weltweit größten Agile-Unternehmen. Erfahren Sie mehr darüber, wie Microsoft die DevOps-Planung skaliert.