Fördern einer Agile-Kultur in Ihrem Team
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Wenn Ihr Team wächst, möchten Sie, dass Ihre Tools mit ihm wachsen. Und wenn Sie ein Unternehmen sind, das Agile-Methoden verwendet, möchten Sie, dass Ihre Agile-Tools die Geschäftsziele Ihres Unternehmens unterstützen.
Für eine erfolgreiche Skalierung von Agile müssen Sie jedoch sowohl bei der Kultur als auch bei den Tools innerhalb Ihres Unternehmens ansetzen.
Hinweis
Neu bei Agile? Weitere Informationen finden Sie unter Agile Kultur und Skalierung von Agile für große Teams.
Autonomie ermöglichen
Organisationen, die agile sein möchten, müssen der doppelten Verpflichtung Rechnung tragen, sowohl Orientierung im gesamten Unternehmen zu schaffen als auch die Teamautonomie zu unterstützen. Ein Team benötigt Autonomie, um effizient zu sein. Und Unternehmen sind auf Abstimmung über Teamgrenzen und in der gesamten Organisation angewiesen, um effizient zu sein.
Eine zu große Abstimmung mit unzureichender Teamautonomie unterstützt weder Innovation noch die Agilität von Teams beim Erledigen von Aufgaben. Eine zu geringe Abstimmung, bei der jedes Team sein eigenes Programm verfolgt, bietet nicht die erforderlichen Erkenntnisse und die Koordination, die zum Erreichen der Geschäftsziele erforderlich sind.
Mit dem richtigen Maß an Abstimmung innerhalb der Organisation und Teamautonomie können die Mitarbeiter Innovationen entwickeln und inspiriert zusammenarbeiten, um Geschäftsziele zu erreichen.
Erstellen einer Ausrichtung
Berücksichtigen Sie beim Planen Ihres erweiterten Agile-Toolsatzes die folgenden Bereiche. Diese Bereiche stellen den Schlüssel bei der Schaffung von Unternehmensausrichtung und der Entwicklung von Teamautonomie dar.
Bereich
Erstellen einer Ausrichtung
Unterstützen von Autonomie
Produktvision
Die Organisation definiert die Ziele und die Roadmap für die Organisation. Sie können Ziele können als Epics und Features definieren, die im Portfoliobacklog vorkommen.
Ein Team bestimmt, wie die Roadmap am besten erfüllt wird. Teams unterteilen Ziele mithilfe ihrer Teambacklogs in User Stories oder Produktbacklogelemente.
Teamstruktur
Basierend auf Geschäftszielen bestimmen Organisationen die Anzahl und Größe von Teams. Vertikal strukturierte Featureteams führen zu mehr Autonomie und Effizienz.
Bei Teams sollte es einige etablierte Rollen geben, z. B. Produktbesitzer und Entwicklungsleiter, aber auch Raum zum Rollenwechsel. Teammitglieder können beispielsweise abwechselnd als Scrum Master fungieren, Sprint-Demos entwickeln, Sprint-Retrospektiven ausführen oder Sprint-E-Mails erstellen.
Entwicklungsrhythmus
Agile-Organisationen müssen Produkte und Featureupdates in regelmäßigen Abständen veröffentlichen. Die Festlegung regelmäßiger Release- und Sprintzeitpläne fördert den Rhythmus des Geschäfts.
Jeder Sprint – eine zeitgesteuerte Iteration mit konstanter Dauer zwischen zwei und vier Wochen – umfasst Planung, Ausführung, Wertschöpfung, Reflexion und die Verpflichtung zu kontinuierlicher Verbesserung.
Alle Teams verwalten ihre Arbeit innerhalb des festgelegten Sprintrhythmus. Teams liefern Input zur Länge der Sprints, die für sie am besten funktioniert.
Teams wählen die Agile-Methoden, die sich für sie eignen, Scrum, Kanban oder eine Mischung aus beidem. Teams übernehmen auch die Verantwortung für das Einrichten und Verfolgen ihrer eigenen Methoden zur kontinuierlichen Verbesserung.
Für manche Teams besteht die Möglichkeit, in kürzeren Sprints zu arbeiten. Wenn beispielsweise eine Organisation einen Sprintrhythmus von 2 Wochen festlegt, können sich einige Teams dafür entscheiden, in 1-Wochen-Sprints zu arbeiten, während sie sich weiterhin an dem Zeitplan der Organisation orientieren.
Kommunikationsrhythmus
So wie Sprints einen natürlichen Rhythmus in den Arbeitsablauf bringen, gilt dies auch für regelmäßige Kommunikation. Indem sie Erwartungen für die Art und Häufigkeit der Kommunikation festlegen, die sie eingehalten sehen möchten, um die Abstimmung sicherzustellen, schaffen Organisationen auf natürliche Weise eine Ausrichtung über Teamgrenzen hinweg und im gesamten Unternehmen.
Team-Sprint-E-Mails, der Status von Fehlerleisten und der Releaselieferstatus von Featureteams sind Beispiele für eine solche regelmäßige Kommunikation.
Ein Team bestimmt die Details, die sie kommunizieren und wer die Kommunikation entwickelt. Ihre Sprint-E-Mails können eine Zusammenfassung früherer Sprinterfolge und kommender Sprintpläne oder eine Demo der kürzlich fertig gestellten Features enthalten.
Qualität
Jede Organisation muss die Kriterien und Standards festlegen, anhand derer die Qualität bewertet wird, und die Erwartungen an Qualitätsstandards festlegen. Einige Möglichkeiten, die Kriterien zu definieren, sind das Festlegen von Beendigungskriterien für die Entwicklung neuer Features, Standards für die Verwaltung technischer Schulden und Fehlerobergrenzen für Teams oder Einzelpersonen.
Außerdem können Fehlerstatus und Trends durch das Erstellen von Fehlerdashboards überwacht werden.
Ein Team wählt aus, wie es die Qualitätsstandards erfüllt. Sie können Initiativen zur Fehlerbeseitigung für neue Features oder am Ende jedes Sprints vorschreiben. Sie können eine Person bestimmen, die auf rotierender Basis als Fehlerabwehr fungiert.
Verwalten des Risikos, Nachverfolgen der Arbeit
Die Organisation bestimmt, wie die einzelnen Funktionseinheiten Status und Risiken kommunizieren. Sie schließen einen „Kommunikationsvertrag“ über die mindestens erforderlichen Informationen ab, die die Organisation benötigt.
Außerdem stellt die Organisation die Infrastruktur bereit, um Risiken zu reduzieren. Die Organisation schuldet den Teams alles in ihrer Macht stehende, um die allen Teams gemeinsamen Risiken zu verringern.
Über die Erfüllung der von der Organisation festgelegten Anforderungen hinaus bestimmen die Teams alle weiteren Details, die sie zur Risikominimierung verwalten und nachverfolgen müssen. Gleich, ob sie dazu ein Whiteboard mit Haftnotizen oder ein ausgewachsenes Gantt-Diagramm verwenden, die Verwaltung der Details liegt bei ihnen. Beispielsweise können Teams ein Backlogelement hinzufügen, um eine Abhängigkeit von einem anderen Team nachzuverfolgen. Oder sie können ihre Risiken anhand einer Liste von Problemen oder Hindernissen nachverfolgen. Außerdem tragen die Teams regelmäßig zur Verbesserung des Prozesses und der Infrastruktur bei, um die Fähigkeit der Organisationen zu unterstützen, Risiken zu verwalten und Erkenntnisse zu gewinnen.
Struktur von Teams
Bei der Skalierung besteht eine der wichtigsten Aufgaben in der Abwägung, wie Ihre Teams strukturiert sein sollen. Herkömmliche horizontale Teamstrukturen teilen Teams entlang der Softwarearchitektur auf: Teams für Benutzeroberfläche, dienstorientierte Architektur und Daten.
Mit der Einführung agiler Methoden sind vertikale Teamstrukturen, welche die Architektur ausmachen, der größte Beitrag zur Teamautonomie. Vertikale Teams können die Features, die sie besitzen, bereitstellen, indem sie über die gesamte Softwarearchitektur hinweg arbeiten. Sie verbreiten außerdem das Wissen, das für die Arbeit auf allen Architekturebenen erforderlich ist, in allen Teams.
Konfigurieren Sie Ihre Teams entlang der Wertströme, die Ihre Organisation realisieren möchte. Fabrikam Fiber strukturiert seine Teams beispielsweise in die folgenden sieben Featureteams.
Jedes Team plant die bereitzustellenden Features. Es hat die Autonomie, zu bestimmen, wie es die Daten strukturieren, die Dienste konzipieren und die Web- und mobilen Benutzeroberflächen gestalten will. Es plant unter Einhaltung der Qualitätsstandards der Organisation, zu denen alle Teams beitragen.
Konfigurieren Ihrer Agile-Tools für die Skalierung
Wenn Ihr Organisation wächst, können Sie Ihre Agile-Tools wie folgt skalieren.
Hinzufügen von Teams und gefilterten Backlogansichten: Sie fügen Teams hinzu, um die Teamautonomie zu unterstützen und ihnen die Tools zur Verfügung zu stellen, die ihre Arbeit unterstützen – Konfiguration und Verwaltung liegt bei den Teams. Diese Tools umfassen Produktbacklogs, Kanban-Boards, Sprint-Backlogs, Taskboards und andere.
Außerdem können Sie Teams so konfigurieren, dass sie eine Hierarchie von Backlogs und Portfoliobacklogs unterstützen, sodass Portfoliomanager Priorität und den Fortschritt über mehrere Teams hinweg überprüfen können.
Einrichten von Sprints und Releases: Sie können Ihre Iterationen so strukturieren, dass sie einen Satz flacher Sprints oder eine Reihe von Sprints unterstützen, die in geplante Releases eingebettet sind. Jedes Team aktiviert die Sammlung von Sprints und Releases, an denen es teilnehmen muss.
Verwalten von Portfolios: Durch Einrichten einer Hierarchie von Teams und Backlogs und Aktivieren von Portfoliobacklogs. Featureteams, die sich auf eine Teilmenge des Produktbacklogs konzentrieren, können sich weiterhin nur auf ihr Backlog konzentrieren. Portfoliomanager, die Backlogs anzeigen und strukturieren möchten, um Fortschritt und Abhängigkeiten nachzuverfolgen, können Portfoliobacklogs von Features und Epics verwalten.
Wenn Sie weitere Portfoliobacklogs benötigem, z. B. Szenarien oder Initiativen, können Sie diese ebenfalls hinzufügen.
Konfigurieren von Dashboards: Mit Teamdashboards können Sie Diagramme konfigurieren, die den Fortschritt innerhalb eines Teams oder teamübergreifend nachverfolgen. Insbesondere können Sie Status- und Trenddiagramme basierend auf Ihren eigenen Abfragen hinzufügen.
Gruppieren oder Kategorisieren von Arbeit: Es gibt mehrere Möglichkeiten, die Arbeiten zu gruppieren, die Sie nachverfolgen möchten. Backlogs filtern Arbeitselemente auf der Grundlage von Teambereichszuweisungen. Mit Portfoliobacklogs können Sie Backlogelemente unter Features und Epics gruppieren.
Wenn Sie Arbeitselemente anhand anderer Gruppierungen nachverfolgen und erfassen möchten, steht Ihnen nichts im Wege. Sie können Arbeitselementen Tags hinzufügen und dann Backlogs oder Abfragen nach Tags filtern. Außerdem können Sie Unterbereichspfade hinzufügen, um Featurebereiche präziser darzustellen.
Hinzufügen von Ordnern und Verwenden von Teamfavoriten: Wenn Ihre Teams wachsen, ergibt sich eine wachsende Liste von Arbeitselementabfragen, Builddefinitionen und Quellcodeordnern. Mithilfe von Ordnern, Unterordnern und Teamfavoriten können Sie viele dieser Listen einfacher verwalten. Sie können Teamfavoriten für freigegebene Abfragen, Quellcode und Builddefinitionen hinzufügen.
Skalieren mit Teams anstelle von Projekten
Oftmals ziehen Organisationen für jedes Softwareentwicklungsprojekt das Hinzufügen eines Projekts in Betracht.
Es wird empfohlen, Teams hinzuzufügen, um Ihre Tools zu skalieren, anstatt Projekte aus den folgenden Gründen hinzuzufügen:
- Sichtbarkeit: Es ist einfacher, den Fortschritt teamübergreifend anzuzeigen
- Nachverfolgung und Überwachung: Es ist einfacher, für Nachverfolgungs- und Überwachungszwecke Arbeitselemente und andere Objekte zu verknüpfen
- Wartbarkeit: Sie minimieren die Wartung von Sicherheitsgruppen und Prozessupdates.
Weitere Informationen finden Sie unter Informationen zu Projekten und Skalieren Ihrer organization.
Verwandte Artikel
Bevor Sie eins der Agile-Tools erstellen oder damit arbeiten können, benötigen Sie ein Projekt. Wenn Sie noch kein Projekt haben, können Sie ein neues Projekt erstellen.
Wenn Sie bereit sind, von einem Team auf zwei Teams umzustellen oder mehrere Teams zu konfigurieren, lesen Sie Hinzufügen von Teams. Informationen zum Hinzufügen eines Teamadministrators oder zum Konfigurieren von Teamressourcen finden Sie unter Verwalten von Teams und Konfigurieren von Teamtools.
Weitere Informationen und Beispiele finden Sie in diesen Artikeln:
- Skalierbare Praktiken
- Teamübergreifende Sichtbarkeit
- Überprüfen der Teamlieferpläne
- Implementieren von Scaled Agile Framework® zum Unterstützen von Epics, Releaseplänen und mehreren Backlogs.