Bei der Umstellung vom Wasserfall auf agile Softwareentwicklung wird vor allem bei architektonischen Aspekten oft das Bild des Hausbaus bemüht. Natürlich sind Änderungen am entstehenden Objekt – zum Beispiel Wände einreißen, Rohre neu verlegen – nach grundsätzlich getroffenen Entscheidungen nur noch mit großem Aufwand möglich. Die Betonung liegt dabei jedoch auf: grundsätzlich möglich! Die Entscheidung es zu tun, fällt jedoch immer erst, wenn die Wand schon steht oder zumindest angefangen ist.
Mein Vater ist Architekt und von ihm weiß ich, dass Architekten in der Planungsphase nach jeder Anpassung oft stundenlang mit den Bauherren wieder vor den Plänen sitzen. Häufig fallen die Worte: „Ich kann mir das gar nicht richtig vorstellen, ich muss das erst sehen und durchlaufen können.“ Vielleicht werden deshalb auch Fertighäuser immer beliebter. Bei Fertighäusern habe ich noch nie erlebt, dass die Bauherren das Haus erst sehen, wenn die letzte Badezimmerfliese verlegt ist – schlüsselfertig, wie es so schön heißt. Und noch weniger sind alle Beteiligten von Änderungen während der Bauphase – auch nach detaillierter, gemeinsamer Planung – befreit. Sei es wegen unvorhergesehener Schwierigkeiten beim Bauen selbst, wegen Änderungswünschen der Bauherren oder neuen Ideen des Architekten.
Der Kunde darf nerven
An der Softwareentwicklung mit Scrum gefällt mir so gut, dass es von dem Anspruch Abstand nimmt, ein schlüsselfertiges Produkt abzuliefern. Der Kunde darf bei der Entwicklung mit Scrum den Rohbau bewundern, das Richtfest feiern UND sich bei der Teppichauswahl zehn Mal umentscheiden. Und obwohl sie diese Dinge tun, werden die Architekten nicht arbeitslos oder hören gar auf zu planen – ebensowenig wie Entwickler, Softwarearchitekten, Tester oder Product Owner. Ganz im Gegenteil, sie reagieren bestmöglich auf alle diese neuen, veränderten Anforderungen. Ja und manchmal ärgern sie sich auch darüber, dass die Bauherren das nicht früher gewusst haben. Aber schließlich müssen sie darin wohnen, nicht der Architekt selbst. Anders bei Fertighäusern: Da ärgert sich meist nur der Bauherr, weil er im Endeffekt die kleinen Anpassungen doppelt bezahlt – nur dass wir in der Softwareentwicklung selten ein Produkt zwei Mal bauen.
Doch was tun, wenn wir keine Fertighaus-Software einsetzen können oder wollen? Was wenn der User genau wegen der individuellen Anpassungen und Mitgestaltung den Wert der Software erkennt?
Nehmen wir uns ein Beispiel am neuen Willy-Brandt Flughafen in Berlin. Hier wird vor dem Live-Betrieb mit immer größer werdenden Gruppen die Funktionsfähigkeit der Architektur, der Services, der Nutzerführung etc. geprüft. Die Tests fingen so früh an, dass auch grundlegende Änderungen gemäß dem Nutzer-Feedback noch möglich waren. Test-Passagiere sind mit allem ausgestattet, was es im normalen Betrieb braucht und sollen sich wie ganz normale Passagiere verhalten. Inklusive Beschwerden, Hektik, Mitführen verbotener Gegenstände, Drängeln und Orientierungslosigkeit. Meckern ausdrücklich erwünscht!
Ich warte schon gespannt auf meinen ersten Flug vom neuen Flughafen Berlin aus und werde sicherlich Punkte erkennen, bei denen ich sagen kann: Hätten sie doch nur mich gefragt! Und obwohl ich weiß, dass es viel Nerven kostet, werde ich mich nicht für ein Fertighaus entscheiden.
Kristina Klessmann, Scrum Consultant
4 Antworten zu “Scrum baut keine Fertighäuser”
“…bei architektonischen Aspekten oft das Bild des
Hausbaus bemüht.” Leider ein Kardinalfehler der die Diskussion jedes Mal
in die falsche Richtung lenkt.
Softwareentwickeln hat recht wenig mit Haus bauen zu tun, das hat u.a. folgende
Gründe:
– Softwareentwicklung hat eine Geschichte von 40 bis 50 Jahren, Hausbau mehrere
Jahrtausende
– Fertige Häuser in unterschiedlichsten Ausprägungen können VOR der
Beauftragung besichtigt werden. Dadurch wird die Vorstellung von dem was der
Bauherr möchte deutlich geschärft
– Hausbau folgt physikalischen Gesetzen und daraus entwickelten “Best
Practice” (z.B. nachträglicher Kellereinbau ist verdammt teuer, wenn nicht
unmöglich). Davon ist Softwareentwicklung (aus guten Gründen) Meilenweit
entfernt.
– Das herangezogene Beispiel eines Hausbau ist in der Regel ein Privatvorhaben.
Folglich gibt es nur den einen Bauherr (ggf. den Partner, vielleicht noch die
Eltern) der entscheidet und mit seinen Entscheidungen leben muss. Bei der
Softwareentwicklung spielen in der Regel x Meinungen, Wünsche, Positionen, etc.
eine Rolle.
– usw.
Danke für deinen Hinweis, aber ich verstehe noch nicht, was deine Argumente mit der Grundidee des Blogbeitrages zu tun haben. Kristinas Grundthese ist doch zu zeigen, dass sogar bei physikalischen Bauvorhaben Architekturen “umgebaut” werden, weil beim Testen des Produktes architektonische Ideen als “falsch” eingestuft werden, oder?
Software Architekturen sind selbstverständlich anders und viel leichter veränderbar. Aber das Grundargument, war doch, dass auch auch beim Hausbau die Bauherren sich schwer damit tun, zu verstehen, was sie letzlich bekommen werden und deswegen “vielleicht Fertighäuser immer beliebter werden.”
Sie schreibt auch extra von einem Flughafen … dort trifft doch exakt das zu, was du beschreibst. Etliche Stakeholder haben Anforderungen. Faszinierend ist doch, das Architekten tatsächlich damit umgehen können. Ich fände es spannend mal Architekten wie Zaha Hadid http://de.wikipedia.org/wiki/Zaha_Hadid zu fragen, wie sie das eigentlich machen.
Hallo Boris,
Entwickeln einer Software und Bauen eines Bauwerks sind zwei
völlig verschiedene Sachen. Ich behaupte sogar, dass es deutlich mehr Unterschiede
als Gemeinsamkeiten gibt (von den Banalitäten, dass es Projekte sind, dass
Menschen daran arbeiten, etc. abgesehen).Werden die Sachen doch verglichen,
läuft man immer der Gefahren Parallelen finden zu wollen, wo es keine gibt.
Diese Falle hat auch hier zugeschlagen. Denn nach meiner Einschätzung gehört Rohrverlegung
nicht zu den architektonischen Bestandteilen des Hauses. Und wenn beim Testen
des Privathäuschen – und mit Testen ist hier Probewohnen angesagt – Wände rausgerissen
werden sollen, dann ist im bisherigen Projektverlauf einiges schief gelaufen.
Bei dem Beispiel mit dem Flughafen sind für mich ebenfalls
keine architektonischen Änderungen aufgrund des Feedbacks erkennbar. Oder wurde
die äußere Fassade, die tragenden Wände / Säulen, die Deckenkonstruktion, die
Anzahl der Stockwerke, die Grundfläche, die Größe der Fluchttüren, etc.
verändert? Was am Flughafen passiert, ist zweifelsohne ein hervorragendes Stresstest-,
Einführungs- und Stakeholdermanagement. Daraus kann jedes Projekt (egal welche
Vorgehensweise) lernen. Nur die Behauptung, dass dadurch architektonische
Änderungen am physikalischen Bauobjekt „Flughafen“ auch in spätem
Projektverlauf möglich sind, steht einfach auf einem sehr dünnen Eis.
VG
Hi ihr drei,
sicherlich, der Hausbau ist ein sehr strapaziertes Beispiel und ist – was Änderung und Komplexität angeht – nicht mit einer Produktentwicklung in der Software-Entwicklung zu vergleichen. Gerade deswegen bin ich froh es einmal aus einer anderen, für mich bereichernden Perspektive, gezeigt zu bekommen:
Was mir gefällt ist der Blick in die andere Branche; von der immer ein Bild entsteht, dass man hier aufgrund der großen Erfahrung und Muster, auf die man zurückblicken kann, man zumeist ohne Änderungen auskommt.
Ein weiterer Aspekt, auf den die Fertighäuser sehr stark zurückgreifen, ist die Inspektion und die Anpassung der Häuser aufgrund der Inspektion. Auch das finden wir in agilen Projekten sehr stark. Leider schaffen wir leider erst zur Laufzeit eines Projektes die notwendigen Fakten, um eine Inspektion, ein Feedback zu ermöglichen.
Klar schaffen wir es nicht den Dachboden unter dem Keller anzuordnen, so wie wir es in der Software-Entwicklung gerne mal machen, und trotzdem gibt es in beiden Bereichen sicherlich mehr Überschneidungen, von denen man nur profitieren kann.
Viele Grüße,
Sven
PS: auch ein Rohr verlegen mag eine Auswirkung auf das Design des Hauses haben, zumindest wenn der Ort meiner Badewanne davon betroffen ist 😉