Case Study – Agilität – Einführung agiles Projektmanagement

Ausgangssituation

Der berufsbegleitende und interdisziplinäre Studiengang Real Estate Management (REM) an der TU-Berlin richtet sich an Interessierte, die bereits in der Immobilienwirtschaft tätig sind. Dies sind in der Regel ArchitektInnen, Stadt- und RegionalplanerInnen, Bau- oder WirtschaftsingenieurInnen, aber auch BetriebswirtInnen und RechtswissenschaftlerInnen. Das thematische Spektrum des Studiengangs orientiert sich am gesamten Lebenszyklus baulich-räumlicher Projekte.

Bei der Projektentwicklung und Projektsteuerung ist der Fokus der Betrachtung stark durch die jeweilige berufliche Spezialisierung geprägt. Leitbild des Qualifikationsprofils im Studiengang ist jedoch der Generalist, nicht der Spezialist. Die Entwicklung der Schnittstellen- und Transferkompetenz steht im Mittelpunkt.

Pro Semester bearbeiten die Studierenden ein reales größeres Bauprojekt in fünf Disziplinen. Die fünf Disziplinen umfassen Stadtplanung und Stadttechnik, Architektur, Ökonomie, Soziologie und Ökologie, sowie das Projektmanagement. Bisher haben die Studierenden in Projektgruppen die einzelnen Disziplinen aufgeteilt und bearbeitet. Jedes Teammitglied wählt eine ihm fachfremde Disziplin. Durch das Bearbeiten der genannten fünf Disziplinen wird es möglich, ein Immobilienprojekt ganzheitlich zu betrachten. Das heißt, es werden auch Wechselwirkungen, Abhängigkeiten und die daraus resultierenden Dynamiken erfasst und berücksichtigt. Dies impliziert zudem ein umfassendes Stakeholdermanagement.

Fünf Disziplinen zu bearbeiten, bedeutet jedoch nicht automatisch ein Projekt auch tatsächlich interdisziplinär und agil zu bearbeiten. Die Immobilienwirtschaft ist durch die Digitalisierung zunehmend von Komplexität geprägt und – aufgrund vielfältiger Erwartungen unterschiedlichster Anspruchsgruppen und dynamischer Umwelten – steigt auch das kooperative Stakeholdermanagement in seiner Bedeutung. In der Konsequenz gewinnen Themen wie agiles Projekt- und Meetingmanagement, Dialogformate in Beteiligungsverfahren, aber auch das Verhandeln mit Stakeholdern immer mehr an Bedeutung im Studiengang. Themen wie Agilität und Selbststeuerung stehen auch im Portfolio von SUB im Fokus. Sowohl im beschriebenen Studiengang als auch in verschiedenen Projekten in der Immobilienwirtschaft haben wir in der Vergangenheit agile und selbststeuernde Ansätze durch die Einführung von agilem Projekt- und Meetingmanagement erfolgreich integriert.

Agiles Projektmanagement bei REM

Im Sommersemester 2019 war das Semesterprojekt erstmals nicht mehr in der Form des klassischen Projektmanagements konzipiert. Stattdessen agierten die drei Projektteam als Scrumteam.

Die oben beschriebenen Disziplinen wurden also nicht mehr auf verschiedene Studierende innerhalb der Projektgruppe verteilt, sondern es wurde wirklich interdisziplinär bearbeitet. Das heißt, die Mitglieder des jeweiligen Scrumteams bearbeiteten alle, einzelne Aufgaben, aus allen Disziplinen. Die Teams arbeiteten dabei in Sprints (definierten Zeitintervallen). Vor jedem Sprint handelten die Teams im Sprintplanning mit den ProjektleiterInnenn – jetzt in der Rolle des Product-Owners – aus, was in den jeweiligen Sprints an Aufgaben zu bearbeiten waren und was am Ende des Sprints das Projektergebnis sein sollte.

