Evidence-Based Management für eine durchweg agile Organisation

Inhaltsverzeichnis

Viele Ansätze der jüngsten Vergangenheit versuchen, die Vorgehen von Scrum auf die gesamte Unternehmensorganisation auszuweiten. Ken Schwabers Evidence-Based Management nutzt dabei die Kernprinzipien des Frameworks, um den Wert der Softwareentwicklung zu erfassen und kontinuierlich zu optimieren.

Bei vielen Firmen ist Scrum als Framework zur Softwareentwicklung etabliert. Oft hat es seinen Siegeszug dabei von unten aus der Entwicklungsabteilung heraus angetreten ("bottom up"). Auch wenn Scrum mittlerweile auf höheren Ebenen, bis hin zur Geschäftsleitung, sichtbar ist, wird es häufig noch als reiner "Prozess" für die Softwareentwicklung wahrgenommen. Das liegt zum Teil daran, dass es in vielen Unternehmen an einem messbaren Monitoring außerhalb der Softwareentwicklung fehlt. Erfolge und Fortschritte, die durch den Einsatz des Frameworks erzielt werden, sind so kaum messbar und werden, besonders vom Management, deswegen nicht wahrgenommen.

Als Framework ist Scrum per Definition unvollständig, da es nur die absolut notwendigen Grundregeln für agile Entwicklungsprojekte festlegt. In diese Lücke schlagen einige Ergänzungen und Erweiterungen der letzten Monate. Einige davon versuchen, Scrum zu einem vollwertigen Prozess auszubauen. "Evidence-Based Management for Software Organizations" von Ken Schwaber hat einen anderen Ansatz: Im Gegensatz zu vielen anderen Erweiterungen, die einem "One size fits all"-Ansatz folgen, nutzt es die Prinzipien von Scrum – Transparenz, Inspektion und Adaption –, um den Wert der Softwareentwicklung in einem Unternehmen zu erfassen und kontinuierlich zu optimieren.

Es misst dazu zunächst den Wert, den die Softwareentwicklung erzeugt, in einem sogenannten Agility Index Snapshot. Danach werden in einem Capability Spotlight die Leistungsfähigkeit des Unternehmens in verschiedenen Bereichen ermittelt sowie geeignete Maßnahmen zur konkreten Verbesserung des Wertes identifiziert und priorisiert. In einem nächsten Zyklus ermittelt man erneut mit einem Agility Index Snapshot die Wirksamkeit. So wird ausgehend vom erwirtschafteten Wert iterativ-inkrementell das gesamte Vorgehen nachweislich optimiert. Diese Nachweisbarkeit ist das Grundprinzip von Evidence-Based Management, wie im Folgenden aufgeführt.

Messen, diagnostizieren, verbessern

Die Autoren wollen zunächst die drei oben genannten Werkzeuge zur kontinuierlichen Verbesserung der agilen Vorgehensweisen in einem Unternehmen betrachten:

• Agility Index Snapshot: Messen relevanter Metriken, um den Zustand des Unternehmens hinsichtlich der eigenen Agilität zu bestimmen.
• Capability Spotlight: die erfassten Metriken diagnostizieren, um zu ermitteln, was als Nächstes optimiert werden soll.
• Guided Improvement: Durchführen der geplanten Maßnahmen, um den Erfolg in einem erneuten Agility Index Snapshot zu prüfen und das weitere Vorgehen zu verfeinern.

Messen mit dem Agility Index Snapshot

Der erste Schritt zur Verbesserung der Agilität im Unternehmen ist die Bestandsaufnahme. Dabei werden für den Agility Index Snapshot elf Metriken ermittelt. Die vier "Current Value Metrics" ermöglichen dabei einen detaillierten Blick auf die Organisation selbst. Die drei "Time to Market Metrics" messen die Fähigkeit, Produkte und Ideen schnell an den Markt zu bringen. Mit den vier "Ability to Innovate Metrics" wird gemessen, wie innovativ die Organisation ist.

