Lessons Learned – Wie die agile Transformation zum Erfolg wird

Die agile Transformation bedeutet für Unternehmen oftmals Neuland zu betreten. Umso wichtiger ist es, gewonnene Erfahrungswerte aus der Praxis festzuhalten und umgehend wieder in den Alltag einfließen zu lassen.

Schließlich ist der laufende Wechsel zwischen Reflexion bisheriger Ergebnisse und (Wieder-)Anpassung ein fester Bestandteil des agilen Arbeitens. Im Folgenden finden Sie die wichtigsten Erfahrungen, die AUSY Technologies gemeinsam mit einem Kunden aus der Finanzbranche während der letzten drei Jahre gewonnen hat. Unsere Consultants haben den Kunden bei der vollumfänglichen Einführung agiler Methoden unterstützt. Dabei haben sich die folgenden Regeln gut bewährt:

• Planen Sie immer so, als wäre der nächste Sprint der letzte, und fokussieren Sie jede Geschichte auf den Kundennutzen. Aufgrund der Quartalsbudgets waren wir im Projekt dazu gezwungen – und die Ergebnisse waren ermutigend.
• Der Schlüssel zu einem gemeinsamen Verständnis des Projektablaufs liegt in der Visualisierung der Abfolge von Prozessschritten sowie deren Diskussion im Team: Jeder sollte dabei seine Sichtweise einbringen, damit ein gemeinsames Bild des neuen Prozesses entsteht. Hierdurch ist jedes Teammitglied in der Lage, die Reihenfolge und die einzelnen Schritte nachzuvollziehen und ggf. zu erklären.
• Product Owner sollten ihre Story-Designs so früh wie möglich mit dem Team besprechen. Beginnen Sie die Diskussion am besten mit halbfertigen User Stories. Auf diese Weise verbessern sich Ihre Geschichten schneller und es fließen durch die Diskussion neue, gute Ideen ein.
• Nutzen Sie „Story-Mapping“. Das Story-Mapping eignet sich am besten für das Sortieren von Ideen, für die Priorisierung, für die Kontrolle, für die Vollständigkeitsprüfung. Und es fördert die Orientierung für Business und IT.
• Achten Sie gleich zu Beginn, noch in den allerersten Sprints, auf integrierte ausführbare Software. Auf dieser Basis lässt sich das weitere Vorgehen aufbauen. Dies macht sich in den darauffolgenden Sprints bezahlt.
• Halten Sie die Inkremente klein und liefern Sie immer lauffähige Systeme – getreu dem Motto: „Kleiner ist besser.“ Denken Sie an das Minimum Viable Product (MVP), also die minimal denkbare Ausführung eines sinnvollen Produkts. Lieber ein funktionierendes MVP als eine umfängliche technische Implementierung ohne Kundennutzen – denn im Tagesgeschäft wird letztere ohnehin nicht genutzt.
• Liefern Sie nach jedem Sprint in eine Testumgebung. Führen Sie im Zuge der Review-Sitzung stets vor, was im Moment schon funktioniert. Jedes Teammitglied sollte dazu seine Arbeitsergebnisse einbringen. So halten Sie Ihre Stakeholder immer auf dem aktuellen Stand und sichern bei ihnen die Bereitschaft, Ihr Team zu unterstützen.
• Engagieren Sie entwicklungsorientierte Tester; d.h. Fachkräfte, die sich mit den Entwicklern abstimmen und so früh wie möglich mit dem Testen beginnen. Auf diese Weise werden die Tester frühzeitig mit der neuen Software vertraut gemacht und können mögliche Herausforderungen schnell erkennen.
• Ein Daily Stand-up sollte tatsächlich auch als Daily Stand-up stattfinden. Also täglich, nicht seltener.
• „Never change a winning team.“  Halten Sie die eingespielten Teams zusammen. Die Aufgaben müssen zum Team kommen, nicht umgekehrt. Dadurch lassen sich eine höhere Geschwindigkeit und ein besseres Ergebnis erzielen.
• Wenn Teams doch einmal Teammitglieder austauschen, sollten dabei genügend Schlüsselpersonen und Know-how-Träger erhalten bleiben. Sehen Sie es als Investition in die Zukunft Ihres Teams, Wissen innerhalb des Teams zu teilen. Denn so lässt sich der Wegfall einzelner Teammitglieder kompensieren.
• Berücksichtigen Sie bei der Planung von Änderungen, dass der Wechsel von Arbeitsmodellen oder -methoden meist länger als ein halbes Jahr dauert. In vielen Fällen ist sogar eher ein Jahr realistisch.
• Es bedarf einer aktiven Pflege der Schnittstellen zu benachbarten Teams, in technischer wie menschlicher Hinsicht.
• Continuous Integration, Continuous Deployment und Testautomatisierung sind obligatorische Voraussetzungen der agilen Transformation. Ohne diese Methoden kann Entwicklung nie wirklich „agil“ sein.
• Es bedarf des gegenseitigen Respekts, damit Fachbereich und IT aufeinander zugehen und gemeinsam am Erfolg arbeiten können.
   

Und nicht zuletzt lautet eine der wichtigsten Regel der agilen Transformation: Seien Sie konsequent. Seien Sie mutig! Denn eine halbherzige Herangehensweise bringt am Ende nur halbfertige Resultate.