Vom Wasserfall zum Daily Scrum – Agile Planung in der Architektur

Die allen Bauprojekten zugrunde liegende Gantt Chart – auch bekannt als „Wasserfall“ – galt bis vor wenigen Jahren noch als Inbegriff eines durchdachten und funktionierenden Planungs- und Bauprozesses. Waren ArchitektInnen früher Generalisten, die Gewerke übergreifend planen und entscheiden konnten, müssen sie heute schon sehr früh auf das Spezialwissen anderer Projektbeteiligter zurückgreifen. Schließlich führt die üblicherweise hohe Anzahl von Projektbeteiligten und deren Zusammenspiel dazu, dass Bauprojekte heute nicht mehr nur kompliziert, sondern hochkomplex sind . Konnte der Verlauf auch größerer Projekte bisher noch vergleichsweise gut mit dem klassischen, eben wasserfallartigen Balkendiagramm abgebildet werden, braucht es im Umgang mit der Komplexität mittlerweile neue Ansätze. Im Gegensatz zum bisherigen plangetriebenen Vorgehen, in dem das Projektziel von vornherein im Detail definiert wird und dann auch unter größtem Einsatz von Ressourcen – eben gemäß Plan – erreicht werden muss, sieht das iterative Arbeiten der Agilen Planung ein schrittweises Vorgehen vor. Zwar wird der Projektrahmen im Kontext des Dreiecks „Kosten-Termine-Qualitäten“ schon eingangs definiert. Eine detaillierte Definition und Darstellung der einzelnen Arbeitspakete und Aufgaben erfolgt jedoch nur für den überschaubaren Zeitraum der nächsten vier bis sechs Wochen. Die Komplexität des Projekts wird so für alle Betei­ligte begreifbar gemacht.

Um die in der IT erfolgreiche Umsetzung des Agilen Projektmanagements auf den Planungs- und Bauprozess zu adaptieren, haben wir, Edgar Haupt und Dr. Hendrik Seibel, zusammen mit Robert Schmorleitz (BMP) in den vergangenen Jahren den Workflow „Agil + Lean “ entwickelt, der sowohl das große Ganze strukturiert wie auch das iterative, kurzzeitige Vorgehen unterstützt. Besonderes Merkmal ist die Visualisierung der „Planung der Planung“ – die Basis für eine erfolgreiche Projektumsetzung mit internen und externen Teams. Dieser Workflow eignet sich für jedes Projekt. Die Prinzipien lassen sich einfach auf den eigenen Planungsprozess adaptieren.
Grundvoraussetzung ist dabei die Gesamtprozessanalyse, die am Anfang eines jeden Projekts steht. In ihr werden alle Rahmenbedingungen eines Projekts definiert, insbesondere wird ermittelt, welche Planungs- und Ausführungspartner wann im Projekt benötigt werden. Darauf aufbauend folgt die Meilensteinanalyse: die Definition aller für den Projekterfolg relevanten Meilensteine, z. B. Schnittstellen-, Abstimmungs-, Abgabe- und Fertigstellungstermine. Um eine realistische Abschätzung zu erhalten und nicht den vom Bauherrn genannten Wunschtermin blindlings abzunicken, erfolgt die Festlegung der Meilensteine von hinten nach vorne. Ausgehend von der Fertigstellung oder auch schlüsselfertigen Übergabe des Projekts wird der Prozess sukzessive nach vorne aufgerollt. Dabei gilt: Je weiter die Vorgänge in der Zukunft liegen, desto gröber werden sie zunächst definiert.

Sind die Meilensteine erst einmal definiert, werden daraus die Sprints entwickelt. Ein Sprint stellt einen Zeitraum dar, innerhalb dessen die zuvor vom Planungsteam gemeinsam fest gelegten Aufgaben abgearbeitet werden, eine Art Sammel­vorgang. Die Meilensteine bestimmen dabei die Zielvorgaben. Ein Sprint kann je nach Projektgröße eine ganze Leistungsphase oder nur ein Teil dessen, bspw. die Grundrissplanung, sein. Ungemein wichtig ist die Definition of Done, also die Definition dessen, was nach Erledigung der Aufgabe bzw. Abschluss des Sprints oder der Leis­tungsphase denn tatsächlich als Ergebnis vorliegen soll – erfahrungsgemäß liegt hier ein erhebliches Konfliktpotential im Umgang mit dem Bauherrn. In der Regel hegen PlanerInnen als auch BauherrInnen gewisse Erwartungen und Annahmen hinsichtlich des zu liefernden bzw. erwarteten Leistungssolls. Diese sind allerdings meist schlecht oder gar nicht kommuniziert. Im Rahmen einer Sprintplanung werden die unterschiedlichen Sichtweisen und Interessen schließlich auf einen Nenner gebracht. Jeder Sprint enthält eine Reihe von Aufgaben. Diese werden dann mit Hilfe einer Haftnotiz auf dem Teamboard für alle Beteiligten sichtbar gemacht. Die Farbe der Haftnotizen gibt dabei Rückschluss darauf, ob es sich um interne (Architekten-)Leistungen oder externe (Fachplaner-)Leistungen handelt. Agile Planung bedeutet also immer auch die Sichtbarmachung von Aufgaben, Verantwortlichkeiten und damit des gesamten Workflows.

