Der Fachbereich ist unzufrieden
Neue gesetzliche Vorgaben oder andere Regularien erfordern neue Software, doch die lässt auf sich warten. Was dann –nach hektischen Nacht-und-Nebel-Aktionen – ausgeliefert wird, überzeugt nicht vollständig. Die IT ist genauso unzufrieden mit dem Projektverlauf. Vielleicht wird daher beschlossen, die Entwicklung umzustellen, und zwar gemäß den agilen Prinzipien.
Das ist natürlich nur eine der möglichen Optionen. Aber wenn die Entscheidung zugunsten der Agilität fällt, dann ist das eine Veränderung, die weitaus mehr betrifft als interne Aspekte der IT-Abteilung. Gravierend sind die Auswirkungen vor allem in zweierlei Hinsicht: Zunächst haben Finanzdienstleister oft eine säulenartige, gewachsene Hierarchie. Agile Teams dagegen kennen keine hierarchischen Strukturen, sondern Rollen, mit denen bestimmte Aufgaben verknüpft sind. Das allein könnte man immer noch für einen Aspekt halten, der in erster Linie das Entwicklungsteam angeht. Nur ist eine dieser Rollen der Product Owner, und damit wird die zweite große Veränderung angesprochen, die direkte Beteiligung des Fachbereichs. Denn der ist gewohnt, seine Anforderungen in ein Feinkonzept zu schreiben und an die IT weiterzugeben. Damit geht die gesamte Verantwortung an die IT über.
Dieses klassische Silodenken hat deutliche Nachteile
Zunächst deswegen, weil es erheblichen Aufwand bedeutet, ein Feinkonzept auszuarbeiten und weil darin Aussagen getroffen werden müssen, deren Rahmenbedingungen vielleicht noch gar nicht klar sind. Vor allem aber, weil die Mitarbeiterinnen und Mitarbeiter aus dem Fachbereich häufig wenig Bezug zum Entwicklerteam haben. Dessen Datentypen, Architekturkonzepte und Praktiken zu kennen gehört nicht zur Kernkompetenz des Fachbereichs. Ergo enthält das Konzept zwar viele Informationen, möglicherweise aber genau diejenigen nicht, die von der IT gebraucht würden. Umgekehrt liefert die IT dann ein Produkt, das vielleicht den Anforderungen der Fachabteilungen entspricht. Vielleicht aber auch nicht. Oder vielleicht schon, nur gäbe es da andere Anforderungen mit viel höherer Priorität, die nicht umgesetzt wurden. Einfach deswegen nicht, weil die Kommunikation zwischen beiden Parteien nicht nur suboptimal verläuft. Sie findet, abgesehen vom Konzept, bis zur Lieferung eines Produkts praktisch nicht statt.
Das agile Vorgehen besteht daher darin, Mitglieder des Fachbereichs direkt in das Team zu holen, das die Produktion der Software verantwortet. Dafür steht zunächst die Rolle des Product Owners. Er oder sie ist damit betraut, die Anforderungen an die Software zu formulieren und vor allem zu priorisieren. Allerdings nicht, wie beim Feinkonzept, am Anfang für das komplette Projekt, sondern iterativ – Anforderungen werden erst grob beschrieben und just-in-time vor der Umsetzung detailliert. Das erlaubt, sie an veränderte Rahmenbedingungen während des Projekts anzupassen. Die nächste wichtige Rolle spielen die Tester aus dem Fachbereich: Das Entwicklungsteam liefert jeweils nach einem kurzen Zeitintervall – meist vier Wochen – ein Inkrement, ein Softwareteilstück, das dann sofort getestet wird. Denn so liegt ein objektiver Beleg dafür vor, dass die Entwicklung in die richtige Richtung läuft.
Damit gibt es nicht mehr „die IT“ auf der einen Seite und „die Fachabteilung“ auf der anderen
Gegenseitiges Fingerzeigen ist überholt. Jetzt gibt es ein Scrum-Team, das gemeinsam Verantwortung trägt. Dabei obliegt es dem Fachbereich, Anforderungen so zu formulieren, dass die IT die richtigen Informationen erhält. Umgekehrt steht die IT in der Pflicht, nicht nur genau das zu entwickeln, was die Anforderungen vorgeben, sondern auch in der vom Product Owner vorgegebenen Reihenfolge.
Das ist für beide Gruppen eine deutliche Veränderung, die nicht nur Begeisterung hervorruft. Zwar spart der Fachbereich die Kapazität, die zuvor für das Feinkonzept benötigt wurde, dafür muss er einen Product Owner und Tester zur Verfügung stellen – eine Herausforderung, der sich durch die kürzeren Projektzeiten und die effizienteren Prozesse mit der neuen, besseren Software begegnen lässt.
Die IT-Abteilung erlebt die neue Kooperation mit dem Fachbereich möglicherweise als Verlust an Eigenständigkeit, da sie ihr Vorgehen mit dem Product Owner abstimmen muss. Im Gegenzug erhält sie jedoch die Sicherheit, wirklich das zu entwickeln, was der Fachbereich braucht. Außerdem sollte das iterativ-inkrementelle Vorgehen den Stress kurz vor dem Projektende senken und der IT den Freiraum schaffen, sich auf ihre Kernkompetenz zu konzentrieren – hochwertige Entwicklung.
Letztendlich bietet die agile Vorgehensweise mit der engen Verzahnung zwischen Fachbereich und IT die nötige Flexibilität, um immer komplexere Projekte zu stemmen, mit denen irgendwann auch der beste Einzelkämpfer (oder die beste Einzelkämpferin) überfordert wäre. Dazu kommen der massive Lerngewinn und das wachsende Verständnis für die Belange der anderen. Mit beidem steigt die Anerkennung für die Leistungen der Gegenseite, wenn die ziemlich fremden Abteilungen zu Freunden werden. „Wir sind ein Team“ ist eine gute Basis, um die Produkte zu bekommen, die man wirklich will.
Gastbeitrag von Daniel Ziegler, Senior Agile Consultant, andrena objects ag. Treffen Sie andrena bei der Handelsblatt-Tagung Banken-Technologie 2014 am 3. und 4. Dezember 2014 in Frankfurt.
Kontakt: Sebastian Bach, Sales Manager EUROFORUM | XING
