Bauprojekte lassen sich gem. HOAI und AHO in verschiedene Projektphasen einteilen. Wie in Abbildung 4 schematisch dargestellt, werden die übergeordneten Prozesse nach der Vorgehensweise des traditionellen Projektmanagements linear durchlaufen. Demnach wird die Planung des Projekts bereits zur Projektvorbereitung durchgeführt. Neben einem detaillierten Lastenheft werden zu Beginn die einzelnen Projektphasen definiert und ein detaillierter Kosten- und Ressourcenplan abgeleitet.³² Die jeweilige Projektphase baut auf den Entscheidungen aus der vorherigen Phase auf (sog. Wasserfallmethode). Die maßgebenden Entscheidungen werden in den frühen Projektphasen getroffen und beeinflussen den Projekterfolg nachhaltig. Diese basieren jedoch in der Regel auf Annahmen.³³ Auf Veränderungen, die während des Projektverlaufs auftreten, kann im Nachhinein nur mit erheblichem zeitlichem Aufwand reagiert werden.³⁴ In den traditionellen Vorgehensweisen wird das Projektergebnis als Projektabschluss zwischen den Projektbeteiligten präsentiert und evaluiert.³⁵

Im Gegensatz dazu steht das agile Rahmenwerk Scrum (vgl. Abbildung 5). Die übergeordneten Prozesse werden über eine Iteration durch Sprints durchlaufen und vorab über Sprint Ereignisse definiert.³⁷ Ein Sprint hat dabei immer eine gleichbleibende Dauer (sog. Timeboxing). Das Projektziel wird bei Scrum durch den Kunden (bspw. Auftraggeber) als grobe Vision formuliert. Jeder Sprint leistet ein Teilergebnis für das Gesamtprojekt. Die Vision wird durch die Iterationen der Sprints und der Ausarbeitung einzelner Teilprodukte präziser.³⁸ In jedem Sprint wird das Ziel der Iteration definiert und die dazu notwendigen Aufgaben festgelegt. Nach der Ausführung des Sprints wird das Ergebnis mit  dem Kunden evaluiert. Durch die regelmäßige Evaluation hat der Kunde nach jeder Iteration die  Möglichkeit, die Entwicklung eines Projekts zu beeinflussen. Der Kunde wird fortlaufend in den Wertschöpfungsprozess eingebunden. Auf neu gewonnene Erkenntnisse kann proaktiv reagiert werden.³⁹ Durch die Iterationen können präzisere Aufwandsschätzungen und Vorhersagen über den  Projektverlauf erfolgen.⁴⁰ Vor dem Hintergrund des Wissenszuwachses der Projektenbeteiligten bei voranschreitendem Projektfortschritt werden Entscheidungen bei Scrum zum spätmöglichsten Zeitpunkt, aber dem größtmöglichen Wissensstand getroffen.⁴¹

Die Projektorganisation Scrum Real Estate ist in Abbildung 6 vereinfacht dargestellt. Grundsätzlich nimmt bei Scrum die Entscheidungsinstanz des Bauherrn als AG eine entscheidende Rolle ein. Der Product Owners und der Scrum Masters sind mit der Rolle des Projektmanagements (Projektleitung und Projektsteuerung) vergleichbar. Der Product Owner, ähnlich dem Projektleiter, ist für das Gesamtprojekt verantwortlich und agiert als Bindeglied zwischen Bauherrn und Development Team. Der Scrum Master übernimmt im übertragenen Sinne die Projektsteuerungsfunktion. Das Scrum Team ist nach seinen Funktionen gegliedert und präsentiert dem AG die erarbeiteten Sprint-Ergebnisse.

Nach dem Scrum Guide von Schwaber und Sutherland sollte das Scrum Team maximal zehn Personen umfassen. Dies ist darauf zurückzuführen, dass kleinere Teams besser miteinander kommunizieren und produktiver arbeiten. Da diese Größe im Zusammenhang mit Bau- und Immobilienprojekten sehr schnell erreicht wird, bietet das Rahmenwerk die Möglichkeit, mehrere zusammengehörende Scrum Teams zu organisieren.⁵⁰ Eine mögliche Organisation der Scrum Teams ist in Abbildung 7 dargestellt. Die einzelnen Teamleiter vertreten die Arbeitsgruppen ihres spezifischen Leistungsbereichs. Die Organisation der einzelnen Scrum Teams untereinander entspricht der Organisation im ursprünglichen Scrum Team und kann mit dem Prinzip „Scrum of Scrums" beschrieben werden. Die einzelnen Scrum Teams bzw. Arbeitsgruppen unterscheiden sich nach ihren spezifischen Leistungsbereichen, wie zum Beispiel Architektur, Tragwerksplanung oder TGA. Bei einer entsprechenden Organisation ist jedoch darauf zu achten, dass die Repräsentanten der einzelnen Arbeitsgruppen in regelmäßigen Besprechungen anwesend sind und im Austausch stehen. Während dies bei kleineren Projekten in der Regel einfacher umgesetzt werden kann, führt die Anzahl der Projektbeteiligten bei Großprojekten oftmals dazu, dass die geforderte Agilität verloren geht. Daher bietet sich die Organisation über mehrere Scrum Teams an.

