Agile Skalierung mit Microsoft Azure DevOps

Agile Frameworks haben sich oft auf Teamebene bewährt, wenn kleine Teams (3-9 Personen) an einem Ort (Distanz < 10m) an einem Produkt arbeiten. In der Praxis ist diese Konstellation selten anzutreffen. Zum einen lassen sich Produkte häufig nicht mit einem kleinen Team entwickeln, sodass die Arbeit einer wesentlich größeren Zahl von Personen koordiniert werden muss (vertikale Skalierung). Darüber hinaus sind Teams häufig nicht an einem Ort. Die Arbeit über verschiedene Standorte hinweg (horizontale Skalierung) ist ebenso verbreitet. 

Am Markt sind diverse Frameworks verfügbar (u.a. SAFe, Less, Nexus, Scrum of Scrums, Scrum@Scale, Disciplined Agile Delivery). Sie dienen als Unterstützung, um die Herausforderungen der Skalierung zu meistern. Aus unserer Sicht empfiehlt es sich die Frameworks vor allem als Inspiration zu verstehen und weniger als Blaupause im Rahmen einer 1-zu-1 Umsetzung. Skalierte Umgebungen stellen die Teams häufig vor große methodische und technische Herausforderungen. 

Über alle Frameworks hinweg haben sich folgende Erfolgskriterien für skalierte Umgebungen herausgestellt:

1. Co-Location sicherstellen
2. Unmittelbarer Kontakt zwischen dem Team, den Kunden und sonstigen Stakeholdern
3. Ein übergreifender, einheitlicher Sprintzyklus für alle Teams
4. Ein gemeinsames Backlog mit einem verantwortlichen Product Owner
5. Schulung der Mitarbeiter zu Agilität, DevOps und technischer Exzellenz (Architekturen, CI/CD Pipelines, Test Management, Release Management)
6. Reduzierung von Abhängigkeiten zwischen Teams und Features
7. Transparenz über alle Ebenen und Teamgrenzen hinweg

Um diesen Herausforderungen zu begegnen, bietet Microsoft Azure DevOps viele hilfreiche Features, die wir Ihnen nachfolgend vorstellen wollen.
 

Wie kann Microsoft Azure DevOps helfen?
 

Idealerweise hält sich das Team in einem Umkreis von 10m auf. In einem solchen Umfeld lässt sich Wissen am besten teilen oder "zufällig" aufgreifen. Die Hauptherausforderung in verteilten Teams ist also die Kommunikation. Durch die Integration von Microsoft Azure DevOps in Microsoft Teams sowie die Unterstützung der gesamten Prozesskette vom Anforderungsmanagement bis zum Deployment reduziert die Arbeit mit Microsoft Azure DevOps die Herausforderungen verteilter Teams.  

Microsoft Azure DevOps unterstützt von Haus aus die Zusammenarbeit von unterschiedlichen und verteilten Teams durch die Verfügbarkeit in der Microsoft Cloud. Eine lokale Softwareinstallation ist weder möglich noch erforderlich. Der Einstieg in die Nutzung von Microsoft Azure DevOps ist bewusst einfach gehalten, sodass auch Stakeholder, die nicht direkt mit der Entwicklung betraut sind, auf Microsoft Azure DevOps als Informationsplattform zurückgreifen können. 
Weiterhin wird eine offene, ebenen- und teamübergreifende Zusammenarbeit unterstützt. Die Projektdokumentation, Produktbeschreibungen oder Architekturskizzen lassen sich beispielsweise im Wiki zentral verwalten.

Die Microsoft Teams Integration erlaubt direkt aus Microsoft Teams auf Work Items zu referenzieren oder Änderungen an Work Items im Teams Channel zu abonnieren. Die Teammitglieder werden aktiv über Änderungen benachrichtigt, ohne eine weitere lästige E-Mail zu versenden. Diskussionen lassen sich aber auch durch Kommentare direkt im Work Item führen. 

Der Vorteil liegt auf der Hand: Weitreichende Transparenz über den aktuellen Stand des Produkts und der Arbeit des Teams.

Abhängigkeiten und Übergaben zwischen Teams gilt es weitestgehend zu vermeiden. Leider ist es selten möglich gänzlich auf sie zu verzichten. Zur Koordination mehrerer Teams sowie ihrer Abhängigkeiten sind einheitliche Sprintzyklen zu empfehlen.
In Microsoft Azure DevOps werden die Sprintzyklen bzw. Iterationen zentral in den Projekt-einstellungen verwaltet. Diese Zyklen dienen der übergreifenden Sprintplanung, auf die wiederum mehrere Teams referenzieren können. Auf diesem Weg wird sichergestellt, dass Teams in synchronisierten Iterationen ihren Scope abarbeiten.
 

