Freigeben über

Fördern einer Agile-Kultur in Ihrem Team

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Wenn Ihr Team wächst, möchten Sie, dass Ihre Tools mit ihm wachsen. Wenn Sie ein Unternehmen sind, das Agile-Methoden verwendet, möchten Sie, dass Ihre Agile-Tools die Geschäftsziele Ihres Unternehmens unterstützen.

Die erfolgreiche Skalierung von Agile erfordert jedoch, dass Sie sowohl die Kultur als auch die Tools in Ihrer Organisation ansprechen.

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. Unternehmen benötigen eine Ausrichtung zwischen Teams und der Organisation, um effizient zu sein.

Zu viel Ausrichtung mit unzureichender Teamautonomie erstickt Innovation und verhindert, dass Teams agile arbeiten, um Aufgaben auszuführen. Zu wenig Ausrichtung mit jedem Team, das sein eigenes Programm ausführt, verhindert den Einblick und die Koordination, die für die Erfüllung von Geschäftszielen erforderlich ist.

Mit der richtigen Ausrichtung in der gesamten Organisation und Teamautonomie können Sie Einzelpersonen in die Lage versetzen, innovationen zu entwickeln und sie dazu zu inspirieren, zusammenzuarbeiten, um geschäftsziele zu erreichen.

Erstellen einer Ausrichtung

Berücksichtigen Sie beim Planen Ihres erweiterten Agile-Toolsatzes die folgenden Bereiche. Diese Bereiche helfen Ihnen bei der Erstellung der Unternehmensausrichtung bei der Entwicklung der Teamautonomie.

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 als Epen und Features definieren, die im Portfolio-Backlog angezeigt werden.

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.

Innerhalb von Teams sollten Sie einige Rollen einrichten, z. B. Product Owner und Entwicklungsleitende, aber auch Raum für Rollenwechsel bieten. 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 der konstanten Dauer zwischen zwei und vier Wochen – umfasst planung, ausführen, Wert liefern, reflektieren und kontinuierlich verbessern.

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.
Einige Teams können in kürzeren Sprints arbeiten. Wenn eine Organisation z. B. einen 2-wochenigen Sprintrhythmen festlegt, können einige Teams sich für den Betrieb in 1-Wochen-Sprints entscheiden und gleichzeitig den Organisationszeitplan einhalten.

Kommunikationsrhythmus

Ebenso wie Sprints einen natürlichen Rhythmus zum Arbeitsfluss bringen, tun auch regelmäßige Kommunikationen. 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 Sprintleistungen und der nächsten Sprintpläne enthalten oder eine Demo der kürzlich abgeschlossenen 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. Sie können die Kriterien definieren, indem Sie Beendigungskriterien für neue Featureentwicklung, Standards zum Verwalten von technischen Schulden und Bug Caps für Teams oder Einzelpersonen festlegen.
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 Bug-Bashing-Veranstaltungen für neue Features oder am Ende jedes Sprints veranstalten. Sie können eine Person auswählen, die im Rotationsverfahren als Bug-Abwehr 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. Teams können z. B. ein Backlog-Element hinzufügen, um eine Abhängigkeit nachzuverfolgen, die sie in einem anderen Team haben. Oder sie können ihre Risiken über eine 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.

Diagramm mit horizontalen und vertikalen Teams.

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. Beispielsweise organisiert Fabrikam Fiber ihre Teams in den folgenden sieben Featureteams.

Diagramm mit sieben Funktionsteams: Shopping cart, Customer profile, Service status, Email, Voice, Internet und TV

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 bereitzustellen, mit denen sie diese Unterstützung konfigurieren und verwalten können, wie sie arbeiten möchten. Zu diesen Tools gehören Produkt-Backlogs, 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. Portfolio-Backlogs ermöglichen es Ihnen, Backlogelemente unter Features und Epics zu 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: Sie können den Fortschritt in allen Teams einfacher anzeigen.
  • Nachverfolgung und Prüfung: Sie können Arbeitsaufgaben einfacher mit anderen Objekten verknüpfen , um Nachverfolgungs- und Prüfungszwecke zu unterstützen.
  • Wartbarkeit: Sie minimieren die Wartung von Sicherheitsgruppen und Prozessupdates.

Weitere Informationen finden Sie unter Informationen zu Projekten und Skalieren Ihrer organization.

Verwandte Inhalte

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:

Branchenressourcen für Agile-Kultur

  • Last updated on