Scrum baut keine Fertighäuser

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

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

4 Antworten zu “Scrum baut keine Fertighäuser”

  1. Gast sagt:

    “…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.

    • bgloger sagt:

      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.  

      • Gast sagt:

        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

        • Sven Winkler sagt:

          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 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.