Nach einigen Jahren intensiver Arbeit hatten wir bei congstar es geschafft die agile Arbeitsweise in der IT-Entwicklung und Qualitätssicherung zu etablieren und waren in der Lage effizient hochqualitative Software für das Unternehmen bereit zu stellen. Die Arbeit machte Spaß, und die Ergebnisse machten uns stolz.
Dennoch hatte nicht nur ich das Gefühl, dass wir erst am Anfang waren, denn das Ziel unserer Arbeit sollte Unternehmenswert sein, und nicht nur gute Software. Es reichte dazu nicht auf einer agilen Insel zu sitzen, sondern wir mussten die agile Arbeitsweise horizontal skalieren und brücken zu den Bereichen und Prozessen um uns herum schlagen.
Vom Schreier zum Unternehmensbacklog
Bislang war es so, dass jeder anfordernde Fachbereich sich überlegte, was er denn dringend brauchte, um die Firma nach vorne zu bringen und eine gewisse Anzahl von Change Requesten (CRs) pro Release stellen konnte. Diese wurden dann im Führungskreis diskutiert und priorisiert. Dabei gewannen in Konfliktsituationen, und die gab es immer, da die Fachbereiche stets mehr Ideen und Wünsche hatten, als wir in der IT umsetzen konnten, diejenige, die am lautesten schreien konnten. Der Blick auf den Gesamtwert der Anforderungen für das Unternehmen war nicht klar. Dazu kam noch, dass wir für unseren Mutterkonzern, die Telekom, gewisse Dinge umsetzen mußten.
Wir in der IT beobachteten bei den Themen, die wir umsetzten lokale Optimierungen, und wir waren uns mehr als unsicher, ob das auch das globale Optimum für congstar war.
Da wir in Scrum mit einem – und zwar genau einem – priorisierten Backlog, also einer Liste, in der die CRs nach Priorität absteigend geordnet waren, arbeiteten, die vom unserem Chief Procduct Owner verantwortet wurde, lag es nahe, diese Methodik auch auf alle Anforderungen zu erweitern.
Den Argumenten für eine ganzheitliche Priorisierung aller Anforderungen der congstar war das Unternehmen offen, und wir gründeten ein neues Gremium, das fortan alle Anforderungen, die eine IT-Unterstützung brauchten, priorisieren sollten. Das Prioboard war geschaffen.
Dieses Board tagte einmal die Woche für eine Stunde, was ausreichend war und bis heute ist. Teilnehmer sind Vertreter aller Fachbereiche, und damit auch der IT, die – und das ist ganz wichtig – kein Mitglied des Führungskreises sind, sondern die erfahrensten und besten Kollegen. Verantwortet werden das Prioboard und dessen Ergebnisse von den Product Ownern, die den Termin auch vor- und nachbereiten und moderieren.
In den nun entstehenden Diskussionen auf operativer Ebene bildeten sich schnell objektive Kriterien zur Priorisierung heraus, wir Ergebnisbeitrag, Kundenwert, Kosten/Nutzen Verhältnis, Beitrag zur Strategie und Komplexität der Lösung.
Ein Anforderer stellte also einen CR vor, machte auf Basis der Kriterien einen Vorschlag zur Priorisierung und stellt sich den Diskussionen der Teilnehmer. Da das Prioboard ein für alle congstars offenes Gremium ist, ist auch sichergestellt, dass die relevanten Kollegen dabei sind und gehört werden. Der Termin sorgt für Austausch, Verständnis und Transparenz. Gegenseitiges Hinterfragen auf Augenhöhe führt zum einen straffen Backlog Management im Sinne der gesamten congstar und damit zum Erfolg.
Im Falle von Konflikten, entscheidet der sogenannte Elferrat, in dem jeder Fachbereich und jede relevante Funktion, also auch der Datenschutz und die Strategie, eine Stimme haben. Die Vertreter des Elferrates sind fest definierte und mit Entscheidungsbefugnis ausgestattete Kollegen der einzelnen Bereiche und Funktionen.
Durch dieses Vorgehen haben wir jede Woche eine genau priorisierte Liste der wichtigsten Vorhaben mit IT-Auswirkung und stellen diese dem Führungskreis vor, der dann zum Release Forecast das Backlog und die CRs, die für das nächste Release zur Umsetzung kommen sollen, offiziell verabschiedet. In manchen Situationen gibt es Alternativen, zwischen denen die Führungsmannschaft entscheiden muß, wenn es zum Beispiel darum geht, Risiken aus regulatorischen Themen gegen marktrelevante Themen abzuwägen.
Das funktioniert sehr gut, und im Laufe der Zeit nahmen die Diskussionen zum Forecast in der Führungsrunde ab und das Vertrauen in das Prioboard zu. Um die Arbeit in diesem Gremium auch iterativ zu verbessern und zu lernen, machen wir regelmäßige Prioboard Retrospektiven, um neue Ansätze zu diskutieren und auszuprobieren.
Ein wichtiger Schritt zur Agilisierung des Unternehmens war getan.
Lerne das Richtige zu tun, bevor Du es richtig tust.
Das Backlog ist gereiht und wird von Release zu Release abgearbeitet. Dabei zeigte sich aber, dass die Aufwände für die wichtigsten CRs so groß sind, dass wir langsamer voran kommen, als die Firma das bräuchte.
Der nächste Schritt bestand also darin, getroffene Annahmen zum Potential von Produkten und Veränderungen frühzeitig zu verifizieren, und dafür diese Themen kleiner zu machen. Das Ziel ist es, dabei auf die richtigen Themen zu fokussieren, bevor wir diese vollumfänglich umsetzen.
Ein guter, aber von uns nicht ganz so oft gewählter Weg dazu, ist das Prototyping. Zum Beispiel haben wir bei der gesetzlich vorgeschriebenen Identifikation von Kunden, welche Prepaid Produkte kaufen, versucht herauszufinden, ob eine Online Identifikation eine gute Alternative oder Ergänzung zum etablierten Postident sein könnte, das für den Kunden umständlich und für congstar teuer ist. Wir haben als Prototyp erst einmal nur Kunden gefragt, ob sie das machen wollen, und ihnen bei Zustimmung dann gesagt, dass wir das in Kürze anbieten werden, bzw. im nächsten Schritt, das dann als rein manuellen Prozess im Backoffice umsetzten. Aus den Rückmeldung der Kunden lernten wir so den Wert dieser Idee und die Wünsche der Kunden kennen, bevor wir sie systemisch umsetzten.
In der Regel führen wir die Diskussion um ein mögliches Minumum Viable Product (MVP). Das bedeutet, dass wir nicht erst ein Produkt in mehreren Inkrementen bauen, um es vollständig vor Kunde zu bringen, sondern, dass wir mit einem minimalen Satz an Funktionalitäten, die einen Mehrwert bieten, vor Kunde gehen, dabei lernen und dann das Produkt ausbauen oder auch verwerfen.
Den MVP-Ansatz den Fachbereichen nahe zu bringen war nicht leicht, und es gab immer wieder Diskussionen und auch Produkte, die mit zu viel Aufwand und leider wenig Erfolg eingeführt wurden.
Mit der Zeit sind es aber genau diese Fehschläge, die heute als Argumentationshilfe für ein MVP herangezogen und auch akzeptiert werden. Hilfreich ist auch, dass wir den Stand der Produktentwicklung regelmäßig für das ganze Unternehmen transparent machen, in dem wir Review Messen durchführen. Die Fachbereiche besuchen diese zahlreich und lernen dabei, dass sich ein Zwischenstand und MVP deutlich besser anfühlt, als befürchtet, und das Vertrauen in den Ansatz wächst.
Das Risiko, das bei der teilweisen Umsetzung von Produkten und Funktionalitäten besteht, ist dass sich im Laufe der Zeit unfertige Teile in der Software ansammeln, die betriebliche Workarounds und andere Probleme mit sich bringen.
Dennoch sind wir von der Richtigkeit des Ansatzes überzeugt, und der wirtschaftliche Erfolg hinterlegt das.