Home Blog Wieso Agilität in der Architektur so schwer ist – eine Betrachtung anlässlich der neuen Diskussion um das Berliner Stadtschloss

Wieso Agilität in der Architektur so schwer ist – eine Betrachtung anlässlich der neuen Diskussion um das Berliner Stadtschloss

Das Berliner Stadtschloss: Prestigebau, zentrale Großbaustelle und ewiges Streitobjekt. Jetzt machte der Architekt Stephan Braunfels mit der Idee Schlagzeilen, die Ostfassade des Stadtschlosses kurzerhand wegzulassen, um so die Innenhöfe des Schlosses in Richtung Spree und Alexanderplatz zu öffnen. Wenig überraschend reagiert der eigentliche Architekt des Humboldtforums, Franco Stella, nicht gerade begeistert: Die Idee käme zu spät, die Fundamente seien bereits gesetzt und vor allem habe schließlich nicht Braunfeld, sondern eben Stella den Architekturwettbewerb für das Stadtschloss gewonnen. Und der Verzicht auf die Ostfassade würde zudem keinesfalls die Kosten reduzieren, so Stella, im Gegenteil: Eine solche Änderung ziehe eine komplette Neuplanung nach sich, was auf einen Baustopp von mindestens drei Jahren hinauslaufen und die Kosten entsprechend in die Höhe treiben würde. Trotzdem: Medien und Öffentlichkeit haben den Vorschlag längst aufgenommen und diskutieren wieder begeistert mit.

So weit, so vorhersehbar: eine Geschichte aus Konkurrenz, Eitelkeit und Meinungsmache und die Frage, ob sich Fachjurys und Öffentlichkeit jemals einig werden. Mal ganz davon abgesehen dass große Teile der Berliner Bevölkerung – ich selbst inklusive – zum Thema Stadtschloss eigentlich bestenfalls mit den Schultern zucken.

 

Betrachtet man die Angelegenheit aber mit der agilen Brille, steckt doch Bemerkenswertes darin. Drei Jahre Planungsphase und Baustopp, um weniger zu bauen anstatt mehr? Wow. Mir ist durchaus klar, dass ein echter Bau wesentlich komplexer ist als ein zu groß geratenes Lego-Haus und dass von Statik über technische Gebäudeausrüstung, der Anpassung und Fertigung spezieller Bauteile bis hin zur Ausführungsplanung (also der Koordination wann welcher Handwerker was tun sollte) eine Menge Aspekte Beachtung und Zeit erfordern. Dennoch: Zumindest das Ausarbeiten der Pläne müsste auch im Bauwesen agil und damit iterativ möglich sein, was mir Projektmanager aus der Baubranche auch bereits versichert haben. Wenn man zu Beginn die Teile plant und planerisch abschließt, ohne die das Gebäude nicht funktionieren würde, könnte man auf diesen Planungsstand zurückgreifen, auch wenn sich an den nicht so zentralen Teilen etwas ändert oder sie gar wegfallen sollen, wie die Ostfassade des Stadtschlosses.

Überhaupt: Das Weglassen. Auch in der Softwareentwicklung ist das ein oft wunder Punkt. Da hat man Features konzipiert und gebaut, und nun soll man sie einfach weglassen oder gar wieder ausbauen, nur weil die Nutzer sie nicht verwenden?! Auf viel zu vielen Seiten oder in Produkten wird Feature für Feature hinzu addiert, ohne dass diese jemals hinterfragt werden oder ein ungenutztes Element ausgebaut würde. Am Ende verläuft sich der Nutzer in der Vielzahl der Features, die er nicht braucht.

Ein Rückbau der Angebote – mit zahlreichen Plattenbauten in ostdeutschen Kleinstädten ist dies tatsächlich auch in der Architektur schon geschehen, als klar wurde dass man für die schwindenden Einwohnerzahlen keine 17, sondern nur noch 5 Geschosse braucht.

Doch für ein bewusstes und gelungenes Weglassen braucht es zuvor die Analyse der Nutzung bzw. eine ehrliche Befragung der Nutzer, und das sind bei öffentlichen Bauten eben nicht nur die Bauherren, sondern auch die normalen Bürger. Im Falle des Humboldt-Forums entschied 2008 eine Fachjury über den Siegerentwurf in einem Architektenwettbewerb.

Fachgremien, die lange im Voraus entscheiden, woraufhin die Planungsmaschinerie in Bewegung kommt und nur mit enormem Aufwand und Kosten korrigiert werden kann. Auch beim Endlosprojekt des Flughafen BER scheint ein guter Teil der Probleme daher zu rühren, dass Anforderungen sich geändert haben, sei es durch Willkür oder äußere Umstände. Im Zeit- und Kostenplan, der im Falle des BER bereits Anfang der 2000er Jahre aufgesetzt wurde, waren solche Änderungen nicht vorgesehen. Man kann auch sagen: Es war nicht geplant, dass man im Verlauf von 10 Jahren zu neuen Erkenntnissen kommt.

 

Wie schon geschrieben: Architektur ist mit Software nicht zu vergleichen und wer die Vision eines repräsentativen Stadtschlosses oder eines Großflughafen hat, der braucht nicht, wie es die Lean Philosophie nahe legen würde, mit einer Bretterbude oder einer Schotterpiste anfangen. Dennoch bin ich sicher, dass ein iteratives Vorgehen innerhalb des Planungsprozesses, der Mut zum Weglassen sowie der frühzeitige und ehrliche Einbezug aller Nutzer Vorgehensweisen sind, die auch in der Architektur umsetzbar wären und einige Probleme verringern würden.

Wenn man es denn will. Und womöglich liegt da die wirklich grundlegende Schwierigkeit: So lange Architekten (oder zumindest einige, vielleicht viele, zumindest wohl die meisten sogenannten „Stararchitekten“) sich selbst als Künstler verstehen und ihre Arbeit nicht als Entwurf von Gebrauchsobjekten, sondern als Kunstwerke, ist der Anspruch ein anderer. Ein Künstler darf und soll an seiner perfekten Vision festhalten. Nur wer sich um „Nutzer“ statt „Betrachter“ schert, muss sich mit den wandelnden Anforderungen der Realität auseinander setzen.

 

Zumindest in einem Punkt jedoch scheint sich der Stararchitekt Braunfels, der den Verzicht auf die Ostfassade des Stadtschlosses vorschlug, schon an der IT-Welt orientiert zu haben: Er ließ sein iPad mit den Plänen „gedankenverloren“ im Taxi liegen, pünktlich einige Tage vor der offiziellen Vorstellung der Pläne. Medienwirksam lobte er dann einen guten Finderlohn aus, um die geheimen Dokumente zurück zu bekommen, natürlich ohne Erfolg. Solche „Pannen“, die der PR-Strategie in die Hände spielen, kannte man bisher eher von Apple und Co., doch wer weiß: Vielleicht war das ja erst der Anfang dessen, was die Architektur von der IT zu übernehmen bereit ist. Wir bleiben gespannt. Ob mit oder ohne Stadtschloss.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© by leanovate GmbH - Impressum