Skalierung von Agile für große Teams

Die Wörter Groß und Agile werden nicht häufig in einem Satz verwendet. Große Unternehmen haben sich den Ruf erworben, langsam voranzukommen. Das ändert sich jedoch. Viele große Softwareunternehmen vollziehen erfolgreich die Umstellung auf Agile. Sie lernen, Agile-Prinzipien mit oder ohne beliebte Frameworks wie SAFe, LeSS oder Nexus zu skalieren.

Bei Microsoft verwendet eine solche Organisation Agile, um Produkte und Dienste zu erstellen, die unter der Marke Azure DevOps ausgeliefert wurden. Diese Gruppe verfügt über 35 Feature-Teams, die alle drei Wochen Features für die Produktion freigeben.

Jedes Team in Azure DevOps verfügt über Features von Anfang bis Ende und darüber hinaus. Sie besitzen eigene Kundenbeziehungen. Sie verwalten ihren eigenen Produkt-Backlog. Sie schreiben und überprüfen Code in der Produktionsverzweigung. Alle drei Wochen wird die Produktionsverzweigung bereitgestellt, und das Release wird öffentlich. Die Teams überwachen dann die Systemintegrität und beheben Live-Site-Probleme.

Gemäß den Agile-Prinzipien sind autonome Teams produktiver. Eine Agile-Organisation möchte, dass ihre Teams die Kontrolle über ihre tägliche Ausführung haben. Jedoch führt Autonomie ohne Koordinierung zu Chaos. Dutzende unabhängig voneinander arbeitende Teams würden kein einheitliches, qualitativ hochwertiges Produkt produzieren. Die Ausrichtung gibt den Teams ihren Zweck und stellt sicher, dass sie die Ziele der Organisation erreichen. Ohne Ausrichtung würden selbst die besten Teams fehlschlagen.

Um Agile zu skalieren, müssen Sie die Autonomie für das Team aktivieren und gleichzeitig die Ausrichtung auf die Organisation sicherstellen.

Um das empfindliche Gleichgewicht zwischen Ausrichtung und Autonomie zu bewältigen, müssen DevOps-Führungskräfte eine Taxonomie sowie einen Planungsprozess definieren und Feature-Chats verwenden.

Eine Taxonomie definieren

Ein Agile-Team und die größere Agile-Organisation, zu der es gehört, benötigen einen klar definierten Backlog, um erfolgreich zu sein. Teams werden Schwierigkeiten haben, erfolgreich zu sein, wenn die organisatorischen Ziele unklar sind.

Um klare Ziele festzulegen und darzulegen, wie jedes Team dazu beiträgt, muss die Organisation eine Taxonomie definieren. Eine klar definierte Taxonomie erstellt die Nomenklatur für eine Organisation.

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

Epics

Epics beschreiben Initiativen, die für den Erfolg der Organisation wichtig sind. Epics erfordern möglicherweise mehrere Teams und mehrere Sprints, aber sie haben ein Ende. Epics haben ein klar definiertes Ziel. Sobald das Epic erreicht wurde, ist es geschlossen. Die Anzahl der laufenden Epics sollte verwaltbar sein, damit die Organisation fokussiert bleibt. Epics sind in Features unterteilt.

Features

Features definieren neue Funktionen, die erforderlich sind, um ein Epic-Ziel zu realisieren. Features sind die Releaseeinheit; sie stellen dar, was für den Kunden freigegeben wird. Veröffentlichte Versionshinweise können basierend auf der Liste der kürzlich abgeschlossenen Features erstellt werden. Die Fertigstellung von Funktionen kann mehrere Sprints erfordern, sollte jedoch so dimensioniert sein, dass ein konsistenter Wertefluss für den Kunden sichergestellt ist. Features werden in Storys unterteilt.

Storys

Storys definieren 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 Mehrwert. Eine abgeschlossene Story stellt jedoch Software in Produktionsqualität dar. Storys sind die Arbeitseinheit des Teams. Das Team definiert die zum Abschließen eines Features erforderliche Story. Storys können optional in Vorgänge unterteilt werden.

Aufgaben

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

Initiativen

Diese Taxonomie ist kein Standardsystem. Viele Organisationen führen eine Ebene über Epics ein, die als Initiativen bezeichnet werden.

