Agil sein oder nicht sein: Ist das wirklich noch die Frage?€¦ · Scrum wurde von Schwaber und Sutherland entwickelt (Schwaber, 2004). Was Scrum unter anderem auszeichnet ist, dass

VDI-Bautechnik Jahresausgabe 2019/2020

40

Technologie / Wissenschaft / Beruf

Bild 1. Planung als ein Prozess der Transformation

Bild 2. Planung als ein Prozess des Flusses (Workflows)

Bild 3. Planung als ein Prozess der Wertschöpfung

Agil sein oder nicht sein: Ist das wirklich noch die Frage? Agile Design Management in der Planungsphase von Bauvorhaben

S. T. Demir

Die Planungsphase eines Bauprojekts ist besonders dynamisch. Wie lässt sich bei den vielen Änderungen und plötzlichen Anpassungen immer noch der Überblick behalten? Das Agile Design Manage-ment ist die Antwort. Doch agiles Projektmanagement erfordert andere Methodiken und einen Kulturwandel. Dazu muss so mancher Fallstrick aus dem Weg geräumt werden.

Alles im Plan – Aber wie?

Planung ist geprägt durch ein empirisches Vorgehen, dass sich durch die Aufnahme von Kundenanforderungen itera-tiv dem Ziel nähert. Die Ergebnisse werden mit einem Plan visualisiert. Planung der Planung beschreibt den Weg, um dieses Ziel zu erreichen. Das Besondere hierbei: Ziele und Kundenanforderungen können sich verändern, da mit zu-nehmender Zeit neue Erkenntnisse entstehen. Demnach ist das Umfeld während der Planungsphase eines Bauprojek-tes dynamisch. Dies erfordert ein iteratives Management-system, das auf kurzen Zyklen und schnellen Feedback-schleifen basiert, um auf sicherem Weg zur perfekten Lö-sung zu gelangen. Diese Anforderung hat zur Entwicklung von Agile Design Management geführt, das heißt zur An-passung des Scrum-Ansatzes an die Planungsphase von Bauvorhaben. Ziel des Agilen Design Managements ist es, die Koordination, das Schnittstellenmanagement, die Zu-sammenarbeit und die Transparenz in allen Planungspha-sen zu erhöhen.

Transformation, Fluss und Wertschöpfung: drei Hauptansätze zum Managen der Arbeit

Eine unzureichend flexible und umfassende Planung hat bei der zunehmend hohen Komplexität von Bauprojekten gravierende Folgen. Dazu gehören unzulängliche Termin-treue, Mehrkosten durch Mängel und unzufriedene Bau-herren. Um die Leistung von Bauprojekten zu erhöhen, ist eine Verbesserung der Planung der Planung unabdingbar. Herausforderungen, denen der Planungsprozess unter an-derem ausgesetzt ist, sind wie folgt:

– Mangelnde Transparenz – Schlechte Koordination und Zusammenarbeit im Auf-

gabenmanagement– Lang andauernde Prüf- und Genehmigungsprozesse – Mangelhafte Integration der Nutzer– Unnötige Funktionen– Kaum nachvollziehbare Protokollstrukturen – Mehrseitige Terminpläne mit sehr vielen Aktivitäten,

die nicht lesbar sind.

– Planungsfehler und Planungskollisionen – Unvollständige Planungsergebnisse am Ende der Pla-

nungsphase Während sich die Planung überwiegend mit der Lösung von technischen Problemen und Details befasst, gab es we-nig Entwicklung im Bezug zur Steuerung der Arbeit selbst. Drei Hauptansätze können in Betracht gezogen werden, um die Steuerung der Arbeit innerhalb der Planung der Pla-nung zu beschreiben.

– Planung ist ein Transformationsprozess – Planung ist ein Flussprozess – Planung ist ein Wertschöpfungsprozess

Nachfolgend werden diese drei Ansätze beschrieben. Die Wahrnehmung, dass Planung ein Transformationsprozess ist, beruht darauf, dass Anforderungen und Bedarf zu Be-ginn ermittelt werden und diese dann in einen Plan trans-formiert werden. Am Ende entsteht die Planung eines Pro-jektes.

Dr. Selim Tugra Demir