Eine wesentliche Voraussetzung für die Ermittlung ist die gezielte Abgrenzung des Bereichs, für den man die Metriken erhebt. Dadurch erreicht man, dass sie auch tatsächlich Aussagekraft besitzen und zu konkreten Maßnahmen führen können. Grundsätzlich wird dabei nicht das Team, sondern ein Produkt (bzw. eine Produktgruppe oder die ganze Organisation) betrachtet und gemessen.

Current Value Metrics	Time to Market Metrics	Ability to Innovate Metrics
Umsatz des Unternehmens pro Mitarbeiter	Häufigkeit von Releases	Anteil der Kunden, der die aktuellste Version des Produkts verwendet
Anteil der Kosten für die Produktentwicklung	Zeitraum zwischen Fertigstellung des Produkts und der Auslieferung	Anteil an wenig bis nicht verwendeten Funktionen des Produkts
Mitarbeiterzufriedenheit	Benötigte Zeit für die Auslieferung einer komplett neuen Funktion an den Kunden	Anteil des Gesamtbudgets, der für Innovation aufgewendet wird
Kundenzufriedenheit		Anzahl der bekannten Fehler in der aktuellen Produktversion

Bei den Metriken geht es nicht um absolute Werte, denn diese sind zwischen verschiedenen Unternehmen ohnehin schwer bis gar nicht vergleichbar. Wichtiger ist eine Erhöhung der Transparenz des eigenen Zustands im Unternehmen und der Produktentwicklung, um erkennen zu können, welche Maßnahmen bei der kontinuierlichen Überarbeitung tatsächlich einen positiven Effekt haben. Es geht also nicht darum, einen abstrakten Grad an Wertschöpfung zu erreichen, sondern die eigenen Fähigkeiten ehrlich zu ermitteln und sie danach gezielt zu verbessern.

Diagnostizieren mit dem Capability Spotlight

Nach der Bestandsaufnahme folgt das Diagnostizieren der ermittelten Metriken und das Erstellen einer Liste mit Maßnahmen – das Practice Backlog –, die sich priorisieren und umsetzen lassen. Diese konkreten Maßnahmen werden für die folgenden fünf Bereiche innerhalb eines Unternehmens definiert, die die gesamte Wertschöpfungskette umfassen:

• Prozess: Optimierung des verwendeten Vorgehens (z. B. Scrum) und seiner Elemente
• Produktivität: agile Praktiken bei der Produktentwicklung, zum Beispiel Continuous Integration oder Test-Driven Development
• Wert: Fokussierung auf das Herstellen und Weiterentwickeln von Produkten und Funktionen, die einen tatsächlichen Mehrwert bieten, etwa Weiterentwickeln des Product Backlog, Release- und Meilensteinplanung für das Produkt
• Qualität: Konzentration auf die Qualität des Produkts, beispielsweise durch das Einhalten definierter Entwicklungsstandards oder Application Lifecycle Management
• Unternehmen: Verbesserung der Strukturen im eigenen Unternehmen, etwa Organisationskultur und -kommunikation, oder der Wertschätzung der eigenen Mitarbeiter

Für die Definition der Maßnahmen gibt es kein Pauschalrezept. Hier sind Erfahrung und Fingerspitzengefühl gefragt. Außerdem ist es nötig, sich auf das Unternehmen einzulassen und die Analyse sowie die Priorisierung eng mit den Betroffenen im Unternehmen durchzuführen. Nur so ist es möglich, alle Beteiligten aktiv in den Prozess einzubinden und die Maßnahmen anschließend auch umzusetzen.

Theorie

Kontinuierliche Verbesserung durch Guided Improvement