Microsoft Azure DevOps unterstützt von Haus aus die Möglichkeit, ein zentrales Product Backlog über mehrere Teams zu nutzen oder aber auch mehrere Team Backlogs anzulegen. Hiermit lässt sich ein umfangreicher Produkt Scope mit verschiedenen Teams gemeinsam bearbeiten. Ein zentrales Backlog bietet den Vorteil, dass Abhängigkeiten zwischen Backlog Items einfacher erkannt werden, eine eindeutige Priorisierung transparent ist und die Delegation von Themen in die jeweiligen Teams leichter fällt. Je nach Anzahl der Teams, kann ein zentraler Product Owner schnell zum Engpass werden, ein Product Owner je Team kann hier sinnvoll sein und die Effizienz erhöhen.

Solch eine Umsetzung haben wir in Microsoft Azure DevOps über das Area Path Feature umgesetzt, welches es ermöglicht, ein zentrales Backlog gemeinsam mit mehreren Teams zu bearbeiten und gleichzeitig die Transparenz darüber zu behalten, welches Teams an welchen Themen arbeitet:
 

Die hier angelegten Area Path´ lassen sich nun nutzen, um Backlog-Items diesen zuzuordnen und so auf die verantwortlichen Teams zu referenzieren.

Um einen nachhaltigen Wissenstransfer sowie die Akzeptanz neuer Vorgehensmodelle, Arbeitsweisen in Teams oder auch der Arbeit mit einem neuen Tool zu erreichen, empfehlen wir die Einführung durch ein geeignetes Change Management zu begleiten. Das Kredo "A fool with tool is still a fool" gilt natürlich auch für Microsoft Azure DevOps. Aus unserer Erfahrung heraus haben sich Maßnahmen, wie die Etablierung einer Champion Community, ausgewiesene Coaches, die Etablierung von virtuellen oder Vor-Ort Trainings sowie vor allem das Vorleben der Nutzung von Tools und Prozessen durch Führungskräfte bewährt.

Agile Arbeitsweisen sind durch einen kontinuierlichen Verbesserungsprozess geprägt (PDCA - Plan Do Check Act). Am Ende einer jeden Iteration überprüft das Team, auch aggregiert über mehrere Teams hinweg, ihr Vorgehen in der Sprint Retrospektive. Gerade zu Beginn der Nutzung eines neuen Tools oder einen neues Prozessen empfehlen wir ein großes Augenmerk auf die Retrospektiven der durchgeführten Sprints zu legen, um frühzeitig Lerneffekte aus der eigenen Arbeitsweise, sei es bezogen auf die Methodik oder dem Tool, zu ziehen. Details zu den Möglichkeiten von Microsoft Azure DevOps im Zusammenhang mit Retrospektiven (als auch Sprint Reviews) finden Sie in einem unserer vorherigen Artikel zum Thema.

Abhängigkeiten zwischen Work Items können die Umsetzung erheblich erschweren und auch den Wert gelieferter Ergebnisse bzw. Inkremente reduzieren. Es empfiehlt sich daher, sich der Abhängigkeiten stets bewusst zu sein und diese nach Möglichkeit zu reduzieren. Helfen kann hierbei eine saubere Struktur in Form von Epics, Features und User Stories:

Zusätzliche Tools können helfen, die Abhängigkeiten im Blick zu behalten und effektiv zu verwalten. Zum einen können in Power BI individuelle Berichte erstellt werden, die Abhängigkeiten zwischen Items grafisch visualisieren. Zum anderen bietet der Azure Marketplace diverse, zum Teil kostenlose Erweiterungen an. Eine dieser Erweiterungen ist der Dependency Tracker, welcher es ermöglicht u.a. sowohl konsumierende als auch produzierende Abhängigkeiten übersichtlich darzustellen. Die Erweiterung bietet viele weitere nützliche Features, die bei komplexeren Projekten hilfreich sein können, um den Überblick zu bewahren.

Microsoft Azure DevOps steigert die Transparenz durch die enge Verzahnung aller Module - sei es die Overview, die Boards oder auch die automatisierten Test-, Build- und Deploymentprozesse. Richtig aufgesetzt und konfiguriert bietet Microsoft Azure DevOps hier vielen Stakeholder-Gruppen, die für Sie relevanten Sichten auf den Stand eines Projektes.

Insbesondere in der Softwareentwicklung können manuelle Aufwände zur Integration von Entwicklungsergebnissen aus mehreren Teams sowie Tests und Deployments massiv reduziert werden (vgl. dazu Artikel zu CI/CD). Da Microsoft Azure DevOps jedoch eher den Fokus auf die operative Steuerung und Umsetzung von Entwicklungsprojekten legt und agilen Teams vielfältige Mittel und Features an die Hand gibt, um Projekte effizient und transparent durchzuführen, bilden weitere Tools, die eher strategisch bzw. auf Portfolio-Ebene angesiedelt sind, eine sinnvolle Ergänzung. Weitere Möglichkeiten stellen bspw. die Abbildung hybrider Projektumgebungen dar, die sich aus klassischen Projekt- oder Portfolioelementen (Project for the Web, Project Online oder Project Server) mit agilen Tools wie Microsoft Azure DevOps vereinen. Dies ermöglicht gerade in großen Organisationen hohe Transparenz von der Managementebene mit Blick auf das Portfolio bis hinunter in die Projektdetails eines agil arbeitenden Teams (Top-Down und revers).