[email protected] Projektmanager fischer Consulting GmbH Klaus-Fischer-Straße 1, 72178 Waldachtal

Die in Bild 1 dargestellte Vorgehensweise konzentriert sich darauf, die Planungsaufgabe durch die Unterteilung in Teil-aktivitäten zu lösen. Es werden Projektstrukturpläne und Kritische-Pfad-Methoden in Betracht gezogen, um die Pla-nung der Planung zu koordinieren und zu steuern. Beim zweiten Ansatz, Planung als Flussprozess, liegt der Schwerpunkt bei der Organisation und Verbindung von In-formationsflüssen mit den Planungsaktivitäten und Arbeits-abläufen. Diese Informations- und Arbeitsflüsse haben das Ziel, den Zeit- und Arbeitsaufwand für alle notwendigen In-formationen, die informell und mündlich übertragen wer-den können, zu reduzieren. Das ist visualisiert in Bild 2. Das Koordinieren und Steuern der Informationsflüsse in-nerhalb der Planungsphase ist ein wichtiges Thema. He-rausforderungen, denen die Beteiligten während der Bau-phase ausgesetzt sind, sind teilweise das Ergebnis von inef-

VDI-BautechnikJahresausgabe 2019/2020

41


Bild 4. Anforderungen an die Methodik anhand der Projektphasen

Bild 5. Das magische Dreieck in einem traditionellen und agilem Projektumfeldfektiver und ineffizienter Kommunikation in der Planungs-phase. Der wertschöpfende Ansatz setzt den Fokus einzig und al-lein auf die Kundenanforderungen. Der Schwerpunkt liegt dabei, den Kunden zu verstehen. Die Verbesserung der Pla-nung ist im Einklang mit der Verringerung des Wertverlus-tes. Bild 3 veranschaulicht den Ansatz des Wertschöpfungspro-zesses. In diesem Zusammenhang ist es notwendig, Itera-tionen, die auf kurzen Zyklen und schnellen Feedback-schleifen basieren, zu implementieren, um kontinuierlich zur perfekten Lösung zu gelangen. Alle drei Hauptansätze zur Steuerung der Arbeit müssen bei der Planung der Planung in Betracht gezogen werden. Al-lerdings werden die Planungsphasen in der Regel mit Gant-Charts geplant und durchgeführt. Diese Art der Planungs-methodik eignet sich zur Überprüfung der Machbarkeit ei-nes Projekts, aber nicht zur Steuerung der Arbeit selbst. Die Ursache liegt darin, dass das Gant-Chart ein lineares Vorge-hen ist, welches auf der Annahme beruht, dass eine Aktivi-tät nach der anderen erledigt werden kann. In der Ausfüh-rungsphase von Bauprojekten wird solch eine Linearität mit Taktplänen erreicht beziehungsweise angestrebt (z. B. Binninger und Wolfbeiß (2019)). In der Planungsphase von Bauprojekten besteht allerdings die Anforderung nicht auf Linearität, sondern auf Agilität und die damit verbundene Flexibilität. Bild 4 veranschaulicht die Projektphasen und die damit verbundenen Bedarfe an das Managementsystem. Der ite-rative beziehungsweise agile Bedarf in der Planungsphase begründet sich dadurch, dass ein Planungsstand entwickelt und dem Kunden übergeben wird. Der Kunde gibt Feed-back, dass dann wiederum eingearbeitet wird. Der iterative Zyklus wird solange durchlaufen, bis der Kunde zufrieden ist. Daher ist es in der Planung erstrebenswert, nicht rigide, sondern agil zu sein.

Mit „agil“ zur neuen Magie im vorhandenen Dreieck

Das magische Dreieck des Projektmanagements zeigt die drei Paramater, die ein Projekt und dessen Erfolg bestim-men: Zeit, Kosten und Leistung. Diese sind in Bild 5 in Form von Dreiecksspitzen dargestellt. Im Idealfall werden bereits vor Projektbeginn der Leistungsumfang, die Pro-jektkosten und die Terminschiene festgelegt. Anschließend wird darauf die Projektsteuerung aufgebaut. Das traditio-nelle Vorgehen besagt Folgendes: Verändert sich eine der drei Größen, hat dies direkte Auswirkungen auf die beiden anderen Parameter. Demnach muss die Varianz von einem Element des Dreiecks mit den anderen ausgeglichen wer-den. Dies führt zwangsläufig zu einer Veränderung der Pro-jektparamater und den damit verbundenen Projektrahmen-bedingungen. In Bauprojekten wird auf den vertraglich de-finierten Leistungsumfang bestanden, was wiederum dazu