Die Namen jeder Ebene können auf Ihre Organisation zugeschnitten werden. Die oben definierten Namen (Epics, Features, Storys) werden jedoch in der Branche häufig verwendet.

Autonomieabfolge

Sobald eine Taxonomie festgelegt ist, muss die Organisation eine Autonomieabfolge festlegen. Die Autonomieabfolge ist der Punkt, an dem die Verantwortung für die Ebene vom Management auf das Team übergeht. Das Management greift nicht in Ebenen ein, die dem Team gehören.

Das folgende Beispiel zeigt die Autonomieabfolge, die unter den Features festgelegt wird. Das Management besitzt Epics und Features, die Ausrichtung bieten. Teams besitzen Storys und Aufgaben und haben Autonomie darüber, wie sie ausgeführt werden.

In diesem Beispiel teilt das Management dem Team nicht mit, wie es Storys zerlegen, Sprints planen oder Arbeiten ausführen soll.

Das Team muss jedoch sicherstellen, dass seine Ausführung mit den Zielen des Managements übereinstimmt. Während ein Team über sein Backlog an Storys verfügt, muss es seinen Backlog an die Features ausrichten, die ihm zugewiesen sind.

Planung

Zum Skalieren der Agile-Planung benötigt ein Team einen Plan für jede Taxonomieebene. Es ist jedoch wichtig, den Plan zu durchlaufen und zu aktualisieren. Dieser Prozess wird als Rolling-Wave-Planung bezeichnet.

Der Plan gibt die Richtung für einen festgelegten Zeitraum vor und erwartet in regelmäßigen Abständen eine Kalibrierung. Beispielsweise könnte ein 18-monatiger Plan alle sechs Monate kalibriert werden.

Nachfolgend finden Sie ein Beispiel für Planungsmethoden für jede Taxonomieebene: Epics, Features, Storys, Aufgaben.

Bildanalyse

Die Vision wird durch Epics ausgedrückt und legt die langfristige Richtung der Organisation fest. Epics definieren, was die Organisation in den nächsten 18 Monaten abschließen möchte. Das Management besitzt den Plan und kalibriert ihn alle sechs Monate.

Die Vision wird auf einer All-Hands-Besprechung vorgestellt. Da die Vision ehrgeizig sein soll und sich in diesem Zeitraum viel ändern kann, können Sie damit rechnen, dass Sie etwa 60 % der Vision erreichen.

Jahreszeit

Eine Saison wird durch Features beschrieben und legt die Strategie für die nächsten sechs Monate fest. Features bestimmen, was die Organisation für ihre Kunden beleuchten möchte. Das Management besitzt den Saisonplan und präsentiert die Vision und saisonal geplanten Pläne auf einer All-Hands-Besprechung. Alle Teampläne müssen mit dem Saisonplan des Managements übereinstimmen. Erwarten Sie, etwa 80 % des Saisonplans zu erreichen.

Plan mit 3 Sprints

Der Plan mit 3 Sprints definiert die Storys und Features, die das Team im Verlauf der nächsten 3 Sprints abschließen wird. Das Team besitzt den Plan und kalibriert ihn bei jedem Sprint. Jedes Team stellt dem Management seinen Plan über den Feature-Chat vor (siehe unten). Der Plan gibt an, wie die Ausführung des Teams mit dem 6-monatigen Saisonplan übereinstimmt. Erwarten Sie, dass sie etwa 90 % des Plans mit 3 Sprints erreichen werden.

Sprint-Plan

Der Sprint-Plan definiert die Storys und Features, die das Team beim nächsten Sprint abschließen wird. Das Team besitzt den Sprint-Plan und sendet ihn zur vollständigen Transparenz an die gesamte Organisation. Der Plan umfasst, was das Team im vergangenen Sprint erreicht hat und welche Schwerpunkte es für den nächsten Sprint festlegt. Erwarten Sie, dass sie etwa 95 % des Sprint-Plans erreichen werden.

Autonomieabfolge

In diesem Beispiel wird die Autonomieabfolge festgelegt, um zu zeigen, wo Teams die Planungsautonomie haben.

