Dies ist ein Companion-Blog zum technischen Beitrag von Vanesco Böhm. Während der technische Artikel das «Wie» beleuchtet, fokussiert dieser Beitrag auf das «Warum» und «Wozu». Denn nachhaltiger Unternehmenserfolg entsteht dort, wo Technology Push und Business Pull zusammenwirken.
Azure DevOps ist keine To-do-Liste
Azure DevOps wird in vielen Organisationen ähnlich behandelt wie der Flugschreiber eines Flugzeugs: Man zeichnet zwar kontinuierlich und pflichtbewusst alle Daten im Hintergrund auf, nutzt sie aber erst retrospektiv, wenn es bereits zu Turbulenzen oder Lieferverzögerungen gekommen ist, statt sie zur aktiven, zukunftsgerichteten Navigation zu verwenden.
Dabei liegt genau hier eines der grössten Missverständnisse moderner Softwareorganisationen.
Das Management fordert Transparenz, Planbarkeit und belastbare Entscheidungsgrundlagen. Entwicklungsteams wünschen sich möglichst wenig Administration und maximale Freiheit für die eigentliche Wertschöpfung. Beide Seiten betrachten Azure DevOps oft als notwendiges Übel, als Werkzeug zur Verwaltung von Arbeit.
Dabei ist Azure DevOps weit mehr als eine digitale To-do-Liste oder eben ein Flugschreiber.
Es ist die Infrastruktur, auf der empirisches Management überhaupt erst möglich wird. Wer über die Struktur von Azure DevOps spricht, diskutiert nicht über Backlogs oder Work Items. Er diskutiert über die Architektur der Empirie.
Führen über Zahlen setzt Struktur voraus
Viele Organisationen möchten ihre Entscheidungen datenbasiert treffen. Begriffe wie Velocity, Throughput oder Cycle Time gehören mittlerweile zum Standardvokabular von Organisationen, die sich z.B. im Spektrum von Business-Agilität und Lean Management weiterentwickeln.
Doch Kennzahlen haben eine unangenehme Eigenschaft: Sie sind nur so gut wie die Daten, auf denen sie beruhen.
Eine Organisation kann noch so viele Dashboards bauen. Wenn Teams unterschiedliche Strukturen verwenden, Work Items unterschiedlich interpretieren oder Projekte historisch gewachsen sind, entsteht lediglich eine sehr professionell visualisierte Form von Unvergleichbarkeit und Unsicherheit.
Vergleichbarkeit entsteht nicht durch Reporting. Vergleichbarkeit entsteht durch Konsistenz.
Eine saubere Trennung von Area Paths und Iterations ermöglicht es beispielsweise, Entwicklungen über Teams und Produkte hinweg nachvollziehbar zu machen. Erst dadurch lassen sich Veränderungen im Zeitverlauf messen.
- Hat das neue Team-Setup tatsächlich die Lieferfähigkeit verbessert?
- Hat die organisatorische Umstellung den Durchsatz erhöht?
- Sind die Wartezeiten gesunken oder verschoben sich Probleme lediglich an andere Stellen?
Ohne konsistente Struktur bleiben solche Fragen Meinungen bzw. isolierte Erkenntnisse. Mit einer durchdachten Struktur werden sie zielführend messbar. Und genau dort beginnt empirisches Management.
Governance ist kein Selbstzweck
Sobald Organisationen erkennen, dass Struktur wichtig ist, folgt häufig die nächste Fehlannahme. Man versucht, die perfekte Struktur von oben herab zu definieren. Es entstehen Prozessrichtlinien, Frameworks und Governance-Dokumente, die jede denkbare Situation antizipieren sollen.
Die Realität zeigt sich davon meist wenig beeindruckt. Komplexe Systeme folgen selten einem Architekturdiagramm – wir erinnern uns an die Erkenntnisse, die im Cynefin-Modell kompakt zusammengestellt sind.
Neue Produkte entstehen. Teams verändern sich. Verantwortlichkeiten verschieben sich. Geschäftsmodelle entwickeln sich weiter. Wer glaubt, diese Dynamik vollständig vorausplanen zu können, überschätzt häufig die Vorhersagbarkeit seiner Organisation.
Struktur sollte deshalb dort entstehen, wo echte organisatorische Grenzen oder geschäftliche Anforderungen existieren und nicht dort, wo ein Governance-Gremium möglichst viele Kästchen in einem Organigramm oder Arbeitsschritte in einem Prozess entdeckt hat.
Oft bewirken kleine Anpassungen im Tooling mehr als grosse Prozessinitiativen. Geschickt eingesetzt können wir solche Anpassungen nutzen, um im Sinne des «Nudgings» niederschwellig reale Veränderungen zu unterstützen.
Die Entscheidung zwischen einem Tag, einem Area Path oder einem eigenen Work Item Type erscheint zunächst technisch. In der Praxis beeinflusst sie jedoch direkt, wie Menschen arbeiten, kommunizieren und Entscheidungen treffen. Gutes Tooling schafft keine Regeln. Es setzt Anreize. Und gute Anreize erzeugen häufig bessere Ergebnisse als zusätzliche Vorschriften.
Tech Insights by bbv
Designing Azure DevOps Projects for Real-World Complexity
The most consequential Azure DevOps configuration decision you make is also the easiest to get wrong: how to structure your project.
Eine Wahrheit – mehrere Perspektiven
Die eigentliche Stärke einer durchdachten Azure DevOps Struktur liegt nicht in der Dokumentation von Arbeit. Sie liegt darin, dass unterschiedliche Stakeholder dieselben Daten aus unterschiedlichen Perspektiven betrachten können, ohne die gemeinsame Wahrheit zu verlieren.
Für Entwicklungsteams entsteht Transparenz über den eigenen Fortschritt. Verbesserungsmöglichkeiten werden sichtbar. Engpässe können identifiziert werden, bevor sie zu Problemen werden.
Für die Produktleitung entsteht ein konsolidierter Blick über mehrere Teams hinweg. Abhängigkeiten werden früher erkannt. Prioritäten lassen sich koordinieren. Entscheidungen basieren auf nachvollziehbaren Daten statt auf Eskalationen.
Für das Management entsteht etwas noch Wertvolleres: Planbarkeit. Nicht perfekte Vorhersagbarkeit. Nicht die Illusion vollständiger Kontrolle. Sondern die Fähigkeit, fundierte Entscheidungen auf Basis empirischer Erkenntnisse zu treffen.
Der Unterschied ist entscheidend. Gutes Reporting dient nicht dazu, einzelne Mitarbeitende zu überwachen. Es dient dazu, Muster sichtbar zu machen.
Die interessanteste Frage lautet selten: «Warum hat Person X diese Aufgabe noch nicht abgeschlossen?»
Die interessantere Frage lautet meist: «Warum benötigt unser System für solche Aufgaben regelmässig länger als erwartet?»
Die erste Frage führt zu Mikromanagement. Die zweite zu echter Verbesserung.
Die teuersten Fehler entstehen früh
Viele Architekturentscheidungen in Azure DevOps wirken anfangs überraschend harmlos.
Ein Projekt mehr.
Eine zusätzliche Struktur.
Ein Sonderfall für ein Team.
Eine Ausnahme für ein bestimmtes Produkt.
Jede einzelne Entscheidung erscheint vernünftig. Die Summe dieser Entscheidungen erzeugt jedoch häufig eine Landschaft, in der Daten nicht mehr konsistent ausgewertet werden können.
Das eigentliche Problem sind dabei selten die technischen Migrationskosten. Das Problem sind die verlorenen Erkenntnisse. Wenn historische Daten nicht mehr vergleichbar sind, gehen Jahre potenzieller Lernkurven verloren. Organisationen verlieren die Möglichkeit, Entwicklungen über längere Zeiträume hinweg zu analysieren und fundierte Verbesserungen abzuleiten.
Deshalb lohnt es sich, früh über die grundlegenden Bausteine nachzudenken. Nicht um Perfektion zu erreichen. Sondern um spätere Handlungsfähigkeit zu sichern.
Die Herausforderung besteht dabei darin, die richtige Balance zu finden. Zu viel Standardisierung erstickt die Eigenheiten erfolgreicher Teams. Zu viel Freiheit verhindert aussagekräftiges Reporting.
Zwischen diesen beiden Polen liegt der eigentliche Gestaltungsraum moderner Organisationen aus Sicht des empirischen Managements.
Fazit: Empirie braucht Architektur
Azure DevOps ist kein Projektmanagement-Werkzeug. Zumindest nicht nur. Es ist die technische Grundlage dafür, wie eine Organisation Wissen über sich selbst erzeugt.
Eine gute Struktur ermöglicht es dem Management, faktenbasiert zu steuern, ohne in Mikromanagement zu verfallen. Gleichzeitig schafft sie für Teams einen Rahmen, der Transparenz erzeugt, ohne unnötige Reibung zu verursachen.
Wer Azure DevOps lediglich als Ablage für Aufgaben betrachtet, erhält eine digitale To-do-Liste. Wer nur rückwärtsgerichtete Auswertungen betrachtet, erhält einen Flugschreiber. Wer Azure DevOps hingegen als strategisches Asset begreift, schafft die Grundlage für empirisches Management. Und in einer Welt zunehmender Komplexität ist genau das vielleicht der wertvollste Wettbewerbsvorteil überhaupt.
Dr. Alan Ettlin
DAS KÖNNTE SIE AUCH INTERESSIEREN
Künstliche Intelligenz im Testprozess
