Agilität ins Team bringen - Interview mit Bernhard Rohrer
Agilität in Teams
Bernhard, du hast bei deinem vorangehenden Arbeitgeber die Art und Weise der Zusammenarbeit agilisiert. Warum hast du das gemacht?
Nun ja, der Wendepunkt war ein Gespräch mit einem Kunden. Er erzählte mir, dass er wohl demnächst kein Projekt mehr mit uns umsetzen werde. Er kritisierte die Art und Weise, wie wir unsere Projekte durchführten. Die Projekte dauern zu lange, sind zu teuer, die Resultate eher mangelhaft und überhaupt vermisse er die Transparenz. Er sagte, er habe das Gefühl, dass er nicht die Leistung erhalte, die er auch bezahle. Noch viel mehr ärgere er sich über den ständigen «Wassermeloneneffekt»! Das Projekt wird von Statusmeeting zu Statusmeeting grün rapportiert. Bis die Wassermelone auf den Tisch falle und dann sei plötzlich alles rot. «Ihr müsst endlich agiler werden» gab er mir als Botschaft mit.
Im Vorfeld dieses Gesprächs hatte ich bereits einiges an Literatur zum Thema LEAN-Management konsumiert, sowie das eine oder andere Training im Bereich Agilität, Complexity Thinking, Scrum und Change-Management genossen. Das ist doch die perfekte Gelegenheit, um die Konzepte in der Praxis auszuprobieren, dachte ich mir. Und auch der Kunde war nicht schwer von der Idee zu überzeugen.
Und wie hast du das genau gemacht?
Es gab damals in meinem Team drei Engineers, die den Kunden gut kannten. Ich sprach mit ihnen über unsere Pläne und sie waren sofort von der Idee angetan, zudem hatten sie das passende Mindset. Rückblickend war das wohl einer der wichtigsten Erfolgsfaktoren. Zusammen mit einem erfahrenen Agile Coach haben wir das Kickoff durchgeführt und dem Projekt den Namen «Nordstern» gegeben, ein «Working Agreement» geschrieben und die Rollen definiert. Der Kunde war der «Product Owner», dies weil das Vorhaben viele Anspruchsgruppen seinerseits hatte und er den besseren Zugang zu den Stakeholdern hatte. Als Provider stellten wir im Gegenzug den Scrum Master. Seine Hauptaufgabe ist es, seine Organisation und insbesondere sein Team zu Spitzenleistungen zu führen. Sofern notwendig bediente er auch firmeninterne Prozesse und räumte allfällige Hindernisse aus dem Weg. Die Rolle des Projektleiters auf Providerseite haben wir weggelassen. Etwaige Lücken hat der Scrum Master gefüllt.
Wichtig erscheint mir: Wir haben beim Setup darauf geachtet, dass alle wesentlichen Skills im agilen Team vertreten waren und mit min. 60-80% ihres Pensums dabei waren. Kleinere Aufgaben, welche nur zeitweise Skills benötigten haben wir bei Bedarf hinzugezogen. Das Projekt lief so gut, dass wir in einem zweiten Schritt dann auch den Betrieb aus diesem Team sicherstellten. Hierzu haben wir zusätzlich Betriebsmitarbeiter im Team aufgenommen sowie weitere Kunden mit diesem Team betreut.
Wie hat sich das auf die Performance des Teams ausgewirkt?
Das initiale Projekt konnte in der Hälfte der üblichen Durchlaufzeit und mit 30% weniger Kosten abgeschlossen werden. Ein voller Erfolg also! Im anschliessenden Betrieb konnte nach ungefähr einem halben Jahr der Durchsatz der abgeschlossenen Aufträge ebenfalls verdoppelt werden. Aufgrund der sehr direkten Kommunikation und der Interdisziplinarität gab es deutlich weniger Loops und daher auch tiefere Prozesskosten. An den Kundenschnittstellen konnten überflüssig gewordene Abstimmungsmeetings aufgelöst werden.
Hast du sonstige Effekte auf das Team festgestellt?
Als erstes hat es sich positiv auf die Transparenz ausgewirkt. Es war jedem Teammitglied jederzeit klar, wer was wo zu liefern hatte. Das war auch in der Zusammenarbeit mit dem Kunden förderlich und hat für mehr gegenseitiges Verständnis und Vertrauen gesorgt. Die direkte Kommunikation zwischen Kunde und Team hat uns effizienter gemacht, da zwischen Auftragsvergabe und Abwicklung keine Informationen mehr verloren gingen. Der «stille Post»-Effekt konnte so deutlich minimiert werden. Als Folge daraus gab es kaum noch Management-Eskalationen. Äusserst beeindruckt war ich davon, wie sich die Mitarbeitenden in kürzester Zeit weiterentwickelten. Wir hatten uns zum Ziel gesetzt, «T-shaped» zu werden. Sprich vertiefte Expertise zu erlernen, sowohl im Fachgebiet (vertikale Linie des «T») als auch darüber hinaus (horizontale Linie des «T»). Jeder Mitarbeitende sollte sein bisheriges, spezialisiertes Fachwissen ins Team bringen und sich gleichzeitig in anderen Fachgebieten weiterentwickeln. So konnte jedes Teammitglied Aufträge in eher fremden Fachgebieten erledigen.
Was hast du aus diesem Prozess der Veränderung gelernt?
Vieles! Zunächst mal, dass es wesentlich mehr Zeit und Geduld für Veränderung benötigt, als man vielleicht ursprünglich annimmt. Insbesondere habe ich gelernt, wie Elemente der agilen Zusammenarbeit sich positiv auf die Performance und Zusammenarbeit mit den Kunden auswirken. Im Pilotteam waren von Anfang an Leute, mit dem richtigen Mindset, dabei. Das war vielleicht auch ein Lucky Punch. Aber jede Veränderung im Team, sei es ein neuer Mitarbeitende, ein zusätzlicher Kunde oder anderweitig veränderte Rahmenbedingungen mussten durch die Teammitglieder wieder verarbeitet werden.
Ausserordentlich lehrreich war die anschliessende Phase der Skalierung. Wir wollten den Erfolg des Pilotteams auf den gesamten Bereich übertragen. Es wurde ein «Programm» ins Leben gerufen, welches bis zu einer bestimmten Deadline die Agilisierung des Bereichs abschliessen soll. Ich muss immer noch ein wenig schmunzeln, wenn ich das laut ausspreche. In stundenlangen Diskussionen hat das Kernteam versucht auf dem Reissbrett das fertige Modell zu zeichnen, Kunden und Mitarbeitende den agilen Teams zuzuordnen und zu einem bestimmten Datum die fertige Lösung zu präsentieren. Ein so ganz und gar nicht agiles Vorgehen für ein äusserst komplexes Vorhaben. Am Tag X wurde dann die «neue Organisation» den Mitarbeitenden kommuniziert. Ein Abholen und Einbeziehen der Mitarbeitenden haben, wenn überhaupt, höchstens marginal stattgefunden. Aus meiner Perspektive wurden die Auswirkungen dieses Changes unterschätzt und so blieben begleitenden Massnahmen mehrheitlich aus. Hier würde ich künftig verstärkt investieren und ein iteratives Vorgehen wählen.
Nun hast du eine ähnliche Aufgabe beim WaaS Produktteam von isolutions vor dir. Wirst du alles nochmals genauso machen?
Meine vorangehende Antwort hat es wohl schon ein wenig verraten. Nein, mit Sicherheit nicht. Wir arbeiten heute eher iterativ. Das heisst, wir testen Elemente aus und beurteilen oder messen, was gut funktioniert und was nicht. Wir beziehen die Mitarbeitenden sehr früh ein. Wie wir das im Pilotteam auch gemacht hatten. Am Schluss muss es positive Effekte auf die Zusammenarbeit, die Effektivität sowie auf die Kundenzufriedenheit haben. Und wer kann das besser beurteilen als die Mitarbeitende und die Kunden? Wenn es positive Effekte auf den Arbeitsalltag hat und diese von den Mitarbeitenden geschätzt und willkommen geheissen werden, dann fällt der Change – und davon bin ich überzeugt – wesentlich leichter.
Welche Performance-Verbesserungen erhoffst du dir von der Umstellung bei isolutions?
Um ehrlich zu sein, ist die Performance schon sehr gut. Als Team haben wir uns die beste Customer Experience zum Ziel gesetzt. Kürzlich sind wir auf eine Studie gestossen, welche die Zufriedenheit von Benutzer hinsichtlich IT-Support behandelt. Dabei wurde festgestellt, dass Feedbacks – kulturell bedingt – in der DACH-Region wesentlich schlechter ausfallen als in anderen Regionen. Hauptursache neben ungelösten Problemen sind zu lange Lösungszeiten. Im Gegenzug sind Benutzer immer dann sehr zufrieden, wenn Probleme rasch gelöst werden. Speed scheint also ein wichtiges Kernelement von hoher Kundenzufriedenheit zu sein. Einige unserer Kunden haben auch schon bemängelt, dass wir teilweise etwas langsam sind. Deswegen wollen wir Schnittstellen innerhalb des Teams reduzieren und Entscheidungswege so kurz wie möglich halten. Hier erhoffe ich mir, durch den gezielten Einsatz von agilen Elementen und Grundsätzen, zur besten Managed Cloud Services Organisation mit der höchsten Kundenzufriedenheit in der Schweiz zu werden.