Wie oben erwähnt, erweitert das Management den Besitz nicht über die Grenze der Autonomie hinaus. Das Management bietet Anleitungen mithilfe der Vision- und Saisonpläne und gibt den Teams dann Autonomie, um Pläne mit 3 Sprints und Sprint-Pläne zu erstellen.

Feature-Chats: Wo Autonomie auf Ausrichtung trifft

Ein Feature-Chat ist eine informelle Besprechung, bei der jedes Team dem Management seinen Plan mit drei Sprints präsentiert. Diese Besprechung stellt sicher, dass Teampläne mit den Organisationszielen übereinstimmen. Es hilft dem Management auch, darüber informiert zu bleiben, was das Team tut. Während der Plan mit 3 Sprints bei jedem Sprint kalibriert wird, finden Feature-Chats nach Bedarf statt, normalerweise alle ein bis drei Sprints.

Eine Feature-Chat-Besprechung weist jedem Team 15 Minuten zu. Mit 12 Feature-Teams können diese Besprechungen etwa drei Stunden dauern. Jedes Team bereitet eine Präsentation mit den folgenden drei Folien vor:

Features

Die erste Folie beschreibt die Features, die das Team in den nächsten drei Sprints beleuchtet.

Schulden

Die nächste Folie beschreibt, wie das Team technische Schulden verwaltet. Schulden sind alles, was die Qualitätsindikatoren des Managements nicht erfüllt. Der Leiter des Engineerings legt die Qualitätsindikatoren fest, die für alle Teams gleich sind (Ausrichtung). Beispiele für Qualitätsindikatoren sind die Anzahl der Fehler pro Ingenieur, der Prozentsatz der bestandenen Komponententests und Leistungsziele.

Probleme und Abhängigkeiten

Die auf der endgültigen Folie aufgeführten Probleme und Abhängigkeiten umfassen alles, was sich auf den Teamfortschritt auswirkt, z. B. Probleme, die das Team nicht lösen kann, oder Abhängigkeiten von anderen Teams, die eine Eskalation benötigen.

Jedes Team präsentiert ihre Folien direkt dem Management. Das Team präsentiert, wie ihr Plan mit 3 Sprints mit dem 6-monatigen Saisonplan übereinstimmt. Das Führungsteam stellt klärende Fragen und schlägt Richtungsänderungen vor. Sie können auch Nachverfolgungsbesprechungen anfordern, um umfassendere Probleme zu lösen.

Wenn der Plan eines Teams nicht den Erwartungen des Managements entspricht, kann das Management einen überarbeiteten Plan anfordern. In diesem seltenen Fall plant das Team einen zweiten Feature-Chat, um ihn zu überprüfen.

Vertrauen: Das Bindeglied, das Ausrichtung und Autonomie zusammenhält

Wenn Agile im großen Maßstab praktiziert wird, ist Vertrauen keine Einbahnstraße:

• Das Management muss darauf vertrauen, dass die Teams das Richtige tun. Wenn das Management den Teams nicht vertraut, wird es den Teams keine Autonomie gewähren.

• Ein Team gewinnt Vertrauen, indem es kontinuierlich qualitativ hochwertigen Code liefert. Wenn Teams nicht vertrauenswürdig sind, gibt ihnen das Management keine Autonomie.

Das Management muss den Teams klare Pläne zur Verfügung stellen, an denen sie sich orientieren können, und ihnen dann die Umsetzung zutrauen. Teams müssen ihre Pläne mit der Organisation abstimmen und auf vertrauenswürdige Weise ausführen.

Wenn Unternehmen Agile auf größere Szenarien skalieren möchten, liegt der Schlüssel darin, den Teams Autonomie zu geben und gleichzeitig sicherzustellen, dass sie an den Unternehmenszielen ausgerichtet sind. Die kritischen Bausteine sind klar definierter Besitz und eine Vertrauenskultur. Sobald eine Organisation diese Grundlage eingerichtet hat, werden sie feststellen, dass die Agile-Methode sich sehr gut skalieren lässt.

Nächste Schritte

Für ein Team jeder Größe gibt es heute viele Möglichkeiten, Vorteile zu erzielen. Sehen Sie sich einige dieser Methoden an, die skaliert werden.

Erfahren Sie mehr über Azure DevOps-Features für Portfolioverwaltung und teamübergreifende Sichtbarkeit.

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