2015 kam es in der Software- und Informatik-Abteilung von Agilent zu Problemen. Beim Release eines wichtigen neuen Produkts konnte das Team den Release-Termin nicht einhalten. Das war nicht das erste Mal. Die Abteilung war nur bei etwa 20 % der Releases pünktlich.
Die verpassten Release-Termine setzten die Software-Teams unter enormen Druck. "Wenn Teams unter Druck stehen, treffen sie schlechte Entscheidungen", so John Sadler, VP und GM der Software- und Informatik-Abteilung von Agilent. "Sie stellen die Qualität hinten an und müssen später die Folgen ausbaden. Unser Team war völlig überlastet und hatte jedes Mal Schwierigkeiten, die Fristen einzuhalten."
Eine besondere Herausforderung für die Software- und Informatik-Abteilung von Agilent waren die 150 Mitarbeiter auf zwei Kontinenten, die mit Auftragnehmern auf einem dritten Kontinent zusammenarbeiteten. Eine große Abteilung umfasste alles und jeden von der Technik über das Marketing, die Qualitätssicherung und den technischen Support bis hin zu Vertriebsexperten. Das Unternehmen musste neue Teamverfahren einführen, um schneller Mehrwert zu liefern, höhere Qualität und Planbarkeit zu bieten und besser auf Veränderungen zu reagieren. Kurz gesagt: Es war Zeit für eine agile Transformation.
Die agile Transformation beginnt
2015 plante Agilent eine agile Transformation mit den folgenden Zielen:
- Fokus auf der Planbarkeit
- Entwicklung eines verlässlichen Release-Rhythmus
- Entwicklung eines reproduzierbaren Auslieferungszyklus
- Förderung kontinuierlicher Verbesserung
Der Agile-Ansatz stellt die Qualität an die erste Stelle, den reproduzierbaren Rhythmus an die zweite und den Umfang an die dritte. "Wenn sich Teams nicht an diese Prioritäten halten, setzen sie oft den Umfang an die erste Stelle, der Zeitplan besteht nur aus Fristen und die Qualität bleibt auf der Strecke", so Sadler.
Agilent wollte agile Verfahren einführen, die Prioritäten zu einem elementaren Bestandteil der Softwareentwicklung machten. Die Einführung von kontinuierlicher Verbesserung als zentralen Wert umfasste einen kulturellen Wandel, der den Grundstein für die Transformation legte. Qualität an die erste Stelle zu setzen, sollte sowohl die Zufriedenheit externer und interner Kunden verbessern. Agilent war bereit, Abstriche beim Umfang zu machen, um die Kundenerwartungen zu erfüllen.
Zweite Priorität hatte es für die Abteilung, einen vorhersehbaren Release-Zyklus zu entwickeln, der nach und nach verbessert werden konnte. Ein kürzerer, zuverlässigerer Entwicklungszyklus bedeutete, dass das Team Probleme vermeiden und Risiken frühzeitig vermindern musste, damit genug Zeit zum Reagieren blieb.
Phasenweise agile Transformation
Ab August 2015 arbeitete Agilent zunächst mit cPrime zusammen, einer Beratungsfirma für agile Transformationen, und später mit TCGen, einem führenden Beratungsunternehmen für die Produktentwicklung.
Einer der ersten Schritte war die Implementierung des agilen Produktmanagementtools Jira. Jira bietet ein zentrales Datenbanksystem für alle Entwicklungsaufgaben der global verteilten Teams von Agilent. Das Tool schafft Transparenz mit einer zentralen Informationsquelle, die geplante Funktionen, geplante Release-Termine und die Erfolge der Teams aufzeigt.
Angepasst mit Genehmigung von cPrime, Inc.
Als Nächstes waren Agile-Schulungen an der Reihe. Das Ziel war es, agile Prinzipien und Konzepte zu vermitteln und eine gemeinsame Terminologie aufzubauen. cPrime verwendete sein RAGE-Modell (Recipes for Agile Governance in the Enterprise), das die wichtigsten Zeremonien darlegt, darunter Meetings zur Release-Planung, Scrum of Scrums-Teammeetings, Scrum of Scrums-Produktinhabermeetings, Meetings zur Release-Backlog-Pflege sowie Meetings zu Release-Reviews und Release-Retrospektiven.
Agilent legte außerdem Bereichsproduktinhaber-Rollen und Programmmanager-Rollen fest und maß den Fortschritt mithilfe von Burnup-Charts. Agilent führte zudem einfache Techniken zur Entscheidungsfindung ein, führte Zeremonien durch, verwendete agile Scrum-Artefakte und implementierte weitere agile Verfahren.
Agile in der Praxis
Im November 2015 führte die Software- und Informatik-Abteilung von Agilent einen Sprint Zero durch – eine zweiwöchige agile Planungssitzung mit vierzehn geschulten Teams. Dabei wurde ein achtmonatiger Produkt-Release-Plan für das Chromatografie-Datensystem OpenLAB entwickelt.
Die Aktivitäten im Rahmen des Sprint Zero umfassten drei Kategorien:
- Schulung von Teams zu geschäftlichen und technischen Zielen, Antriebsfaktoren und übergeordneten Anforderungen für OpenLAB mithilfe von Präsentationen und Postern.
- Anwendung kürzlich erlernter Methoden zur Entwicklung von Anforderungen und Schätzung von Storys, Epics und Fehlern.
- Aufstellung von Storys, Epics und Fehlern auf dem Release-Planungs-Board und Angabe aller teamübergreifender Abhängigkeiten.
Agilent bemerkte schnell, dass die Agile-Verbesserungen im Unternehmen über das Pilotprojekt hinausgingen. Einer der ersten Erfolgsindikatoren war intern. "Da wir mit anderen Agilent-Abteilungen zusammenarbeiteten, war es besonders wichtig, unsere angekündigten Aktivitäten verlässlich durchzuführen", so Sadler.
Agilent verzeichnete auch extern Verbesserungen. Das Kundenfeedback trug maßgeblich dazu bei, dass die Agilent-Teams besser auf Marktveränderungen reagieren konnten. Durch die frühzeitige Einbeziehung der Kunden in den Entwicklungsprozess erhöhte Agilent die Softwarequalität und reduzierte gleichzeitig das Markt- und Integrationsrisiko.
Zu einem der Erkenntnisse von Agilent gehörte es, die Definition von "Erledigt" so zu ergänzen, dass jedes agile Epic Upgrade-Storys enthalten sollte. Babita Jain, Director of Software Quality, und Stefan Weiss, Manager of Software Integration bei Agilent, leiteten die Implementierung der Transformation an und unterstützten Teams dabei, den gesamten Umfang des Projekts zu verstehen. "Ein Epic sollte nicht als erledigt gelten, wenn es keine Upgrades enthält", erklärt Jain.
Die agile Transformation verbesserte nicht nur die Qualität sondern auch die Zuverlässigkeit. 2016 wurde das Chromatografie-Datensystem OpenLAB pünktlich ausgeliefert. Seit der agilen Transformation liefert Agilent Software in einem regelmäßigen Rhythmus aus und es kommt seltener zu Fehlern beim fertigen Produkt.
Erfolgsmessung
Agilent definiert und misst den Erfolg seiner agilen Initiative mit "einer geringen Fehlerquote im fertigen Produkt und hoher Kundentreue", so Sadler. Auch die Kundenbindung ist von zentraler Bedeutung. In einem gesättigten und wettbewerbsorientierten Markt wie der Life-Science-Branche ist die Abwanderung von Kunden eine reelle Gefahr. Die Fähigkeit, bestehenden Kunden neue Systeme zu verkaufen ist daher von zentraler Bedeutung.
Im Folgenden sind vier wichtige Metriken aufgeführt, die durch das JIRA-basierte Kapazitätsmodell von Agilent ermöglicht werden:
Burndown-/Burnup-Charts
Agilent bemaß den Arbeitsaufwand zuvor in Entwicklungsstunden, Arbeitstagen und Story Points. Jetzt verwenden alle Mitarbeiter Burnup-Charts, um den gesamten Arbeitsaufwand sowie die bereits erledigten Aufgaben nachzuverfolgen. Burndown-Charts zeigen ihnen, wie viel Arbeit noch übrig ist.
Prozent der auf den Markt gebrachten Kapazität (Nutzlast)
Die Möglichkeit, die Kapazität zu modellieren und nachzuverfolgen, ist ein entscheidender Faktor in der Art und Weise, wie Agilent Erfolg misst. Mit Jira konnte Agilent ein detailliertes Kapazitätsmodell entwickeln. "Mit diesem Modell konnten wir der Marketingabteilung in der Planungsphase mitteilen, wie viele Story Points sie vor einem Release abarbeiten sollte. Die Marketingabteilung kann das Backlog zudem nach Priorität ordnen, um den Kapazitätsanforderungen gerecht zu werden", so Sadler.
Anzahl der Fehler und mittlere Zeit zur Behebung
Das Kapazitätsmodell umfasste eine detailliertere Ansicht, die es Agilent ermöglichte, die aufgewendeten Kapazitäten zur Behebung von schwerwiegenden Fehlern zu ermitteln. Dabei wird zwischen Fehlern, die vom Kunden im fertigen Produkt entdeckt werden, und Fehlern, die vom Qualitätsteam entdeckt und gemeldet werden, unterschieden.
Zeitaufwand in Prozent für die Behebung von in manuellen Test gefundenen Fehlern
Das Kapazitätsmodell ermöglicht es Agilent, die Zeit zu messen, die zur Entwicklung neuer sinnvoller Funktionen für Kunden sowie zur Wartung und Aufrechterhaltung vorhandener Produkte aufgewendet wird.
In etwas mehr als drei Jahren konnte die Abteilung den Kapazitätsprozentsatz für wertschöpfende Arbeit mehr als verdoppeln – von 30 auf 65 Prozent. Da sich die Softwarequalität durch den neuen agilen Ansatz verbesserte, mussten im Nachhinein auch weniger Fehler behoben werden.
Ein Jahr nach Beginn der agilen Transformation beschreiben die Teammitglieder von Agilent unterschiedliche Vorher-Nachher-Szenarien:
 | Vorher: Die Leistung wurde in Entwicklungsstunden, Arbeitstagen und Story Points gemessen. |
