Skalieren von Agile auf große Teams

Die Wörter "Groß " und "Agile " werden nicht häufig in demselben Satz verwendet. Große Organisationen haben den Ruf verdient, langsam zu sein. Das ändert sich jedoch. Viele große Softwareorganisationen machen die Transformation zu Agile erfolgreich. 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 Featureteams, die alle drei Wochen für die Produktion freigegeben werden.

Jedes Team in Azure DevOps verfügt über Features von Anfang bis Ende und darüber hinaus. Sie besitzen ihre eigenen Kundenbeziehungen. Sie verwalten ihren eigenen Produktrückbestand. Sie schreiben und überprüfen Code in den Produktionszweig. Alle drei Wochen wird der Produktionszweig bereitgestellt, und die Veröffentlichung wird öffentlich. Die Teams überwachen dann die Systemintegrität und beheben Live-Site-Probleme.

Nach agilen Prinzipien sind autonome Teams produktiver. Eine Agile-Organisation möchte, dass ihre Teams die Kontrolle über ihre tägliche Ausführung haben. Aber Autonomie ohne Ausrichtung würde zu Chaos führen. Dutzende von Teams, die unabhängig arbeiten, würden kein einheitliches, qualitativ hochwertiges Produkt produzieren. Die Ausrichtung gibt Teams ihren Zweck und stellt sicher, dass sie organisatorische Ziele erfüllen. 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 an die Organisation sicherstellen.

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

Definieren einer Taxonomie

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 es schwer haben, erfolgreich zu sein, wenn unternehmensweite Ziele unklar sind.

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

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

Epics

Epics beschreiben Initiativen, die für den Erfolg der Organisation wichtig sind. Epen werden von mehreren Teams über mehrere Sprints hinweg vollendet, aber sie haben ein Ende. Epics haben ein klar definiertes Ziel. Sobald das Epos erreicht wurde, ist das Epos abgeschlossen. Die Anzahl der laufenden Epen sollte verwaltbar sein, um die Organisation fokussiert zu halten. Epics sind in Features unterteilt.

Features

Features definieren neue Funktionen, die erforderlich sind, um ein episches 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. Features können mehrere Sprints zur Fertigstellung benötigen, sollten jedoch umfangsmäßig geplant werden, um einen konsistenten Wertfluss für den Kunden zu gewährleisten. Features werden in Benutzer-Geschichten unterteilt.

Geschichten

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 Geschichte bietet dem Kunden möglicherweise keinen bedeutenden Wert. Eine abgeschlossene Geschichte stellt jedoch produktionsqualitätsbasierte Software dar. Geschichten sind die Arbeitseinheit des Teams. Das Team definiert die zum Abschließen eines Features notwendigen Geschichten. Geschichten können optional in Aufgaben unterteilt werden.

Aufgaben

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

Initiativen

Diese Taxonomie ist kein 1-size-fits-all-System. Viele Organisationen führen eine Ebene über Epen ein, die als Initiativen bezeichnet werden.

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

Autonomiebereich

Sobald eine Taxonomie festgelegt ist, muss die Organisation eine Linie der Autonomie ziehen. Die Autonomielinie ist der Punkt, an dem der Besitz der Ebene vom Management an das Team übergeht. Das Management mischt sich nicht in die Bereiche ein, die dem Team gehören.

Das folgende Beispiel zeigt die Linie der Autonomie, die unter den Features gezeichnet wird. Das Management besitzt Epen und Features, die Ausrichtung bieten. Teams besitzen Geschichten und Aufgaben und haben Autonomie darüber, wie sie ausgeführt werden.

In diesem Beispiel teilt die Verwaltung dem Team nicht mit, wie Sie Geschichten dekompilieren, Sprints planen oder Arbeiten ausführen können.

Das Team muss jedoch sicherstellen, dass ihre Ausführung den Zielen des Managements entspricht. Während ein Team seinen Backlog von Geschichten besitzt, müssen sie ihren Backlog mit den ihnen zugewiesenen Features ausrichten.

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 Rollwellenplanung bezeichnet.

Der Plan bietet eine Richtung für einen festen Zeitraum mit erwarteter Kalibrierung in regelmäßigen Abständen. Beispielsweise könnte ein 18-monatiger Plan alle sechs Monate kalibriert werden.

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

Vision