führt, dass bei einer Nichteinhaltung die Kosten und die Termine variieren. Wie in Bild 5 veranschaulicht wird mit agilen Management-ansätzen das magische Dreieck auf den Kopf gestellt (Owen et al., 2006; Owen und Koskela, 2006a; Owen & Koskela, 2006b). Der Schwerpunkt liegt auf der Kooperation und Zu-sammenarbeit mit dem Kunden, anstelle von Vertragsver-handlungen hinsichtlich des Leistungsumfangs (Agile Alli-ance, 2001). Im agilen Projekt wird der Leistungsumfang laufend angepasst, aber Kosten und Termine werden zu Be-ginn fixiert. Die Adaption des agilen Managements auf die Planungsphase des Bauprojekts ist im Moment noch nicht möglich. Es erfordert einen enormen organisatorischen Aufwand, um den Wandel zur Agilität aufgrund der vorhan-denen komplexen, unflexiblen Struktur erfolgreich zu meistern. Diese Umstellung bedeutet, auftretende Barrie-ren und Herausforderungen anzunehmen, die einen Wan-del der Prozesse, der Menschen, der Orte und der techni-schen Rahmenbedingungen mit sich bringen. Mit Hinblick auf die integrale Projektabwicklung (Initiative-Teambuil-ding, 2017) könnten sich zwar hier in Zukunft Barrieren re-duzieren, dennoch wird eine direkte Adoption von Agilen Methoden auf die Bauplanung nicht angestrebt.

Den Ball im Spiel halten: Der Ursprung von Scrum

Scrum ist die am weitesten verbreitete agile Management-methodik in der Softwareentwicklung und wird in vielen anderen Branchen eingesetzt. Ursprünglich entstammt der Begriff Scrum den Regeln der Mannschaftssportart Rugby. Er steht für die Möglichkeit, das Spiel wieder aufzunehmen, nachdem der Ball herausgenommen wurde. Die Inspiration zur Namensgebung kam durch einen Artikel von Takeuchi und Nonaka (1986), in dem sie diese Methode mit der Spiel-regel beim Rugby verglichen. Scrum wurde von Schwaber und Sutherland entwickelt (Schwaber, 2004). Was Scrum unter anderem auszeichnet ist, dass es einen einfachen Rahmen bildet für die schnelle Entwicklung einer Software-lösung. Bei der Einführung müssen drei Rollen etabliert werden: Produkteigentümer, Scrum-Master und Entwick-lungsteam. Der Produkteigentümer definiert die User Sto-ries (Anforderungen) des Product Backlogs, dies in der Re-gel mit dem Eigentümer und Nutzer. Darüber hinaus priori-siert der Produkteigentümer die zu erledigenden User Sto-ries im Product Backlog. Das Entwicklungsteam entwickelt die Softwarelösung. Der Scrum-Master trainiert und lehrt die Methodik. Scrum bedient sich einer iterativen Herangehensweise, bei der die Iterationen Sprints genannt werden. Ein Sprint ist ein fester Zeitraum von einer bis zu vier Wochen mit einer Präferenz für die folgenden Punkte:


42


Bild 6. Die Scrum-Methodik und deren Herausforderungen für die Planung der Planung im Bauprojekt

– Kürzere Intervalle. In jedem Sprint wird das Scrum-Team ein Produkt entwickeln und liefern.

– Schrittweite. Jedes Inkrement ist eine erkennbare, sichtbar verbesserte, funktionierende Teilmenge der Softwarelösung.

Das Product Backlog ist eine geordnete Liste der gewünsch-ten Uster Stories. User Stories beschreiben, was, von wem, bis wann zu erledigen ist. Zu Beginn des Sprints arbeitet das Team mit dem Produkteigentümer zusammen, um die Arbeit auszuwählen, die sie während eines Sprints liefern werden. Das Team trifft sich täglich, um sicherzustellen, dass die Laufrichtung noch in Ordnung ist. Das Meeting ist kein Statusmeeting. Es ist mehr die Möglichkeit, die Arbeit für den kommenden Tag zu koordinieren und zu synchroni-sieren. Das Entwicklungsteam beantwortet drei Fragen:

– Was sollte bis heute erreicht werden? – Was wird bis morgen erreicht? – Gibt es Faktoren, die meinen Fortschritt gefährden?

Nach dem Sprint Review überprüft das Team seinen Pro-zess. Für weitere Details zur Scrum-Methodik wird auf die Literatur verwiesen (siehe zum Beispiel Schwaber, 2004; Hunt, 2006; Fernandez & Fernandez, 2008; Fernandes & Sousa, 2010). Die methodische Vorgehensweise von Scrum ist in Bild 6 visualisiert. Die in Bild 6 visualisierten Blitze stellen die Herausforde-rungen bei der Übertragung des Scrum-Gedankens auf die Bauplanung dar. Es ist unklar, wer der Produkteigentümer ist. Sollte diese Rolle dem Bauherren zukommen, wäre die Fähigkeit, die User Stories zu priorisieren, aufgrund des fehlenden technischen Wissens fragwürdig. Darüber hi-naus gibt es in der Planungsphase verschiedene Ergebnisse in Form von Arbeitspaketen und Aufgaben. Der damit ver-

bundene Detaillierungsgrad innerhalb der User Stories im Product Backlog ist unklar. Dasselbe trifft auch für den De-taillierungsgrad der Aufgaben zu, die im Scrum-Board er-scheinen sollen. Planungsteams bestehen in der Regel aus einer Reihe von verschiedenen Disziplinen. Scrum sollte nicht mit mehr als 20 Teammitgliedern angewendet wer-den. Auch bei kleinen Bauvorhaben (Investitionen unter 10 Mio. Euro) kann diese Grenze schnell überschritten wer-den. Darüber hinaus arbeiten die Planungsteams an ver-schiedenen Orten, sodass es schwierig ist, sich für den täg-lichen Sprint zu treffen. Zu guter Letzt sind größere Pla-nungsänderungen nicht erwünscht. Mit konventionellen und gängigen Planungsansätzen ist es fast unmöglich, das Projekt in unabhängige Module zu unterteilen, die eine ei-genständige Bearbeitung ermöglichen. Änderungen sind fast immer von großer Tragweite und führen zu einem er-höhten Arbeitsaufwand für die Fachplaner. Auch wenn mit-tels moderner Ansätze wie Modularisierung und Standardi-sierung gearbeitet wird, ist die Zahl der Projekte, die diese Ansätze anwenden und erfolgreich abgeschlossen werden, relativ gering. Daraus lässt sich schließen, dass der Scrum-Ansatz aus der Softwareentwicklung nicht 1 : 1 auf die Pla-nungsphase von Bauprojekten übertragen werden kann. Stattdessen wurde ein hybrides Vorgehen entwickelt. Der Schwerpunkt liegt bei der Adaption des Scrum-Gedankens auf der Planung der Planung, durch die Integration von Ele-menten des Lean Shopfloors und des Lean Constructions. Dies wurde als Agile Design Management konzipiert. Das Ziel des agilen Design Managements ist es, die Koordinati-on, das Schnittstellenmanagement, die Zusammenarbeit und Transparenz in allen Planungsphasen zu erhöhen, um dadurch sowohl die Effektivität als auch die Effizienz zu verbessern.


43


Wer agil sein will, muss agil werden

