Seite 3: Beispiel

Inhaltsverzeichnis

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