Früher Scheitern mit Scrum

Wer sind die Scrum-Experten von ZWP zu Gast an der Bar?

Roman: Herzlich willkommen an der TGA-Bar, live aus Berlin, aus dem Hauptstadtstudio — wir sind immer noch auf dem Barcamp. Wir freuen uns sehr, dass wir zwei nette Kollegen von ZWP dabei haben. Vielleicht stellt ihr euch kurz vor.

Tobias: Ich bin Tobias Göddecke aus Köln, leite dort mit zwei Kollegen die Niederlassung und bin Niederlassungsleiter, seit 15 Jahren dort. Ich komme aus der klassischen TGA-Branche und bin dort immer geblieben.

Mehdi: Ich bin Mehdi Fadlallah und seit ungefähr fünf Jahren bei ZWP. Ich mache die Projektleitung, habe Maschinenbau und Green Building Engineering studiert — so bin ich bei ZWP gelandet.

Roman: Bei euch schlägt überall das agile Herz, deswegen passen wir gut zusammen. Mehdi, du hast bei euch die Rolle Certified Scrum Master.

Wie hat ZWP Scrum im Büro eingeführt?

Mehdi: Scrum machen wir schon seit 2017 im Haus und haben damals gemerkt, dass es eine gute Methode ist, um Projekte agil zu gestalten und effektiver und effizienter ans Ziel zu kommen. Vor ungefähr eineinhalb Jahren haben wir uns gedacht: Warum machen wir das nicht richtig? Wir kennen die Theorie, jetzt wollen wir auch einen zertifizierten Scrum Master haben, der das Thema Agilität im Haus betreut. Das war viel Theorie und gleichzeitig ein Coaching bei uns im Haus — seitdem machen wir das professionell.

Tobias: Eigentlich war das der dritte Anlauf. 2017 haben wir in Kinderschuhen selbst angefangen, weil wir es für richtig hielten, agil zu arbeiten — die Welt ist so komplex geworden. Wir haben Theorie angelesen und uns das über Jahre selbst professionalisiert. Dann kam der Corona-Schock: Wir hatten sehr agil in kleinen Gruppen im Büro zusammengearbeitet, das ging dann nicht mehr, und das Thema ist für ein bis anderthalb Jahre eingeschlafen. Danach haben wir uns Unterstützung geholt, um das agile Mindset zu verstärken und mit einem richtigen Scrum Master in die Breite zu bringen. Wir sind ein großes Büro und wollen das über einzelne Teams hinaus auf alle Mitarbeiter ausweiten — da hilft uns Mehdi übergreifend.

Welche Methoden nutzt ZWP über Scrum hinaus?

Mehdi: Der Anfang war herausfordernd, aber mittlerweile machen das die Teams selbstständig, und die Methoden sind bei uns standardisiert worden. Wir nutzen nicht nur Scrum, sondern auch Kanban, Scrumban und teilweise auf Baustellen Lean Management. Wir sind immer noch in der Entwicklungsphase: Da Scrum aus der Softwareentwicklung kommt, schneiden wir es auf unsere Branche zu und individualisieren es für das, was wir brauchen.

Was ist der größte Erkenntnisgewinn aus der Scrum-Einführung?

Tobias: Der größte Erkenntnisgewinn aus den letzten zwei Jahren: Scrum ist ein mächtiges Instrument, aber ganz formell nach Lehrbuch hat es viel Drumherum, das nicht in jeder Phase und zu jedem Zeitpunkt in unsere Projekte passt. Es ist projektabhängig und leistungsphasenabhängig, wann man was macht. Wir nutzen nur das, was uns gerade hilft. In dem einen Projekt ist eine einfachere Methode besser, weil sie im täglichen Tun mehr Übersicht gibt; in einem anderen spielt der Bauherr mehr mit, und wir können Scrum mit allem Drumherum wirklich umsetzen.