Die Teams arbeiteten innerhalb der Sprints selbstorganisiert. Sie führten Daily Scrums durch – Stand-Up`s in dem kurz der Stand der Aufgabenbearbeitung untereinander mitgeteilt wird. Welche Aufgaben sind noch in Bearbeitung, welche in der Qualitätssicherung und welche fertig. In dem Daily zieht sich jedes Teammitglied die Aufgaben, aus den jeweiligen Disziplinen, die er/sie bis zum nächsten Stand-Up bearbeiten möchte – also nach dem Pull- statt Push-Prinzip aus. Die Daily Scrums fanden mittels eines elektronischen Boards statt. In dem Board sind mehrere Spalten vorhanden, die den Prozess transparent abbilden. In der ersten Spalte befindet sich das sogenannte Backlog, hier sind alle Meilensteine und Aufgabenpakete gesammelt, die insgesamt zu erledigen sind, um das Projektziel zu erreichen – eine Machbarkeitsstudie – zu erstellen. Die zweite Spalte bildet das Sprintbacklog ab. Wie beschrieben, befinden sich hier die Aufgaben, die innerhalb des Sprints vom Scrumteam bearbeitet werden. Im Falle der Projektarbeit wurde der Sprint auf vier Wochen angelegt. Nachdem das Sprintbacklog im Sprintplanning I, mit dem Product Owner verhandelt war, kamen die Mitglieder des Scrumteams zusammen, um in dem Sprintplanning II Meeting, die Aufgaben herunter zu brechen und zu schätzen, wie viele Aufgaben in der ersten Woche des Sprints bearbeitet werden können. Außerdem wurde in diesem Meeting gemeinsam besprochen, welche Fachdozenten oder weiteren Stakeholder das Team noch einbeziehen möchte, um Fragen zu klären oder zu einer Thematik Input zu bekommen. Dann in der nächsten Spalte „to do“ wurden die Aufgaben geschoben, die sich jedes einzelne Scrum-Team-Mitglied gezogen hat. In den kommenden Dailys „wanderten“ die Aufgaben von den Spalten „in Arbeit“ in die Spalte Qualitätssicherung und dann in die Spalte „Done“. In dem jeweils folgenden Daily, wurden dann immer die nächsten Aufgaben gezogen, die die jeweiligen Teammitglieder bearbeiten möchten. Idealerweise befinden sich am Ende eines Sprints alle Aufgaben in der Spalte „Done“. Aufgaben die nicht innerhalb des Sprints bearbeitet werden konnten, wandern wieder zurück ins Backlog. Die Pflege des Backlogs ist in der Verantwortung des Product Owners. Aufgaben die sich innerhalb des Sprints ergeben, werden von dem Scrumteam mit aufgenommen. Somit stellt das Board einen „lebenden Organismus“ dar, der atmet.

Meine Aufgabe als Beraterin von SUB war es, den Gesamtprozess zu begleiten und innerhalb der Teams als Scrum Master zu agieren. Die Rolle das Scrum Master ist es als Facilitator – als Befähiger – zu agieren, das Team durch proaktive lösungsorientierte Fragen darin zu unterstützen, die gruppendynamischen Prozesse und das Miteinander und die internen Prozesse zu reflektieren, so dass, das Team Lösungen finden kann, um dysfunktionale Muster zu unterbrechen. Da es sich um ein Masterstudiengang handelt, in dem die TeilnehmerInnen lernen sollen, Immobilienprojekte ganzheitlich in allen fünf beschriebenen Disziplinen zu entwickeln, haben wir darauf verzichtet die Rollen des Product Owner und die des Scrum Masters von den Studierenden ausfüllen zu lassen. 

Mehrwert und Nutzen

Die agile und selbststeuernde Konzeption des Semesterprojekts bedeutete einerseits in iterativen Reviews das inhaltliche Ergebnis zu reflektieren und in den Retrospektiven zu eruieren, wie die Projektgruppe als Team zusammenarbeitete. Es ermöglichte den Studierenden eigenverantwortlich im Dialog mit den Product Ownern und FachdozentInnen die Aufgabenstellung im Projektgeschehen zu reflektieren und anzupassen, anstatt die Arbeit am Ende des Semesters aus der Vergangenheit zu betrachten. Schien der finale Soll-Zustand des Projekts nicht mehr erreichbar zu sein, wurde zuvor häufiger versucht durch ad-hoc Entscheidungen diesen doch noch zu erreichen. Stattdessen wurde nun iterativ das entworfene Leitbild bzw. die Vision angepasst. Dabei wurde stets kritisch hinterfragt, welche Anpassungen vorgenommen werden müssen, um eine reale Umsetzung des Projektes auf der einen Seite möglich zu machen und trotzdem Werte und Philosophie des Leitbildes in anderer Form zu bewahren.

Im Sinne der Selbststeuerung waren die Studierenden nun außerdem in der Verantwortung relevante Themen bzw. Fragen an die jeweiligen FachdozentInnen eigenständig zu entwickeln. Die Dozierenden waren somit nicht mehr allein dafür verantwortlich, zu beachtende Fragestellungen in die Vorlesungen zu integrieren.Durch die neuerliche Konzeption des Semesterprojekts lernten die Studierenden nicht nur die Vorteile des interdisziplinären Arbeitens, sondern auch agiles Projektmanagement in Form des Frameworks „Scrum“ in der Anwendung kennen. Sie können dieses nun in die eigene Organisation tragen, ggfls. weiterentwickeln und implementieren.

Im wissenschaftlichen Kontext lässt sich somit weiter untersuchen, inwiefern agiles Projektmanagement in Form von Scrum in der Immobilienwirtschaft/Projektentwicklung anwendbar ist. Von Interesse ist außerdem, wo diesem Ansatz Grenzen gesetzt sind und wie adaptiv und integral im realen Projektmanagement vorgegangen werden kann.

Zukunftsperspektiven

Auf Grund der ausgesprochen positiven Rückmeldungen seitens der Studierenden und der ProjektleiterInnen, werden wir das agile Projektmanagement im zweiten Semester des REM Masterstudienganges beibehalten. Im Sinne agiler Prinzipien haben wir das Format jedoch in Teilen angepasst.

Für die Product Owner, die auch am Ende des Semesters die Arbeiten der Studierenden beurteilen, ist es enorm wichtig, im Rahmen der zu bearbeiteten Machbarkeitsstudie zu verstehen, welche Zusammenhänge, Logiken, Dynamiken und Wechselwirkungen zwischen den einzelnen Disziplinen im Projekt entstehen. Nur so kann eingeschätzt werden, ob die erarbeiteten Strategien und Maßnahmen der Studierenden, folgerichtig sind und somit das Projekt realisiert werden könnte. So soll nun in den Reviews – den inhaltlichen Meetings, die mit dem Scrumteam, dem Product Owner stattfinden – das elektronische Board der einzelnen Projektgruppen stärker genutzt werden. In den Reviews geht es dann auf der einen Seite darum, die Teil-Ergebnisse vorzustellen und zu reflektieren, die bisher bearbeitet und fertig gestellt worden sind. Auf der anderen Seite sind die Studierenden eingeladen Zusammenhänge, Abhängigkeiten und Wechselwirkungen mittels des elektronischen Boards, in dem auch die dazugehörigen Dokumente und Anhänge abgespeichert sind, darzustellen.

Den Fachdozierenden sollte außerdem stärker die Möglichkeit gegeben werden auch außerhalb der Lehrveranstaltungen den Prozess mit zu verfolgen und wichtige Themen/Aufgaben aus ihrer Rolle als Experte/in einer Disziplin (Ökologie, Soziologie, Städtebau, Architektur etc.) einzubringen. Dafür werden die FachdozentInnen der beschriebenen Disziplinen, ebenso einen Zugang zu den elektronischen Boards erhalten.

Maßgeblich ist jedoch, dass die Themen/Aufgaben der Fachdozierenden nur in das Backlog eingestellt und dort ergänzt werden können. Es sollen dazu max. 2 DIN A4 Seiten angehängt werden, in denen die Themen und genauen Aufgabenstellungen verständlich gemacht werden. Der Product Owner bringt diese dann in den jeweiligen Sprintbacklog ein, anhand dessen die Zielstellungen für die nächste Sprint-Etappe verhandelt wird. Am Ende entscheidet das Projektteam jedoch eigenverantwortlich, welche Themen/Aufgaben sie aufnehmen wollen und wann und wie diese umgesetzt werden.