Die neu eingeführte agile Arbeitsweise soll den Parlamentsdiensten helfen schneller auf Kundenbedürfnisse der Parlamentsmitarbeiterenden und der Ratsmitglieder reagieren zu können. Unser Treiber agil zu arbeiten (gemäss PESTEL Analyse) kam von der Gesellschaft aber besonders von der Politik, da wir unter anderem der Politik Informatiksysteme und -anwendungen zur Verfügung stellen. In meinen Augen ist das Ergebnis, auf agile Methoden umzustellen, ein nachvollziehbarer Entscheid, jedoch war und ist der Weg dorthin problematisch.
Culture eats strategy for breakfast, das hat mir besonders Eindruck gemacht. Unsere Unternehmenskultur ist von Misstrauen geprägt und von der Angst Fehler zu machen. Der Strategieentscheid auf agile Arbeitsmethoden umzustellen, hätte benützt werden können, um die Mitarbeitenden ins Boot zu holen, ein gemeinsames Alignement/Vision herzustellen, damit jede Person weiss, wo die Reise hingeht und auch weshalb diese Reise nötig war. Die Reorganisation wurde jedoch von der GL im Alleingang beschlossen und den Mitarbeitenden in einem Kick-Off Meeting als ausgearbeitete, finale Strategie kommuniziert. Dabei wurde nicht über das geredet, was in den letzten Jahren funktioniert hat (Storytelling), sondern nur darüber, weshalb eine solche Reorganisation nötig ist. Dies ist meiner Meinung nach mit ein Grund, weshalb der Start der neuen Organisation äusserst harzig war und wir keinen «Purpose» gefunden haben und auch heute noch in der alten Misstrauenskultur gefangen sind. Dies sicherlich auch, weil weiterhin nur die Geschäftsleitung die Entscheide trifft und somit die flache Hierarchie und teambasierte Führung nicht angewendet wird.
Um zu erleben, wie bei den Parlamentsdiensten SAFe konkret angewendet wird und dies in einem grösseren Zusammenhang zu sehen, habe ich das letzte PI Planning der Parlamentsdienste besucht. Aus diesem habe ich folgende Punkte rausgenommen, welche mir aufgefallen sind:
- Vor der Reorganisation haben die unterschiedlichen Produktgruppen nicht miteinander geredet, kaum die Abhängigkeiten geklärt und waren sich der bevorstehenden Herausforderungen erst kurz vor der Eskalation bewusst (wenn überhaupt). Dies galt es anzugehen, einerseits mittels anderer Arbeitsmethoden, andererseits (so in der Theorie) mit der Einführung der, der Agilität inhärenten Werte wie Vertrauen, Team und psychologischen Sicherheit.
- Die an den Produkten beteiligten Personen sind alle in einem Raum, und jeder Cursus (Produktgruppe) bekommt die Plattform zu sagen, welche Features für das nächste PI geplant sind. Somit sind alle auf dem gleichen Stand und allfällige Abhängigkeiten werden bereits hier ein erstes Mal angesprochen. Bei der anschliessenden Team Breakout Session wurde ein Programm Board erstellt und besprochen. Dieses Programm Board soll die Relaseplanung/-termine definieren und die Abhängigkeiten aufzeigen und wird in die Räumlichkeiten von Ressort integriert und die Product Owner / Product Manager treffen sich einmal pro Woche davor, um es zu sprechen und die Planung voranzutreiben und umzusetzen. Gemäss SAFe wäre das PI Planning zwei Tage, wir haben uns jedoch – aus mir unbekannten Gründen – auf zwei Halbtage beschränkt. Wir machen ebenfalls kein aktives gemeinsames Planning während des PI-Events, sondern machen nur eine Abstimmung, der im Vorfeld erarbeitenden Planungen von PO und PM.
- Ich habe das Gefühl, dass man zwar auf dem guten Weg ist, jedoch viele den Rhythmus noch nicht gefunden haben, insbesondere sind die fachseitigen Teilnehmer in den agilen Arbeitsmethoden noch sehr unerfahren und daher mit der Situation überfordert. Die von unser verlangte SAFe Zertifizierung wurde online und auf Englisch gemacht, wobei ein Grossteil der Mitarbeiter nicht Englisch spricht. Es gibt zwei Product Owner, welche bereits agil gearbeitet haben und somit mit dem JIRA Confluence professionell umgehen können (Unterteilung in Features, Epics, Enablers und Stories) und in einem Excel die Ressourcen aufzeigen und verteilen. Andere sind (noch) nicht in der Lage, dies so umzusetzen, weshalb ich die Gefahr sehe, dass JIRA Confluence ein Datenfriedhof wird.
- Das Verständnis füreinander, besonders in einem Bereich, wo die IT und das Fach vorher nicht miteinander geredet haben, ist gewachsen und die Grabenkämpfe scheinen sich bis auf wenige Punkte verflüchtigt zu haben. Nun muss sich das Ganze noch festigen, man muss es erleben und die Erfolge sehen.
- Das Hauptziel der Reorganisation, nämlich die Zusammenarbeit von Fach und IT zu verbessern, ist bereits auf einem guten Weg jedoch ist man noch nicht so weit, dass man einen gemeinsamen «Purpose» hat, den man lebt. Zurzeit ist das Prestigeprojekt, welches noch unter Hermes läuft, in einem kritischen Punkt angekommen, da dieses per Juli 2023 eingeführt werden muss. Für das nächste PI wurde deshalb diesem respektive den Schnittstellen und Vorarbeiten, welche im neuen Ressort geleistet werden müssen, erste Priorität gegeben.
Was mir klar fehlt, sind die Punkte Vertrauen, psychologische Sicherheit, man gibt den Personen keinen Raum Fragen zu stellen oder Fehler zuzugeben.GL Mitglieder, welche auch personalrechtliche Konsequenzen aussprechen können, sind gleichzeitig Business Owner und entscheiden immer noch abschliessend, wenn sie etwas anders wahrnehmen. Diese Doppelrolle BO und GL Mitglied ist unüblich und meiner Meinung nach höchst kritisch, die Gewaltentrennung fehlt und sie sind unglaublich stark unter politischem Druck und können nicht frei agieren. Unsere (noch) bestehende Kultur hat die schöne neue Strategie gegessen, die Steuerung kommt immer noch von oben nach unten und der «kleine Mitarbeiter» hat nichts zu sagen, auch fachlich nicht.
Schliesslich ist anzumerken, dass SAFe sich, wie ich gehört habe, besonders eignet für die Produkteentwicklung und Lösungsentwicklung mit hohem Softwareanteil. Bei den Parlamentsdiensten wird aber oft eine Standardlösung eingekauft, welche in die bestehende Infrastruktur integriert werden muss. Mir scheint das SAFe Framework für uns zu umfassend da es bei uns eigentlich nur darum geht, Schnittstellen zusammenzuführen. Wenn wir heute mit einem externen Stakeholder zusammenarbeiten, führen diese ein eigenes JIRA und wir führen eigentlich eine Schattenbuchhaltung.
Am Beginn des PI Plannings wurde gesagt, dass mit diesem Tag die Reorganisation offiziell abgeschlossen sei. Das mag sein, die Transformation ist es noch lange nicht, wenn sie denn überhaupt begonnen hat.