Auf Basis der vorgestellten theoretischen Grundlagen stellt sich die Frage, wie Scrum in einem Bauprojekt umgesetzt werden kann. Die intensive Kommunikation im Projekt wird mit Scrum durch die zuvor beschriebenen Scrum-Ereignisse gefördert. In der Folge kommt es zu weiteren Abstimmungen im Projekt. Diese sind von kurzer Dauer und haben die priorisierten Aufgaben zum Inhalt. Aufgaben von geringerer Relevanz werden zu einem späteren Zeitpunkt bearbeitet (vgl. Pareto-Prinzip). Langandauernde und teilweise ineffiziente Projektsitzungen werden auf ein Minimum reduziert. Der Mehrwert von Scrum ist der Baustellenbelegschaft frühzeitig aufzuzeigen, um Missverständnissen vorzubeugen (Kulturwandel).

Das Kommunikationsmedium sollte für eine Vorgehensweise nach dem Scrum-Rahmenwerk durch die Beteiligten vorab festgelegt werden. In einem ersten Schritt eignet sich ein Big Room-Container auf der Baustelle, um Projekte mit Scrum zu starten (sog. Informationsplattform/-hub). Nachdem sich die Vorgehensweise bei den Scrum Mitgliedern etabliert hat, sind weitere Skalierungen über digitale Kommunikationstools denkbar. Diese Vorgehensweise ermöglicht, alle Beteiligten im Projekt über Scrum zu informieren und reduziert abneigende Haltungen gegenüber neuen innovativen Praktiken.

Daneben bietet sich die Einführung über kleine Teams an, welche ein großes Interesse an innovativen Ansätzen hat. Mitarbeiter*innen können sich freiwillig zur Mitarbeit in einem Scrum-Team bereit erklären. Ein erfahrenerer Scrum Master kann zu Beginn unterstützend mitwirken. Für den Fall, dass Personen Bedenken gegenüber dem Rahmenwerk Scrum haben, können diese Einblicke in bereits gestartete Scrum Sprints erhalten. Bei Bedarf können diese kontinuierlich an Scrum herangeführt werden. Die Einbindung von erfahrenen Mitarbeitern in Scrum ist ein maßgeblicher Erfolgsfaktor. Der Erfahrungsschatz und das Wissen kann bspw. durch „Daily Meetings“ an wenige erfahrenere Mitarbeiter*innen weitergegeben. Zugleich stellt dieser Kulturwandel in der Baubranche eine große Herausforderung dar (Change-Management). Eine langfristige und strategische Ausrichtung des Managements ist notwendig. Kurzfristig sind Mehraufwendungen zu erwarten. Die gewonnenen positiven Erfahrungen und damit verbundene Skalierungspotenziale fördern ein Überdenken der gängigen Vorgehensweisen. Entsprechend einem kontinuierlichen Verbesserungsprozess sind Optimierungspotenziale und effizientere Bauprozesse zu identifizieren.⁵²

Im Folgenden wird die Anwendung von Scrum aus der Sichtweise eines Scrum Masters für einen beispielhaften Prozess in einem Bauprojekt dargestellt.

Aufbauend auf der Projektinitiierung und dem damit verbundenen Entwickeln des Product Backlogs (Projektziele), werden diese auf einem entsprechenden Scrum Board (vgl. Abbildung 8) festgehalten. Im Idealfall wird dieses anschließend auf ein digitales Board übertragen und fortlaufend erweitert.

Scrum Sprint:

Auf Basis der grundsätzlichen Anforderungen bzw. Bedarfsermittlung über das Product Backlog findet die Planung des bevorstehenden Sprints statt.⁵⁴ Die Ziele der einzelnen Sprints orientieren sich am zuvor festgelegten Meilensteinplan. Das Projektziel wird in kleinere sog. „Etappenziele“ gegliedert. Meilensteine sollen die Zielerreichung gewährleisten. Ein entscheidender Meilenstein kann bspw. die „Baugenehmigung“ sein. Um diesen Meilenstein zu erreichen sind folgende übergeordneten Aufgaben für den Sprint denkbar:

