CAS Agile Organisation

making your organisation agile

Make it easy to follow

Posted by Cindy Wittmer on 27.12.2019

Die Bank, in der ich als Business Analystin arbeite, möchte mehr Projekte mit agiler Methode durchführen. Wenige grosse Projekte wurden bereits agil durchgeführt. Es ist mittlerweile bekannt, dass die Führungsreige nur teilweise hinter dieser Umstellung steht. Insbesondere die Business-Seite ist nicht mit im Boot. Aber auch das Management der IT scheint nicht vollständig dahinter zu stehen. Vor kurzem wurde der oberste IT Manager an einem Town Hall gefragt, ob aus seiner Sicht das Management bereit ist für agil. Seine Antwort war «Nein. Es ist leider so, dass die Antwort ‘Nein’ ist.».

Traditionell gesehen, ist eine Bank ein hierarchisches Haus. All die Männer und wenigen Frauen, die in der oberen Führungsetagen ihren Platz eingenommen haben, haben ihre Stellung hart erkämpft. Diese Menschen definieren sich über Führungsspanne und Rang. Wichtige Entscheide aus dem Projekt werden an den Steering Commitees gefällt, wo Varianten managementgerecht aufbereitet werden, damit das Gremium darüber entscheiden kann. Der Wasserfallprozess mit fix definierten Lieferobjekten und Milestones existiert nach wie vor.

Das ist die Umgebung, in der ich mich befinde. Agil ist zwar in aller Munde aber die Konsequenz dazu fehlt. Nun ist es so, dass ich schon bald in ein nächstes Projekt eingeteilt werde. Das Projekt ist prädestiniert für eine agile Vorgehensweise. Das Projektbudget sowie der Nutzen für das Business gross. Viele manuelle Aufwände sind heute Alltag, die mit der Umsetzung des Projekts aufgelöst werden können. Tatsache ist aber auch, dass der Versuch der Umsetzung schon dreimal gescheiter hat. Die Gründe waren unterschiedlicher Natur.

Wir zwei Business Analysten sind überzeugt von der agilen Vorgehensweisen und möchten nun mit kleinen Schritten die weiteren Projektmitarbeiter mit ins Boot holen. Unser Ziel: «Make it easy to follow»

Treiber: Drei Projektversuche ohne Nutzen für das Business.

Hypothese: Mit einer agilen Vorgehensweise könnte man im Projekt möglichst schnell, viel Nutzen stiften und das Business entlasten. Mit den bisherigen Versuchen im Wasserfallmodell wollte man viel und hat am Schluss nie was gekriegt.

Experiment 1: Story Mapping

Beim besagten Projekt sind ca. 10 Applikationen involviert, die in diversen Prozessen zusammenhängen. In den bisherigen Spezifikationen wurden die Requirements immer auf Applikationslevel beschrieben. In keinem Dokument sind die Stories übersichtlich und einfach aufgeführt.

In einem Story Mapping Meeting sollen alle Prozesse visuell dargestellt werden. In diesen Prozessen sollen die Pain Points für das Business klar markiert werden, damit schnell ersichtlich ist, wo am Meisten Nutzen herausgeholt werden kann. 

Messung des Erfolgs:

  • Nach den Workshops ist klar ersichtlich welche User Story am Meisten manuelle Aufwand generiert und wo das Projekt am Meisten Nutzen generieren könnte.
  • Aufgrund dieser Erkenntnisse können die ersten Sprints geplant werden.

Experiment 2: Release Planning

Auch wenn wir uns an die Releases halten müssen, können wir mit einer produktionsnahen UAT-Umgebung schnelle Umsetzungen planen. So können wir die Implementationen einerseits schnell testen und das Feedback vom Business entgegennehmen und andererseits können wir bereits nach 3 bis 6 Monaten einen produktiven Release liefern. Im Gegensatz zu einer ersten Lieferung nach 1 Jahr, wäre das ein enormer Fortschritt.

Messung des Erfolgs:

  • Erfolgreiche Einführung eines produktiven Releases nach maximal 6 Monaten.
  • Das Business zieht Nutzen aus dieser Umsetzung (Feedback).

Experiment 3: Einbezug des Managements

Der Head Operations, für den wir das Projekt durchführen, ist ein bekannter Kritiker von agilen Projekten. Mein Eindruck ist aber, dass dies mehr auf Unwissen und Falschinformationen beruht. Deshalb soll er im Rahmen seiner zeitlichen Möglichkeiten laufend über den Fortschritt des Projektes informiert werden. Informiert heisst nicht, dass er eine Slideshow präsentiert bekommt, sondern dass wir möglichst schnell Verbesserung für seine Einheit erreichen können und diese ihm laufend in den Systemen präsentieren können. Ihm wurde von der IT gesagt: „Du gibst uns das Geld und am Schluss siehst Du dann, was wir damit gemacht haben.“ Solche Sätze schrecken wohl viele Manager ab, die keine Erfahrung mit agilen Projekten haben. Von unserem Projekt soll er deshalb möglichst schnell Resultate sehen und über das Vorgehen informiert sein.

Erfolg messen:

  • Head Operations ist zufrieden mit den Resultaten des Projektes.
  • Er versteht, was agile Projekte von anderen Projekten unterscheidet.
  • Er lässt und in Ruhe arbeiten, weil er weiss, dass wir das Richtige tun.

Das sind unsere kleinen Schritte in die Agilität. Ich bin gespannt, ob es funktioniert.