Sind Sprints und Aufgaben erstmal definiert, geht es mit Hilfe des Teamboards an die Bearbeitung. Hierfür haben wir das aus der IT bekannte Scrumboard (strukturiert nach dem System „Kanban“) auf die Anforderungen der Branche angepasst (siehe Abbildung in der Onlineversion des Beitrags auf DBZ.de). Die Aufgaben in Form von Haftnotizen werden nun für jeden sichtbar von links nach rechts über das Board bewegt. Ein Quality-Gate in Form der Abnahmespalte stellt sicher, dass die Aufgaben erst nach gemeinsamer Prüfung im Sinne des Vier-Augen-Prinzips in die letzte Spalte „fertig“ verschoben werden können.

Besondere Bedeutung haben in diesem Zusammenhang Kommunikationsroutinen, wie bspw. das Daily Scrum, das Review oder die Retrospektive. Die Urheber des Scrumframeworks, Jeff Sutherland und Ken Schwaber, hatten die Idealvorstellung, dass sich das Entwicklerteam – analog zum Rugby – vor dem projektbezogenen Scrumboard drängelt.  Beim Daily Scrum geht es also im Kern darum, sich innerhalb des Teams kurz und täglich abzustimmen, um dem gesamten Team ein Verständnis zum aktuellen Projektstand zu vermitteln. Mit Hilfe der drei Fragen „Was habe ich seit gestern getan, was mache ich bis Morgen und was behindert mich?“ ist sichergestellt, dass das tägliche Scrum-Meeting nicht mehr als 15 min. dauert und jedes Teammitglied aktiv am Geschehen beteiligt ist. Anders als in der IT werden hier auch Störer und Hindernisse behandelt. In Zeiten des Home-Office kann das Daily idealerweise per Videokonferenz durchgeführt werden, so dass auch die nicht im Büro anwesenden MitarbeiterInnen auf Stand gebracht werden. Für die Standort übergreifende Koordination sind hier Webtools, wie bspw. Trello oder tick@time, äusserst hilfreich.

Sowohl bei der Prozessplanung als auch in der täglichen Abwicklung ist zu beachten, dass die eingangs vereinbarten Routinen eingehalten werden. Dafür sorgt i. d. R. ein bürointerner ScrumMaster, der u. a. darauf achtet, dass das Daily tatsächlich täglich stattfindet und nicht zur 2-stündigen Besprechung verkommt. Der ScrumMaster ist also eine Art Hüter des Prozesses. Über den Product Owner – der durch die Brille des Bauherrn auf den Prozess blickt – ist sichergestellt, dass die Aufgaben im Sinne des Auftraggebers definiert und abgearbeitet werden. Product Owner sind in der Planungsbranche ProjektleiterInnen, allerdings nicht im Sinne von allwissenden Anleitern, sondern als Mentor der MitarbeiterInnen und InteressensvertreterInnen des Projekts nach innen und außen.

Nach Abschluss eines Sprints erfolgen dann das inhaltliche Review und die teambezogene Retrospektive. Im Review werden – gerne auch unter Beteiligung des Bauherrn – die Ergebnisse der vorangehenden Planungsphase durchgesprochen und idealerweise für vollständig erklärt. Die Retrospektive hingegen lenkt den Fokus auf die Zusammenarbeit im Team, also bspw. „Wie haben wir zusammengearbeitet?“ „Was hat gut funktio­niert?“ „Was weniger gut, wie arbeiten wir im nächsten Sprint weiter?“ Hier wird auch der der Lean-Philosophie inhärente Ansatz der kontinuierlichen Verbesserung deutlich.

Im Ergebnis – und so können wir es nach mehrjähriger praktischer Umsetzung und Begleitung feststellen – stellt die Agile Planung eine deutliche Verbesserung gegenüber den traditionellen Planungsmethoden dar. Voraussetzung sind kurz­zyklische Feedbackschleifen unter Einbeziehung des Bauherrn und ein transparenter Workflow für alle Beteiligten. Die Folge: eine effiziente und termingerechte Umsetzung der Prozesse.