Jetzt erfolgt die eigentliche Umsetzung der Maßnahmen anhand des während der Diagnose erarbeiteten Practice Backlog. Dieses ist – wie aus Scrum bekannt – priorisiert. Die einzelnen Aufgaben werden anhand ihrer erwarteten Wertsteigerung für das Unternehmen abgearbeitet. Das kann nicht von außen passieren, sondern muss innerhalb der Struktur und Prozesse des Unternehmens geschehen. Dabei gibt es zwei grundsätzliche Vorgehensweisen: Bei kleineren Unternehmen und einer überschaubaren Anzahl umzusetzender Maßnahmen existiert ein Practice Backlog für alle fünf Bereiche, in dem die Maßnahmen insgesamt aufgeführt, sortiert und von einem Enterprise Change Team abgearbeitet werden. Bei größeren Unternehmen mit einer größeren Anzahl von Maßnahmen werden für jeden der fünf Bereiche Practice Backlogs gepflegt und von einem Change Team abgearbeitet. Diese Teams arbeiten parallel zu- und unabhängig voneinander.

Die Wirksamkeit der Maßnahmen ermitteln jeweils weitere Agility Index Snapshots. So lässt sich im Laufe der Zeit feststellen, welche Maßnahmen sich bewähren und in welchen Bereichen das Unternehmen und sein Entwicklungsprozess agiler werden.

Literarische Stütze

Die beschriebenen Werkzeuge zur Steigerung der Agilität in einem Unternehmen basieren auf den Prinzipien des Agility Guide [1]. Er beschreibt Prozesse, Metriken und Hilfsmittel für die kontinuierliche Weiterentwicklung von Organisationen. Der Ansatz wurde aus dem Scrum Framework weiterentwickelt und zielt wie Scrum hauptsächlich auf Softwareunternehmen. Während sich Scrum aber primär an Entwickler-Teams richtet, liegt der Fokus im Agility Guide auf der Organisation, in der diese Entwickler arbeiten. Es soll ihrem Management dabei helfen, sich iterativ zu verbessern und so in kleinen Schritten weiterzuentwickeln.

In "The Enterprise and Scrum" [2] und in "Software in Thirty Days" [3] wurden die Ursprünge des Agility Guide beschrieben. Sie bauen auf den drei Säulen Transparenz, Überprüfbarkeit und Anpassung auf. Auch sonst gibt es einige Parallelen zwischen beiden Frameworks. Der Agility Guide enthält Rollen, Ereignisse und Artefakte. Die Funktionen einer Organisation sind in die fünf Bereiche "Unternehmen", "Prozess", "Produktivität", "Qualität" und "Wert" eingeteilt. Anwender des Frameworks ist ein Agility Team, das aus einem Enterprise Product Owner, einem Enterprise Change Team und einem Enterprise Scrum Master besteht. Gibt es für jede Domäne ein eigenes Agility Team, wird "Enterprise" in den Rollenbezeichnungen durch die jeweilige Domäne ersetzt (z. B. Value Product Owner statt Enterprise Product Owner).

Die Rolle des Product Owner ist identisch mit der in Scrum. Er ist verantwortlich für Umfang und Sortierung des Practice Backlog, wählt Einträge für den nächsten Sprint und entscheidet, ob das Ergebnis akzeptiert wird. Auch die Rolle des Scrum Master ist nicht neu. Er sorgt dafür, dass die Vorgaben des Frameworks verstanden und umgesetzt werden, und hilft dem Team im Umgang mit störenden Einflüssen von außen. Der Scrum Master unterstützt Product Owner, Change Team und die Organisation bei der Anwendung des Frameworks. Das Change Team besteht aus Managern, Abteilungsleitern und Fachleuten, die die Befugnis und das Wissen haben, Änderungen in der Organisation durchzuführen oder zu veranlassen. Seine Mitglieder heißen Change Agents. Innerhalb des Teams gibt es keine weitere Unterscheidung nach individuellen Rollen.

Der Agility Guide nennt verschiedene "Events", mit festem Zeitrahmen (time-boxed) und definiertem Inhalt und Umfang:

• Sprints
• Sprint Planning
• Weekly Scrum
• Evaluation
• Sprint Review
• Sprint Retrospective

Einige der Events sind von Scrum bekannt. Ein Sprint dauert hier aber immer genau einen Monat und ist damit länger als bei Scrum. Das Sprint Planning dauert höchstens einen Arbeitstag. Im wöchentlich stattfindenden Weekly Scrum hat das Team 30 Minuten Zeit, sich zu synchronisieren und die nächste Woche zu planen. Die Evaluation dient der kontinuierlichen Messung des Fortschritts und der Planung weiterer Schritte. Sie belegt während des Sprints 10 bis 30 Prozent der Kapazität des Teams. Der Sprint Review erfolgt am Ende des Sprints und belegt maximal einen halben Arbeitstag. Danach wird eine Sprint-Retrospektive durchgeführt, für die bis zu drei Stunden eingeplant werden.

Auch bei den Artefakten von Agility Path finden sich alte Bekannte aus Scrum. Neben dem Practice Backlog gibt es ein Sprint Backlog, ein Evaluation Backlog und den Increment of Change.

Beispiel

Ein fiktives Beispiel

Jetzt soll auf die graue Theorie etwas Praxis folgen. Hierfür sei ein fiktives Beispiel verwendet, an dem sich die Anwendung der oben beschriebenen Mechanismen des Evidence-Based Management verdeutlichen lassen: Ein Unternehmen stellt einen Online-Erziehungsberater als Webanwendung zur Verfügung. Eltern können sich anmelden, sich und ihre Kinder beschreiben und erhalten personalisierte Erziehungstipps durch die clevere Software. Das System lernt und verbessert somit durch kontinuierliche Nutzung den Erziehungserfolg bei Eltern und Kindern.

Das Unternehmen ist aus einem Start-up hervorgegangen, besteht seit sechs Jahren am Markt und hat derzeit 17 Mitarbeiter. Mit wachsender Anzahl der Mitarbeiter wurde es nötig, Prozesse zu etablieren. So hat die Softwareentwicklung im vergangenen Jahr erste positive Erfahrungen mit Scrum gesammelt. Den damit erreichten Erfolg möchte die Unternehmensführung jetzt weiter in die Organisation tragen und beauftragt daher einen agilen Experten (den sog. Evidence-Based Management Consultant oder EBMgt Consultant), der eine kontinuierliche Verbesserung nach den Prinzipien des Evidence-Based Management vorschlägt. Ein Enterprise Change Team wird gebildet und mit entscheidungsfähigen Personen aus der Organisation besetzt. Die Rolle des Enterprise Product Owner übernimmt der Geschäftsführer selbst. Der erste Schritt zur Verbesserung ist die Bestandsaufnahme, der initiale Agility Index Snapshot. Man erhebt die beschriebenen Metriken und fasst das Ergebnis nachfolgend kurz zusammen.

Das einzige Produkt des Unternehmens, der Erziehungsratgeber, erwirtschaftet einen Jahresumsatz von 1,5 Millionen Euro, von denen 1,25 Millionen in die Produktentwicklung (inkl. Maintenance und Support) fließen. Die Mitarbeiter sind sehr motiviert und fühlen sich dem Unternehmen persönlich verbunden. Derzeit wird ein Release pro Quartal entwickelt, nach Abschluss der Entwicklung werden circa drei Wochen für Tests und Bugfixing benötigt. Von der Idee einer neuen Funktion zur Auslieferung benötigt ein Feature im besten Fall 24 Wochen. Da es sich beim Erziehungsratgeber um eine Webanwendung handelt, verwenden alle Anwender immer die aktuellste Version. Da das Unternehmen Kundenzufriedenheit und -verhalten noch nicht misst, ist unbekannt, ob in der Anwendung Funktionen enthalten sind, die wenig oder gar nicht verwendet werden. Deshalb findet man für diese Punkte im Agility Index Snapshot keine Werte. Zum jetzigen Zeitpunkt sind dem Entwicklungsteam 187 Fehler bekannt, und bei der Implementierung neuer Funktionen kommt es häufig zu neuen Bugs. Die Fehlerbehebung benötigt zurzeit circa 50 Prozent der Ressourcen im Entwicklungsteam, die anderen 50 Prozent sind für die Entwicklung neuer Anforderungen verfügbar. Aus diesen Daten, die der Engagement Manager erfasst und aufbereitet, ergibt sich folgendes erstes Bild im Agility Index Snapshot.