Vorhandene rigide Strukturen sind nicht unterstützend bei der Implementierung von agilen Methoden. Die Aufbau- und Ablauforganisation muss aufeinander abgestimmt sein. Ziel ist es, den richtigen Absorptionsgrad an Informationen zur richtigen Zeit an der richtigen Stelle zur Verfügung zu stellen. Daher wird das Agile Design Management in die bestehende Organisationsstruktur integriert. Dies erfolgt zu Beginn der Planungsphase in einem Workshop. Ergebnisse eines solchen Workshops sind in der Bild 7 veranschau-licht. In Bild 7 wurde die Aufbau- und Ablauforganisation in vier Ebenen unterteilt. Lenkungskreis, Projektleitung, Pla-nungsteam und Arbeitsgruppen. Die erforderlichen Metho-den und Werkzeuge sowie deren Anwendungsebene wer-den anschließend definiert. Die Workshops und Bespre-chungsroutinen werden so aufeinander abgestimmt, dass es einen Anweisungs- und Informationsfluss gibt. Im obi-gen Beispiel wurden folgende Sitzungen abgehalten: eine dreimonatige Sitzung des Lenkungskreises, eine vierwö-chentliche Sitzung der Vorschauplanung (zur Identifizie-rung und Priorisierung der Arbeitspakete) und eine zwei-wöchentliche Sitzung des Planungsteams (vor der digitalen

Kanbantafel). In der Fallstudie von Bild 7 wird die Kanban-tafel – die sich aus dem Scrum-Board ableitet – auf der Ebe-ne des Planungsteams eingesetzt. Individuelle Lösungen wurden von den Arbeitsgruppen und Fachbereichen vorge-schlagen. Ein Team stimmte der Verwendung einer Kan-bantafel zu, ein anderes bestand darauf, den herkömmli-chen Zeitplan zu verwenden. Konflikte dieser Art bringt der kulturelle Wandel typischerweise mit sich. Es braucht Zeit, bis sich alle Planungsbeteiligten daran gewöhnt haben, ihre Arbeit vollständig mit agilen Werkzeugen zu steuern.

Der rote Faden in der Geschichte: User Story Definition

Bei der herkömmlichen Scrum-Methode werden die User Stories vom Produkteigentümer definiert. Im Gegensatz zur Softwareentwicklung erfordert die Planung von Bauvorha-ben eine Reihe von Experten, um die verschiedenen Eigen-schaften des Objekts zu gestalten. Die steigende Nachfrage an sich stetig weiterentwickelnden Technologien und An-sätzen zur Digitalisierung führt zu einer zunehmenden Fragmentierung und Komplexität. Dies erschwert es den Projektleitern, die User Stories zu definieren. Da die Identi-fikation und Definition von User Stories Expertise erfordert, wird diese im Zuge des agilen Design Managements durch die Teilprojektleiter eingeholt. Ein Teilprojektleiter verant-wortet eine Planungsdisziplin, wie beispielsweise Architek-tur, Tragwerk oder Elektroplanung. In einem gemeinsamen Workshop werden die Arbeitspakete für die aktuelle Pla-nungsphase identifiziert und auf einem Brown Paper ge-sammelt. Falls möglich, erfolgt anschließend eine Priorisie-rung ohne zeitlichen Bezug. Beispiele für solche Arbeitspa-kete sind: Durchbruchsangaben, Mock-up-Konzept oder Lastangaben. Das Ergebnis eines solchen Workshops ist in Bild 8 (links) visualisiert. Die Priorisierung der Arbeitspakete erfolgt durch die Vor-schauplanung. In einem Folgeworkshop wird die Haftnotiz vom Brown Paper entfernt und in eine zeitliche Abfolge ge-bracht (Bild 8 rechts). Im Zuge der Vorschauplanung wird definiert, wann jedes der zuvor identifizierten Arbeitspake-te abgeschlossen sein muss. Demnach erfolgt die Priorisie-rung der Arbeitspakete über einen Zeitbezug. Damit lassen sich diese in User Stories übersetzen. Die Farbkodierung

Bild 8. Prozessanalyse (links) und Vorschauplanung (rechts) Abb.: ATP architekten ingenieure

Bild 7. Anpassung der Aufbau- der Ablauforganisation Abb.: ATP architekten ingenieure


44


