BZ – Konzerne setzen auf agiles Arbeiten, um schneller und innovativer zu werden. Der Autor des folgenden Beitrags, der anonym bleiben möchte, arbeitet seit vielen Jahren für ein kleines Institut mit dem neuen Ansatz. Für ihn ist eine Rückkehr zur herkömmlichen Wasserfallmethode undenkbar.”Wenn ich lese, dass Großkonzerne sich mit agilen Arbeitsmethoden ganz neu erfinden wollen, muss ich immer ein bisschen grinsen. In meinen Augen geht es beim agilen Arbeiten nicht darum, auf irgendeine magische Art kreativer und innovativer zu werden. Die neue Arbeitsweise ist schlichtweg notwendig, um die immer zu knappen IT-Kapazitäten möglichst sinnvoll einzusetzen. Ich glaube, dass große Konzerne sich die Verschwendung einfach viel länger leisten konnten, weil sie über mehr Ressourcen verfügen als kleine Betriebe.Bei der Auslandsbank, für die ich arbeite, sieht das anders aus. Mit dem früher üblichen Wasserfallmodell bin ich nur einmal in Berührung gekommen, bei meinem ersten Projekt vor zehn Jahren, das zugleich das größte und kritischste war: Die Einführung eines neuen Kernbankensystems mit Schnittstellen zu verschiedenen, meist selbst programmierten Anwendungen für die überschaubare Produktpalette unserer Bank.In der Rückschau ist es eigentlich schon selbsterklärend, warum wir inzwischen dazu übergegangen sind, fast ausschließlich mit agilen Methoden zu arbeiten. Wenn ich an die Überstunden denke! Um die Einführung des neuen Systems vorzubereiten, wurde eine ganze Heerschar von Business-Analysten aus der Zentrale eingeflogen, um mit den Kollegen aus Operations zu sprechen. Ihr Ziel: Herausfinden und dokumentieren, welche Anforderungen das neue System und seine Schnittstellen zu den Altsystemen erfüllen müssen, damit die Prozesse auch nach der Umstellung laufen. Schon diese Befragungen der Fachkollegen haben mehrere Wochen in Anspruch genommen, was steigende Rückstände im Back Office zur Folge hatte.Für jeden einzelnen Prozess haben die Business-Analysten anschließend ein Handbuch erstellt, das den Entwicklern als Leitfaden dienen sollte. Da hat sich mir schon die Frage gestellt, wer das alles lesen soll. Und vor allem, wann – fast jeder, der bei einer Bank arbeitet, klagt doch darüber, dass dauernd sinnvolle Projekte liegenbleiben, weil die IT-Kapazitäten nicht ausreichen. Trotz der umfangreichen Bibliothek von Handbüchern, die ja an allen Standorten meiner Bank erstellt werden musste, gab es danach natürlich trotzdem jede Menge Missverständnisse und Programmierfehler.Heute machen wir das anders. Wenn wir ein Projekt aufsetzen, geht die Initiative in der Regel von demjenigen aus, der dafür verantwortlich ist, dass wir eine neue Anforderung erfüllen. Dieser ,Product Owner` ist für den Projekterfolg verantwortlich und muss die Ziele festlegen, priorisieren und die Kosten im Auge behalten. Der Begriff ist ein bisschen irreführend, denn bei den meisten Projekten geht es nicht um ein Produkt im eigentlichen Sinne. Vielleicht will man ein neues Tool anbinden oder ein Marketingziel erreichen. In den allermeisten Fällen geht es aber darum, neue Vorgaben von den Aufsichtsbehörden umzusetzen.Der Product Owner muss dann, um in der Terminologie des agilen Arbeitens zu bleiben, das Backlog führen. Das könnte man vielleicht als eine Art Projekttagebuch bezeichnen. Und er muss den Kontakt zu allen Stakeholdern halten – was im ersten Schritt bedeutet, die Unterlagen durchzuarbeiten, um zu verstehen, worauf die Aufsichtsbehörden überhaupt hinaus wollen. Er muss auch mit den Kollegen im Entwicklerteam und den Budgetverantwortlichen sprechen sowie mit denjenigen, die den neuen Prozess am Ende in ihre Arbeitsabläufe integrieren müssen. Jede Menge KompromisseIm Grunde geht es also darum, alle Wünsche, Probleme und Anforderungen zu kennen und im Laufe des Projekts jede Menge Kompromisse zu finden zwischen dem Notwendigen, dem Wünschenswerten und dem Machbaren. Im Backlog werden die Ziele des jeweiligen “Sprints”, also der Projektetappe dokumentiert. Wie das Entwicklerteam diese abarbeitet, hat den Product Owner nichts anzugehen, das ist wichtig. Es ist allein Sache des Entwicklerteams, das dabei durch den “Scrum Master” unterstützt wird.Der Scrum Master muss die Fäden in der Hand halten und das Team führen, darf aber keineswegs wie ein Chef daherkommen, der Anweisungen erteilt. Der Kollege, der diese Rolle bei unseren Projekten üblicherweise übernimmt, hat unendliche Geduld, die jeweiligen Ziele dauernd zu wiederholen und Konflikte und Missverständnisse im Team zu überbrücken. Das kann nicht jeder, ich zum Beispiel komme mir schnell komisch vor, wenn ich ihn mal vertrete und zum gefühlt tausendsten Mal dasselbe wiederhole.Ich weiß aber auch, dass die Wiederholungen für den Erfolg des Projekts maßgeblich sind. Das hängt vor allem mit der Zusammensetzung der Entwicklerteams zusammen. Es sollten ja immer möglichst alle betroffenen Bereiche mit am Tisch sitzen. Bei uns sind das in der Regel vier bis fünf Kollegen. Und dass ITler oft ganz anders ticken als Kollegen aus Operations oder dem Vertrieb, ist ja nichts wirklich Neues – da muss ständig Übersetzungsarbeit zwischen verschiedenen Welten geleistet werden.Bei unserer Bank kommen noch Sprachbarrieren dazu. Zwar ist die offizielle Firmensprache an allen Standorten Englisch, aber das spricht natürlich nicht jeder gleich gut und manchmal sind verschiedene Ausdrücke für dasselbe üblich.Das Entwicklungsteam sitzt in der Regel nicht in Deutschland und viele Mitglieder kennen die hiesigen Gegebenheiten nicht aus eigener Erfahrung. Das führt manchmal zu komischen Situationen, zum Beispiel als wir anfangen mussten, für unsere deutschen Kunden die Kirchensteuer abzuführen. Das Konzept Kirchensteuer war ja schon exotisch genug. Dass wir dann aber auch noch herausfinden mussten, welche Kunden Kirchenmitglied sind, um dann für den Fiskus den Eintreiber zu spielen, kam den Kollegen für einen modernen westlichen Staat ziemlich absurd vor.In solchen Fällen bewährt sich die agile Arbeitsweise aus meiner Sicht besonders. Wenn die Anforderungen erst schriftlich niedergelegt werden sollen und die Entwickler sich darauf einen Reim machen sollen, geraten sie leicht auf den Holzweg. Sich das gegenseitig zu erklären, ist zwar oft anstrengend. Die Chance, dass in absehbarer Zeit etwas Brauchbares dabei herauskommt, ist jedoch viel größer. Und durch den persönlichen Kontakt wächst das gegenseitige Verständnis, selbst wenn vieles wie bei uns über Videokonferenzen läuft. Wenn man sich kennt und vielleicht auch schon mal zusammen über etwas gelacht hat, ist es viel leichter, Rückfragen zu stellen. Das bringt allemal mehr als die Schuldzuweisungen, wenn ein Projekt schon in die Hose gegangen ist.” Zuletzt erschienen: Digitalisierung als Überlebensstrategie (22. August)