Der zweite Erkenntnisgewinn: Es braucht ein Veränderungsmindset. Eine Methode einfach auf den klassischen Bauprozess überzustülpen hilft nicht, dann ist es nur mehr Aufwand. Jeder muss mitgehen. Veränderung ist heute das neue Normal. Das lernt man nicht von heute auf morgen — auch nach sechs, sieben Jahren sind wir im ständigen Lernprozess.

Wofür eignet sich Scrum in der TGA-Planung?

Roman: Scrum lässt sich gut anwenden, wo man ein interdisziplinäres Team braucht, das relativ gleichzeitig ein Ergebnis erstellen muss — ein repräsentatives Element, an dem man sich fortarbeiten kann. Ich habe das mal mit vier Technikzentralen beschrieben, die wir hintereinander geplant haben: Die erste sah furchtbar aus, die Hälfte fehlte, aber man konnte sich schon daran abarbeiten und sagen, das Lüftungsgerät soll nicht ins Erdgeschoss, sondern ins zweite und erste Untergeschoss. Das haben wir immer wieder eingebaut und verbessert. Dafür brauchten wir Lüftung, Heizung, Elektro und Sanitär zusammen — alle mussten gleichzeitig etwas erstellen. Das war anfangs sehr unkoordiniert. War das bei euch auch so ein anfangs stressiger Prozess?

Mehdi: In der TGA-Branche sind die Schnittstellen immer ein Genickbruch — auch die internen Schnittstellen zwischen den Gewerken. Es hat sich herauskristallisiert, dass solche Methoden sehr gute Instrumente sind, um diese Schnittstellen zu meistern und aus Hindernissen Chancen zu machen. Am Ende arbeiten alle zusammen und kreieren in kleinen Schritten Inkremente und sehen Erfolge. Und wenn man kleine Erfolge sieht, sind Motivation und Performance größer.

Tobias: Das Sehen würde ich nicht nur auf BIM beziehen. Es reicht schon, sich für zwei Wochen einen Planungsabschnitt transparent zu machen und auf einem Board zu visualisieren — ob Kanban-Board, Scrum-Board oder digital, etwa in Mural. Sich klarzumachen, was man die nächsten zwei Wochen macht und was man tun muss, um das Ziel zu erreichen — dann kommt man in die Tiefe, hat die Pakete und sieht das Vorankommen. Das ist etwas anderes, als in vier oder acht Wochen einen Riesenberg besteigen zu müssen.

Was ist der Türöffner, um Mitarbeitende für agile Methoden zu gewinnen?

Sören: Wenn man sich Scrum aus einem Buch aneignet, das aus der IT kommt, liest man von ganz neuen Begrifflichkeiten und ist schnell beim Thema Akzeptanz. Ich bin Fan davon, Veränderung so einzustreuen, dass sie gar nicht auffällt. Sobald man dem Kind einen Namen gibt — Product Owner, Scrum Master, Backlog —, denken alle: Oh Gott, was ist das, das will ich nicht. Was war für euch der Türöffner?

Tobias: Man muss sich darauf einlassen, dass Veränderung dazugehört und man flexibler werden muss. Ich würde nicht die ganze Methodenkiste aufmachen und erst die komplette Theorie verlangen, sondern schrittweise vorgehen: erst nur eine Visualisierung über ein Board anwenden und das dann ergänzen. Nicht mit Gewalt überstülpen, sondern sagen: Wir haben hier einen flexiblen Kunden, wir bauen uns erst ein Board, um unsere Aufgaben zu visualisieren. Dann ist schon ein erster Schritt gemacht. Das Verständnis kommt über die Anwendung.

Mehdi: Was ich auch immer mache: Es ist nicht in Stein gemeißelt. Wir probieren es aus, mit dem Ziel, die Arbeit zu erleichtern. Wenn wir merken, dass es die Arbeit erschwert, dann lassen wir es wieder weg.