der Haftnotiz beschreibt die Disziplin (i. e. Architektur, Tragwerk etc.). Der Inhalt der Haftnotiz beschreibt, was ge-macht werden muss. Der Zeitstrahl priorisiert die User Sto-ries auf Kalenderwochen-Basis. Bei der erstmaligen Durch-führung dieses Workshops ist es bemerkenswert, dass die Fertigstellungstermine für Arbeitspakete in der Regel ent-weder am Anfang oder am Ende der Phase liegen. Zwi-schen Beginn und Ende gibt es in der Regel keine Prüfläufe oder Zwischenstandsmessungen. Dies führt zu Engpässen, was wiederum zu Unzufriedenheit der Kunden führen kann. Im agilen Design Management werden die User Sto-ries taktbasiert geplant, Puffer eliminiert und Zwischenprü-fungen integriert. Dies schafft mehr Agilität und ermöglicht es dem Planungsteam, die eigenen Ressourcen besser ein-zusetzen. Darüber hinaus werden Problem-Ursache-Lö-sung (PUL) Punkte identifiziert und in die PUL-Listen auf-genommen. Die Workshop-Ergebnisse werden anschlie-ßend jeweils digitalisiert und an alle Teilnehmer verschickt.

Alles im Blick: Die Arbeit mit Kanban

Jedes Arbeitspaket besteht aus mindestens einer oder meh-reren Aufgaben. Die Aufgaben sind flexibel und können je-derzeit angepasst werden. Denn im Laufe der Planung kön-nen neue Aufgaben entstehen und bestehende Aufgaben re-dundant werden. Im Gegensatz zum herkömmlichen Scrum in der Softwareentwicklung ist es sehr schwierig, tägliche Meetings für die Bauplanung abzuhalten. Die ver-schiedenen Disziplinen befinden sich in der Regel an ver-schiedenen Standorten. Je nach Projektkonstellation kann die Kanbantafel digital oder physisch erfolgen. Bei physi-schen Kanbantafeln wird ein Großraumbüro empfohlen. Die Planungsbeteiligten sollten in der Lage sein, sich min-destens zwei Tage lang zu treffen und zu arbeiten. Falls dies nicht möglich ist, kann die Kanbantafel den Beteiligten digi-tal zur Verfügung gestellt werden. Hierzu gibt es mehrere Lösungen auf dem Markt, die evaluiert und auf das Projekt angepasst werden können. Ein Beispiel solch einer digita-len Kanban Tafel befindet sich in Bild 9 (rechts). Was die digitalen und physischen Versionen gemeinsam ha-ben, ist, dass beide im Team gemeinsam konzipiert und va-lidiert werden können. Ein Beispiel ist in Bild 9 (links) auf-geführt. Eine bewährte Struktur ist die Detaillierung der aktuellen Woche, und eine Vorschau der nächsten drei Wo-chen, sodass in Summe eine Vorschau von einem Monat auf der Kanbantafel abgebildet wird. Ein wesentlicher Vorteil der Steuerung der Arbeit mit den Kanbantafeln liegt in der

Verkürzung der Besprechungsdauer. So wurden beispiels-weise im Rahmen der Vorplanung eines Anlagenprojekts die regelmäßigen Meetings von fünf Stunden auf eine Stun-de reduziert. Dies ist auf den systematischen Aufbau der Sit-zungen zurückzuführen. Die Sitzungen an der Kanbantafel sind prozessorientiert. Sie befassen sich nur mit Aufgaben, die derzeit Probleme haben. Diese sind mit einem roten Punkt gekennzeichnet. Dieser hohe Fokus macht die regel-mäßigen Besprechungen effektiver.

Fazit: Agil sein oder nicht sein ist keine Frage mehr.

Da vor allem frühe Planungsphasen eines Bauprojekts eine höhere Dynamik als späte Planungsphasen haben, ermögli-chen iterative Methoden mit einer taktbasierten Arbeitsver-teilung die Reduktion der Komplexität. Dies führt wieder-um zu mehr Effektivität und Effizienz in der Planungspha-se, aber auch im Prozess der Planung der Planung selbst. Auch wenn eine direkte Übertragung der Scrum-Methode in die Planung der Planung nicht möglich ist, bietet die Adaption bereits Lösungen zu aktuellen Herausforderun-gen. Durch die Umsetzung des agilen Design Managements in vergangenen Projekten wurden bereits folgende Verbes-serungen erzielt:

– Transparenz der laufenden und abgeschlossenen Auf-gaben und Arbeitspakete.

– Kollaborative Planung der Planung. – Gemeinsame Priorisierung von Arbeitspaketen und

verwandten Aufgaben.– Bessere Identifizierung und Kommunikation von Pro-

blemen und Risiken.– Integration von Nutzern und Fachabteilungen.– Koordination verschiedener Planungsdisziplinen un-