Das Enterprise Change Team ermittelt aus den ermittelten Werten im Capability Spotlight Maßnahmen, die der Enterprise Product Owner nach ihrem Wert sortiert. In den kommenden drei Monaten soll im Guided Improvement an diesem Practice Backlog gearbeitet werden. Das Team entschließt sich, zunächst die blinden Flecke im Snapshot zu beseitigen, und beauftragt ein spezialisiertes Unternehmen mit dem Ermitteln der Kundenzufriedenheit sowie den wenig und nicht genutzten Funktionen des Erziehungsratgebers. Um die Qualität in der Softwareentwicklung zu steigern, sollen alle Teams umfassend in Scrum geschult werden. Spezielle Module erweitern dabei das Basistraining für die Rollen.

Als agiler Coach unterstützt der Engagement Manager die Scrum Teams. Die Entwicklungsmannschaft wird zusätzlich in weiteren Themen wie Test-Driven Development weitergebildet. Auch die Einführung unterstützender Werkzeuge etwa zur Continuous Integration sieht das Practice Backlog vor, um kritische Punkte wie die Cycle Time oder die Release-Frequenz erhöhen zu können. Als wichtigste Themen für die ersten drei Sprints bis zum nächsten Agility Index Snapshot werden die Kundenzufriedenheit ermittelt, die geplanten Trainings durchgeführt sowie bekannte Fehler behoben. Das Thema Continuous Integration soll evaluiert und entsprechende Werkzeuge aufgesetzt werden.

Die Ergebnisse der Anstrengungen zeigt der zweite Agility Index Snapshot nach Ablauf der ersten drei Sprints. Dabei sind die Zahlen für die Current Value Metrics annähernd gleich. Die Mitarbeitermotivation hat sich erhöht, eventuell ist das auf den frischen Wind zurückzuführen, der durch die Firma weht. Die Zahlen zur Kundenzufriedenheit und zu den nicht genutzten Features runden das Bild ab. Die Investition in die Weiterbildung bindet Budget, das nicht für Innovationen zur Verfügung steht. Als größter Erfolg ist sichtbar, dass sich die Anzahl der bekannten Bugs auf 95 verringern ließ. Werkzeuge für Continuous Integration ließen sich nicht evaluieren, da das Team bei der Planung die Weihnachtszeit mit der daraus folgenden erhöhten Abwesenheit von Kollegen übersehen hat.

Als Folge des zweiten Snapshot möchte das Enterprise Change Team die Kundenzufriedenheit regelmäßig durch das eigene Marketing ermitteln. Das Gleiche gilt für nicht verwendete Features, um die Webanwendung schlank und benutzerfreundlich halten zu können. Das Bugfixing wird als weiterer Punkt zusammen mit der Evaluierung und Implementierung von Continuous Integration mit aufgenommen und hoch priorisiert.

Der dritte Agility Index Snapshot nach weiteren drei Sprints zeigt, dass sich die Kundenzufriedenheit aufgrund reduzierter Fehler und eines besseren Eingehens auf die Kundenbedürfnisse steigern ließ. Die Ausgaben für das agile Coaching sind noch vorhanden, jedoch nicht mehr so hoch wie im vorangegangenen Quartal, wodurch wieder mehr Budget für Innovation verfügbar ist. Der Fokus auf Qualität zeigt Erfolge (32 bekannte Bugs). Continuous Integration ist im Einsatz, hat jedoch noch keine messbaren Auswirkungen.