|---|---|
 | Vorher: Teams mit unterschiedlichen Kenntnissen im Bereich Agile verwendeten unterschiedliche Definitionen für Epics, Stories und Sub-Tasks. |
 | Vorher: Scrum Master schrieben Code, leiteten Teammeetings an und wägten Funktionsprioritäten ab. |
 | Vorher: Fehlerhafte Funktionen konnten genehmigt werden, was zu Fehlern in den folgenden Entwicklungsphasen führte. |
 | Vorher: Oft traten Probleme in letzter Minute auf und führten zu Panik und erheblichen Verzögerungen. |
 | Vorher: Es gab kein Tool, um die Arbeitskapazität im Team zu messen. |
Die Zukunft von Agile bei Agilent
Wie jede Kultur, die kontinuierliche Verbesserung anstrebt, ist auch die agile Transformation von Agilent alles andere als abgeschlossen. Zu den nächsten Schritten gehörten die Verkürzung der Durchlaufzeit und die Verbesserung der Fähigkeit, frühe Erkenntnisse aus dem Marktfeedback zu ziehen – einige wichtige Elemente von DevOps-Metriken.
Agilent hat die Durchlaufzeit bereits drastisch reduziert und jährliche Releases in zwei Sechs-Monats-Zyklen aufgeteilt – obwohl das Unternehmen die Releases jährlich vermarktet. Das Unternehmen plant, die Durchlaufzeit erneut zu halbieren und einen vierteljährlichen Rhythmus einzuführen.
Zur kontinuierlichen Verbesserung gehört auch, Kunden früh und regelmäßig in den Entwicklungsprozess einzubinden. Sadler berichtet, dass es in seinem Team weniger Debatten um unterschiedliche Meinungen zum Projektumfang gibt, wenn klare Erkenntnisse aus dem Marktfeedback vorliegen. Die Aufrechterhaltung von Qualität und Benutzerfreundlichkeit für Kunden hat immer Vorrang und der regelmäßige Kontakt zu Benutzern sorgt dafür, dass das Unternehmen seine Prioritäten einhält: erstens Qualität, zweitens Release-Rhythmus, drittens Umfang.
Erkenntnisse
Sadler schreibt seinem Team den Erfolg zu, einschließlich den Führungskräften Jain und Weiss: Sie alle haben mithilfe von agiler Entwicklung schnelle und kontinuierliche Verbesserungen möglich gemacht. Die richtigen Tools, wie Jira und Confluence, halfen dem Team dabei, Aufgaben an einem Ort zu sammeln und den Fortschritt zu messen.
Agilent fand heraus, dass die agile Transformation einen Sponsor erforderte, der Forschung und Entwicklung, das Inbound-Marketing und die Qualität im Blick behielt. "Wenn deine Transformation nicht all diese drei Bereiche abdeckt, dann hast du keinen Erfolg", sagt Sadler. "Nur F&E macht noch keine agile Transformation aus." Am wichtigsten ist nicht die Arbeit, die innerhalb der Funktionen geleistet wird, sondern die Art und Weise der Zusammenarbeit.
Agilent kam außerdem zu dem Schluss, dass Unternehmen keine haltlosen Annahmen zu Kundenanforderungen treffen sollten. Ein agiler Ansatz umfasst regelmäßige Releases und das direkte Einholen von Kundenfeedback. Dazu gehört, dass Release-Termine eingehalten werden. Zum Auslieferungstermin müssen Produkte in ihrem aktuellen Zustand geliefert werden.
Ein weiterer Vorteil von agilen Frameworks ist laut Sadler die Sichtbarmachung von Problemen. Agile deckt zum Beispiel Kapazitätslücken auf. Dabei kommen Prozessbereiche zum Vorschein, die keinen Mehrwert bieten und zu Verzögerungen führen. Auch Qualitätsprobleme werden identifiziert. Der Wechsel von einem Wasserfallansatz zu einem agilen Ansatz erfordert nicht nur veränderte Arbeitsweisen in Teams sondern auch einen kulturellen Wandel. Agile fördert eine Kultur der kontinuierlichen Verbesserung, die alle Beteiligten inspiriert.