tereinander.– Schnelle Eskalation von Problemen durch wiederkeh-

rende koordinierte Meetings.– Erhöhte Teammotivation durch Übertragung von

mehr Verantwortung insbesondere auf jüngere Fach-planer.

– Reduzierung der Arbeitsbelastung der Mitarbeiter. – Besserer Einsatz von Ressourcen durch taktbasierte

Planung.– Der richtige Informationsgrad, zum richtigen Zeit-

punkt, am richtigen Ort.Agiles Design Management verwendet die Prinzipien des traditionellen Scrum. Projekte, die mit Risiken und Unsi-cherheiten zu kämpfen haben, Fast-Track-Projekte und

Bild 9. Konzipierung Kanban Steuerung (links) digitale Kanban Steuerung (rechts) Abb.: ATP architekten ingenieure (links); KanDo – ATP architekten ingenieure und M&P Business Solutions (rechts)


45


© V

DI F

achm

edie

n G

mbH

& C

o. K

G, D

üsse

ldor

f 20

19

Projekte mit einer starken Parallelisierung zwischen Pla-nung und Ausführung haben die größten Vorteile bei der Anwendung des agilen Design Managements. Weitere Ent-wicklungen sind notwendig zur Erarbeitung von angemes-senen Kennzahlensystemen für die Planung der Planung. Das Besondere am Agile Design Management liegt darin, dass das Verhalten und das damit verbundene Zusammen-spiel der Disziplinen nicht verändert wird. Es ist eine For-malisierung, Strukturierung und Visualisierung der Art-

und Weise wie bereits in der Planungsphase zwar gearbei-tet, allerdings bisher nicht geplant wurde.

LiteraturAlliance, A.: Agile Manifesto. 2001, https://agilemanifesto.org/iso/de/mani

festo.html [Zugriff am 01.08.2019].

Binninger, M.; Wolfbeiß, O.: Taktplanung und Taktsteuerung im Schlüsselfer-

tigbau – Einfluss der Losgrößen und Limits in der Taktzeit. In: Bautech-

nik Jahresausgabe 2018/2019, S. 136-142.

Fernandes, J. M.; Sousa, S. M.: PlayScrum – A Card Game to Learn the Scrum

Agile Method. In: Second International Conference on Games and Vir-

tual Worlds for Serious Applications. IEEE Computer Society, Braga,

Portugal, 2010, pp. 52-59.

Fernandez, D. J.; Fernandez, J. D.: Agile Project Management – Agilism versus

traditional approaches. In: Journal of Computer Information Systems,

Vol. 49 (2008), Iss. 2, pp. 10-17.

Hunt, J.: Agile Software Construction. Springer Verlag, London, 2006.

Initiative-Teambuilding. 2017, www.initiative-teambuilding.de [Zugriff am:

01.08.2019].

Owen, R.; Koskela, L.: An Agile Step Forward in Project Management. In: 2nd

Speciality Conference on Leadership and Management in Construction

and Engineering. ASCE, Grand Bahama, Bahamas, 2006a, pp. 216-224.

Owen, R.; Koskela, L.: Agile Construction Project Management. In: 6th Inter-

national Postgraduate Research Conference in the Built and Human En-

vironment. University of Salford, Delft, Niederlanden, 2006b,

pp. 22-33.

Owen, R.; Koskela, L.; Henrich, G. et al.: Is Agile Project Management applica-

ble to construction? In: International Group for Lean in Construction

14. IGLC, Santiago, Spanien, 2006, pp. 51-66.

Schwaber, K.: Agile project management with Scrum. Microsoft Press,

Washington, USA, 2004.

Takeuchi, H.; Nonaka, I.: The new production development game – Stop

running the relay and take up rugby. Harvard Business Review, 1986,

pp. 137-146.

Danksagung Herzlichen Dank an die ATP architekten ingenieure und der M&P Business So-lutions für die wertvolle Zusammenarbeit, das Vertrauen und die Bildmateria-lien.

Documents

Agil sein oder nicht sein: Ist das wirklich noch die Frage?€¦ · Scrum wurde von Schwaber und Sutherland entwickelt (Schwaber, 2004). Was Scrum unter anderem auszeichnet ist, dass