• Genehmigungsplanung
• Standsicherheitsnachweis
• Brandschutzkonzept
• Bauphysikalische Nachweise etc.

Um diesen Meilenstein zu erreichen, müssen die entsprechenden Arbeitspakete ausgewählt und bearbeitet werden. Die Aufgaben werden entsprechend Ihrer Priorisierung und Vakanz für den jeweiligen Sprint vom Development-Team ausgewählt. Sollten sich während der Bearbeitung des Sprints (Baugenehmigung) weitere Aufgaben ergeben, werden diese im Sprint Review angemerkt und im nachfolgenden Sprint Planning berücksichtigt. Die definierten Ziele des angefangenen Sprints sollen nicht erweitert werden, um diese im vorgesehenen Zeitraum bearbeiten zu können.

Die Herausforderung des Development-Teams besteht in der Auswahl der Aufgaben hinsichtlich:

• Priorisierungsgrad der Aufgabe
  Welche Unterlagen sind zwingend zur Bearbeitung des Bauantrags notwendig und welche können gegebenenfalls nachgereicht werden, ohne den Prüfungsprozess zu verzögern?
• zeitlichem Umfang der Aufgabe
  Können die angestrebten Unterlagen im avisierten Sprint-Zeitraum vollständig bearbeitet werden oder ist hierfür ein weiterer Sprint notwendig?
• Einfluss auf nachfolgende Vorgänge
  Eine verspätete Baugenehmigung verursacht Verzögerungen bei nachfolgenden Sprints.

Diesen Herausforderungen wird u. a. mit Hilfe von sog. Story Points begegnet. Story Points bilden eine Maßeinheit, um den Gesamtaufwand einschätzen zu können, der für die vollständige Umsetzung eines Product Backlog Eintrags oder einer anderen Arbeit nötig ist. Jedem Eintrag wird eine gewisse Punktzahl verliehen. Die Relation der Story Points zueinander steht im Vordergrund.

„Wird ein Story-Point mit 1 Punkt bewertet, sollte dieser vom Umfang nur halb so groß sein wie ein Story Point, welcher mit 2 Punkten bewertet wird. Die Skala kann für jedes Projekt individuell definiert werden. Entscheidend ist das Verhältnis der bewerteten Aufgabenpaketen zueinander. Skalierungseffekte bei wiederkehrenden Aufgaben sind zu berücksichtigen.“

Beispiel:

Eine Baustellenbelegschaft wird durch wiederholte Arbeitsabläufe effizienter und produktiver. Als Beispiel kann der Rohbau von mehreren Geschossen genannt werden. Diese Erfahrung und weitere Kenntnisse jedes Einzelnen im Scrum Team beeinflussen die Bewertung der Story Points. Hierzu dient folgendes theoretisches Beispiel bei gleichbleibenden Geschossflächen: Rohbau EG = 10 Story Points | […] | 5.OG = 8 Story Points | […] | 10.OG = 6 Story Points

Die vorangehende Einschätzung über Story-Points verbessert den Zielerreichungsgrad eines Scrum Teams. Die Auswahl der Maßnahmen für den nächsten Sprint wird vereinfacht. Vorgenommene Ziele sind plausibel und erreichbar. Steht ein neuer Sprint bevor, kann das Development-Team aufgrund der Erfahrung eine bessere bzw. schnellere Beurteilung treffen. Fehleinschätzungen werden reduziert. Treten Fehleinschätzungen auf, werden die qualitativen Abweichungen im Sprint Review festgestellt und in der abschließenden Retrospektive untersucht.⁵⁵

Die Sprint Performance eines Scrum Teams kann über ein digitales Dashboard aufgezeigt werden. Dazu werden die Informationen und Erkenntnisse eines Sprints gesammelt. Allen Mitgliedern des Scrum Teams bietet sich die Möglichkeit, eine Übersicht zu den aktuellen Arbeitsständen im Sprint zu erhalten. Ziel ist nicht die Überwachung der Tätigkeiten einzelner Mitglieder, sondern der Fokus der Scrum Teams auf das Ziel des Sprints bzw. die Gesamtaufgabe. Die Darstellung eines Sprint Dashboards auf Mitarbeiterebene ist ebenso möglich. Zusammenfassend sollen vorhandene Daten visualisiert werden, um diese leicht verständlich zu machen und die Motivation des gesamten Scrum Teams zu fördern.