Die Vision wird durch Epen ausgedrückt und setzt die langfristige Richtung der Organisation. 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 bei einem Teammeeting vorgestellt. Da die Vision ehrgeizig sein soll und sich viel in diesem Zeitraum ändern kann, erwarten Sie, etwa 60% der Vision zu 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 aufhellen möchte. Das Management verantwortet den Saisonplan und präsentiert die Vision und saisonale Pläne auf einer Mitarbeiterversammlung. Alle Teampläne müssen mit dem Saisonplan des Managements übereinstimmen. Erwarten Sie, etwa 80% des Saisonplans zu erreichen.

3-Sprint-Plan

Der 3-Sprint-Plan definiert die Geschichten und Features, die das Team über die nächsten drei Sprints abschließen wird. Das Team besitzt den Plan und kalibriert ihn jeden Sprint. Jedes Team präsentiert seinen Plan zur Verwaltung über den Featurechat (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 für drei Sprints erreichen.

Sprintplan

Der Sprintplan definiert die Geschichten und Features, die das Team im nächsten Sprint abschließen wird. Das Team besitzt den Sprintplan und sendet ihn zur vollständigen Transparenz an die gesamte Organisation. Der Plan umfasst, was das Team im vergangenen Sprint erreicht hat und worauf es sich im nächsten Sprint konzentrieren wird. Erwarten Sie, etwa 95% des Sprintplans zu erreichen.

Autonomiegrenze

In diesem Beispiel wird die Autonomielinie gezeichnet, um zu zeigen, wo Teams die Planungsautonomie haben.

Wie oben erwähnt, erweitert das Management das Eigentum nicht unter die Autonomie. Das Management bietet mithilfe der Visions- und saisonalen Pläne Anleitung und gibt den Teams dann die Autonomie, 3-Sprint- und Sprint-Pläne zu erstellen.

Feature-Chats: Wo Autonomie auf Ausrichtung trifft

Ein Featurechat ist eine informelle Sitzung, bei der jedes Team seinen 3-Sprint-Plan dem Management vorstellt. Diese Besprechung stellt sicher, dass Teampläne mit den Organisationszielen übereinstimmen. Außerdem hilft es dem Management, über das, was das Team tut, auf dem Laufenden zu bleiben. Während der 3-Sprint-Plan jeden Sprint kalibriert wird, werden Feature-Besprechungen bei Bedarf gehalten, in der Regel alle ein bis drei Sprints.

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

Features

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

Schuld

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). Beispielqualitätsindikatoren umfassen die Anzahl der Fehler pro Techniker, den Prozentsatz der Komponententests, die bestanden werden, 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 der Verwaltung. Das Team präsentiert, wie ihr 3-Sprint-Plan mit dem 6-monatigen Saisonplan übereinstimmt. Die Führung stellt klärende Fragen und schlägt Änderungen der Richtung vor. Sie können auch Nachverfolgungsbesprechungen anfordern, um tiefere Probleme zu lösen.

Wenn der Plan eines Teams nicht den Erwartungen des Managements entspricht, kann das Management einen Erneutplan anfordern. In diesem seltenen Fall wird das Team eine zweite Feature-Besprechung planen und ansetzen, um diese zu überprüfen.

Vertrauen: Der Klebstoff, der Ausrichtung und Autonomie zusammenhält

Beim Skalieren von Agile ist Vertrauen eine gegenseitige Angelegenheit:

• Das Management muss Teams vertrauen, um das Richtige zu tun. Wenn das Management den Teams nicht vertraut, wird es den Teams keine Autonomie geben.

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

Das Management muss klare Pläne bereitstellen, an denen sich die Teams orientieren können, und dann darauf vertrauen, dass ihre Teams diese ausführen. Teams müssen ihre Pläne an die Organisation ausrichten und auf vertrauenswürdige Weise ausführen.

Da Organisationen agile auf größere Szenarien skalieren möchten, besteht der Schlüssel darin, Teams Autonomie zu geben und gleichzeitig sicherzustellen, dass sie an die Organisationsziele ausgerichtet sind. Die kritischen Bausteine sind klar definierten Besitz und eine Vertrauenskultur. Sobald eine Organisation diese Grundlage eingerichtet hat, werden sie feststellen, dass Agile sehr gut skalieren kann.

Nächste Schritte

Es gibt viele Möglichkeiten für ein Team jeder Größe, um schon heute von Vorteilen zu profitieren. Sehen Sie sich einige dieser Praktiken an, die skalierbar sind.

Erfahren Sie mehr über Azure DevOps-Funktionen für Portfolioverwaltung und teamsübergreifende Sichtbarkeit.

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