Sören: Genau dieses Ausprobieren ist die Schwierigkeit: Wenn ich überzeugt bin, dass mein Prozess funktioniert, sperre ich mich. Da bin ich wieder beim Mindset — der Bereitschaft und dem Mut, Veränderungen anzunehmen.

Sollte man auch Nutzer und Facility Manager ins agile Team holen?

Roman: Ich war auf der Messe Agile Beyond IT in Hannover, eingeladen von unserem Coach Ralf Kruse, der ein Scrum-Master-Einführer in Deutschland ist. In einer Session fragte ein Mitbegründer, der Scrum nach Deutschland gebracht hat, was das Wichtigste im Scrum-Team ist. Alle dachten: der Scrum Master, der Product Owner — nein. Das Team ist das Allerwichtigste, die Entwickler. Bei uns sind das die Fach- und Systemplanenden. Sein Rat: Setzt die Leute mit den Usern zusammen und lasst sie spielen. Die Projektleitenden und Koordinierenden sind für den Rahmen zuständig — Kosten- und Terminrahmen —, aber das Bild innen drin entsteht zwischen User und Planer. Bei uns wären das Nutzer und Facility Manager. Wir müssten unsere Fach- und Systemplaner viel mehr direkt mit Nutzern und Facility Managern zusammenbringen. Habt ihr das schon integriert?

Mehdi: Das haben wir noch nicht integriert, da haben wir noch keine Erfahrungen. Wir versuchen es erst intern zu stabilisieren und zu etablieren. Der nächste Schritt wäre, mit der Methodik zu den Externen zu gehen — übergreifend mit Architekten, Bauherren, Projektsteuerung und Statik ein Projekt mit einer agilen Methode zu meistern.

Tobias: Auch da würde ich die kleinen Schritte, die wir im Büro erarbeiten, nach außen spielen — über das Team, nicht immer nur über den Projektleiter. Dann bekommt man Feedback, sieht, dass etwas noch nicht passt, und kann schnell nachbessern. Sonst stellt man nach einer großen Leistungsphase am Ende etwas vor und ist daran vorbeigelaufen.

Was bedeutet das Prinzip „früher scheitern"?

Tobias: Der offizielle Begriff ist: Wir wollen früher scheitern. Wenn man sich das transparent macht, heißt das: Ich will früher eine Rückmeldung, ob ich mit dem, was ich gerade erarbeitet habe, richtig liege.

Roman: Du kannst auch einfordern: Ich brauche jetzt einen Design-Freeze, damit ich ein Modell bekomme und euch in vier Wochen etwas zeigen kann. Ohne Design-Freeze kein Modell, dann kommen wir nicht weiter. Und man kann den Terminplan zeigen und wie er sich verschiebt, weil Vorgaben fehlen — agiles Kundenmanagement. Die Alternative ist, die Rhythmen enger zu machen und sich alle zwei Tage zu treffen.

Sören: Früher scheitern ist eine totale Chance: Man gibt nicht vier Wochen Arbeit nachträglich einen Sinn, sondern erfährt viel früher, dass man auf dem falschen Weg war. Sonst denkt man nach vier Wochen zurück und fragt sich, welchen Mehrwert man produziert hat — gar keinen. So kann man sich auch über die Eigenmotivation gut steuern.

Roman: „Scrum Master — besser früher als später scheitern." Geile Rollenbeschreibung: der Helfer beim Scheitern.

Wie geht es mit agilen Methoden an der tgabar weiter?

Roman: Wir treffen uns in der Lounge Projektleitung am 15. Februar. Ich habe eine promovierte Agilistin eingeladen, Dr. Katharina Lennartz von der RWTH Aachen — auch aus eurer Ecke. Sie kommt online dazu und berichtet, was sie dazu am Institut macht. Vielen Dank für das Gespräch — Mehdi, coole Rolle. Berichtet uns gerne in ein, zwei Jahren, wie es weiterlief.

Tobias: Sehr gerne. Ist verbucht, der Termin steht schon.