Das Team wird weiterhin an der Verbesserung der eigenen Agilität arbeiten und nimmt sich als wichtigste Punkte die Steigerung der Release-Häufigkeit und die Verringerung der Cycle Time vor, was in weiteren Sprints bearbeitet und gemessen werden wird.

Ein komplettes Beispiel für einen Report der obigen Agility Index Snapshots lässt sich als PDF herunterladen.

Fazit

Evidence-Based Management kann eine Organisation flexibel auf die eigenen Bedürfnisse abstimmen. Und auch während der Anwendung sind fortwährend Anpassungen nötig. Für den qualifizierten Einstieg in das Thema sollte man sich an einen Professional Scrum Trainer oder einen lizenzierten Evidence-Based Management Consultant wenden. Lizenzierte EBMgt Consultants findet man über diese Webseite. Sie arbeiten eng mit den Change Teams zusammen und helfen dabei, Evidence-Based Management in einer Organisation einzuführen.

Abschließend lässt sich feststellen, dass es mit Evidence-Based Management möglich geworden ist, in agilen Projekten den eigenen Erfolg zu messen. Dadurch werden agile Vorgehensweisen auch für die Management-Ebene greifbarer und verlieren den Ruf des Esoterischen.

Peter Götz
ist IT Consultant und agiler Coach. Als Professional Scrum Trainer und Professional Scrum Master I+II, Professional Scrum Product Owner I und Professional Scrum Developer I unterstützt er seine Kunden bei der Einführung und Implementierung von Scrum in Softwareentwicklungsprojekten.

Uwe M. Schirmer
ist IT Consultant und Trainer. Er hat langjährige Erfahrung als Projektmanager und Requirements Engineer. Als Professional Scrum Master I+II sowie Professional Scrum Product Owner I setzt er in seinen Projekten nach Möglichkeit auf agile Methoden.

Literatur

1. Ken Schwaber und Scrum.org; The Agility Guide (Version 1.3.1)
2. Ken Schwaber; The Enterprise and Scrum; Microsoft Press 2007
3. Ken Schwaber, Jeff Sutherland; Software in Thirty Days; Wiley Press 2012

Alternativen

Alternativen zu Evidence-Based Management

Agility Path ist nicht das einzige Framework, das sich mit der Skalierung agiler Vorgehensweisen beschäftigt. Hier ein kleiner Überblick über weitere derzeit diskutierte Frameworks:

• Scaled Agile Framework (SAFe): Sein Urheber ist Dean Leffingwell, der es bereits 2007 in seinem Buch "Scaling Software Agility, Best Practices for Large Enterprises" beschrieben hat. Das Framework wurde ebenfalls aus Scrum weiterentwickelt und verwendet daraus abgeleitete Begriffe, Artefakte und Konzepte. SAFe bietet die drei Skalierungsstufen "Team", "Programm" und "Portfolio".
• Large-Scale Scrum (LeSS) basiert auf den Ideen von Craig Larman 2008 erschienenem Buch "Scaling Lean & Agile Development". Auch LeSS ist eine Weiterentwicklung von Scrum und verwendet dessen Begriffe und Konzepte. Der Hauptunterschied zu Scrum findet sich bei den Meetings, da es neue Meeting-Typen definiert und die Ausrichtung bekannter Meetings teilweise ändert.
• Scaling Agile @ Spotify unterteilt agile Teams in Tribes, Squads, Chapters und Guilds und beschreibt verschiedene Formen der Interaktion und Kommunikation zwischen den verschiedenen Einheiten. Die Organisation wird zu einer Matrix-Organisation, bei der die Einheiten von Scaling Agile eine Dimension der Matrix bilden. Scaling Agile funktioniert mit verschiedenen agilen Methoden wie Kanban und Scrum.
  

(ane)