Hausbau mit Software: Scrum und-oder klassisch?

"Jedem Anfang wohnt ein Zauber inne." Aber wie organisiert man einen Hausbau mit Software-Entwicklung? Mit Scrum? Klassisch? In Kombination? Eine spannende Frage, wie ich finde.

„Jedem Anfang wohnt ein Zauber inne.“ Aber wie organisiert man einen Hausbau mit Software-Entwicklung? Mit Scrum? Klassisch? In Kombination? Eine spannende Frage, wie ich finde. Und eine Einladung an Experten mitzumischen.

Mal angenommen, ich will ein Haus bauen mit einer ganz speziellen, individuellen Software-Steuerung, die es so heute noch nicht am Markt zu kaufen gibt. Wie würde ich „das Projektmanagement“ aufbauen? Agiles Projektmanagement, Scrum, oder doch lieber klassisch? Oder beides in Kombination? Was sagen verschiedene Experten dazu? Das interessiert mich. Eine Einladung zum Mitmachen, zu der mich der Beitrag „Agiles Projektmanagement für physische Produkte“ im PM-Blog von Stefan Hagen inspiriert hat.

Die Aufgabenstellung

Ich will ein Haus bauen*, das einen großen Bereich für die private Wohnung enthält und ein Büro direkt anschließt. Das Haus soll massiv gebaut werden. Da es ein passendes Fertighauskonzept nicht gibt, so die Annahme, muss das Haus individuell in Zusammenarbeit mit dem Architekten entworfen werden. Dieser Architekt, so die Idee, soll auch die einzelnen Gewerke beauftragen, wobei nicht zwingend das in der Baubranche übliche Ausschreibungsverfahren zum Zuge kommen muss. Andere Organisationsformen sind denkbar. Vor allem kleinere, lokale Handwerker sollen zum Zug kommen und nach Qualität ausgewählt werden.

Außerdem habe ich die Idee, sämtliche Geräte, Jalousien, Türen, Lichter, Steckdosen etc. über eine zentrale Software-Steuerung bedienen zu können, so dass ich im Büro sitzen und beispielsweise den Fernseher ein- und ausschalten kann. Eine Marktrecherche hat ergeben, dass es ein solches System noch nicht in vollem Umfang gibt. Allerdings kann sowohl Hardware wie auch Software gekauft werden, die Teile einer solchen Steuerung abdeckt. Trotzdem scheint aus heutiger Sicht mindestens ein Teil individuelle Programmierung notwendig. Die Anforderungen dafür sind noch nicht erfasst, es handelt sich bisher lediglich um eine Idee.

Die Finanzierung des Vorhabens ist vorab mit Geldgebern besprochen, muss allerdings noch im Details abgewickelt werden. Hierzu verlangen die Geldgeber eine detaillierte Finanzübersicht. Dasselbe gilt für Genehmigungen, die ebenfalls vorab diskutiert wurden, jedoch erst nach Einreichung der Planunterlagen bearbeitet werden können. Bisher existieren nur erste Handskizzen, die verschiedene Überlegungen abbilden.

Da ich selbst viel Langeweile habe – auch das ist eine fiktive Annahme – will ich die Projektleitung für dieses Vorhaben selbst übernehmen. Ich überlege, inwieweit mir Projektmanagement mit Scrum hierbei nutzen kann. In reinen Software- sowie in Entwicklungsprojekten habe ich damit sehr gute Erfahrungen gemacht. Allerdings stellt sich mir die Frage, ob sich diese Methode auch bei diesem Kombinationsprojekt aus physischem Hausbau und Software einsetzen lässt. Dabei ist auch interessant, wie sich gegebenenfalls klassisches Projektmanagement mit Scrum kombinieren lässt.

Was sagen Sie, als Experte dazu? Wie sollte „das Projektmanagement“ aus Ihrer Sicht hier aufgebaut werden? Ausschließlich Scrum? Ausschließlich klassisch? Eine Kombination und wie sieht die aus? Etwas ganz anderes? Alle Ideen und Ansätze sind erwünscht.

Eine Einladung

Ich möchte alle Experten und Profis einladen, die eigene Lösung für diese Aufgabenstellung im eigenen Blog zu veröffentlichen und hier in den Kommentaren einen Link dorthin zu schalten. Oder mir den Artikel zu schicken (dialog@projektmensch.com), so dass ich ihn hier im Projektmensch-Blog als Gastbeitrag veröffentlichen kann (gerne mit Link zu Ihrer Website).

Die Idee ist, möglichst viele verschiedene Lösungsansätze darzustellen, da es aus meiner Erfahrung DIE eine Lösung dafür nicht gibt. Immer häufiger taucht bei uns die Frage auf, wie mit der Kombination aus klassischem Projektmanagement und Scrum umgegangen werden kann. Weshalb ich davon ausgehe, dass es sich für alle lohnt, die verschiedenen Ansätze zusammenzutragen und so voneinander zu lernen. Unseren eigenen Lösungsentwurf werde ich sicherlich ebenfalls zusammenfassen und hier veröffentlichen.

Sofern genug spannende Lösungen zusammenkommen, werde ich diese mit Sicherheit auf openPM zusammenfassen und – sofern gewünscht – in unserem Projektbrief darauf verlinken. Ich bin gespannt. Bitte weitersagen!

Ihr
Holger Zimmermann
Projektmensch


*Es handelt sich um ein fiktives Projekt. Wir haben bereits gebaut. Ohne die Software und mit klassischem Projektmanagement, was in diesem Fall wunderbar funktioniert hat. Lediglich unser Bauleiter hat vermutlich mit uns einige leidvolle Stunden gehabt. 🙂

13 Gedanken zu “Hausbau mit Software: Scrum und-oder klassisch?

  1. Hier ist ein bisschen viel fiktiv. In Fortsetzung dessen könnte man sagen: „Ja, man wendet mit Vorteil fiktiv SCRUM an und wird fiktiven Erfolg haben“. In der Praxis wirst Du ein knappes Budget haben und bald einmal auf Extravaganzen verzichten.

    Wenn Du ein beinahe unendliches Budget zur Verfügung hast – mal fiktiv – dann wirst Du stolz sein, das beste standard Haussteuerungssystem zu verbauen, das es auf dem Markt gibt. Eine Spezialentwicklung wirst Du kaum durchführen, auch wenn Du über unendliches Budget verfügst, weil es andere, wichtigere Facility Management Systeme gibt, die Deine Aufmerksam benötigt, wie z.B. das Heizungssystem: konventionell? Sonnenenergie? Geothermie? Oder doch Hybrid? Das hat Dimensionen, die eine doch eher nebensächliche Haussteuerung übertrifft.

    Wie gesagt, wirst Du aber ein sehr beschränktes Budget zur Verfügung haben. Das können – fiktiv – auch zwei bis drei Millionen sein. Auch das ist beschränkt. Jedes Budget stösst während des Projekts an seine Grenzen, an denen Du sagen wirst, dass Du – wie heisst das so passend? – lieber den Spatz in der Hand hast als die Taube auf dem Dach.

    Auf der anderen Seite ist da der Bauunternehmer. Ich war oft auf dieser Seite. Übernimmt er ein Projekt, dann rechnet er sich eine Marge aus, z.B. 25%. Jeder Furz des Auftraggebers (hier „Kunde“ genannt) schmälert seine Marge. Er wird daher versuchen, den Kunden auf Distanz und ruhig zu halten und das Projekt klassisch mit möglichst wenig Nebengeräuschen durchzuziehen.

    Ich verstehe wohl, dass es Dir in erster Linie um Softwareentwicklung geht, und Du in ein fiktives Bauprojekt einbettest. Aber wie ich immer wieder betone, sind Bauprojekte und IT Migrations- und Integrationsprojekte für SCRUM nicht geeignet. Und wenn man SCRUM gaaanz weit fasst, so weit, dass man es zur Not auch in Bauprojekten anwenden könnte, dann ist’s nicht mehr SCRUM, sondern eine sehr flexible Projektführung. Da sind wir dann wieder beisammen, denn ich bevorzuge auch mehr Flexibilität als Festhalten am Buchstaben des klassischen PM.

    Die Idee des nach Nützlichkeit priorisierten Backlogs ist nicht hilfreich. Ein Hausbau beginnt notwendigerweise beim Fundament. Hierzulande besteht dieses aus einem Sockel in zwei bis drei Metern Tiefe, auf dem dann das Kellergeschoss aufbaut. Mit dem Keller kann der Kunde (Bauherr) aber relativ wenig anfangen. Nach SCRUM würden möglichst schnell die Teile geliefert, mit denen der Kunde schon mal arbeiten kann, hier z.B. Küche und Schlafzimmer, danach das Wohnzimmer.

    Auch die Idee von Sprints ist im Hausbau wenig nützlich. Wozu sollte man für den Aushub einen Sprint definieren? Der Aushub muss sein, er beginnt an einem schönen geplanten Morgen und dauert voraussichtlich so und solange. Es macht keinen Sinn, den Aushub in Sprints aufzuteilen.

    Ich habe viele Migrationsprojekte gemacht. Die SCRUM-Prinzipien halfen mir wenig, weil der Projektweg relativ starr vorgegeben ist (beim Hausbau eben zuerst der Aushub, dann das Fundament, dann der Keller, etc.). Wenn es im Projekt etwas zu entwickeln gab, war das eher ein Nebenkriegsschauplatz. Ich überliess ihn einem Entwicklungsfachman, der sein Teilprojekt selbstverständlich gerne nach SCRUM organisieren konnte, wenn er nur in der Zeit blieb.

    Dein fiktives Haus würde ich als Bauunternehmer also klassisch bauen und Dir empfehlen, Deine Spezialwünsche so gekapselt wie möglich durchzuführen. Selbstverständlich gibt es Schnittstellen. Aber wenn ich z.B. breit verzweigte, gut zugängliche Kabelkanäle vorsehe (warum das in Häusern nicht längst Standard ist, verstehe ich nicht) und dort, wo voraussichtlich zu steuernde Elemente reinkommen (z.B. Fensteröffnungen), grosszügige Freiheiten offen lasse, sollten die beiden Projekte relativ gut aneinander vorbei kommen. Gegen Aufpreis wäre ich als Bauunternehmer auch bereit, mich regelmässig mit den anderen Zulieferern auszutauschen. Nicht bereit wäre ich, in einem solchen Projekt eine GU zu übernehmen. Aber wenn der Bauherr mich als Subakkordant in ein Konsortium einzubinden versucht, müsste ich auf meine Offerte einen Aufschlag machen.

    In einer Studiengruppe, die ich über Ungewissheiten in Projekten führe, nimmt auch eine praktizierende Bauingenieurin teil. Sie betätigt gewissermassen, dass SCRUM die typischen Probleme von Bauprojekten nicht lösen hilft. Es sind vor allem Probleme, die mit Menschen zu tun haben. Wie schrieb Edouard Yourdon in „Himmelfahrtskommande – Aussichtslose IT-Projekte überleben“?

    „Ihre zwei besten Programmierer sind gerade in Ihr Büro marschiert, um Sie darüber zu informieren, dass sie a) heiraten werden, b) den Zeugen Jehovas beitreten und c) heute ihr letzter Tag in ihrem alten Job ist“

    Das lässt sich auch durch einen Srum Master mit Daily Scrum, Backlogs und Sprint Reviews nicht verhindern.

    SCRUM ist nützlich in Projekten, die stark verzweigte mögliche Projektwege hat oder gehen kann, viele Arbeiten unabhängig und parallel sind, der Outcome ungewiss ist und jeder Task jeden anderen beeinflussen kann. In Migrations- und Bauprojekten ist das nicht gegeben.

  2. Peter’s Ausführungen sind sehr interessant. Auf wenn ich kein Experte im Hausbau bin, fällt mir zumindest bei den Annahmen über Scrum auf, daß hier das agile Mindset fehlt. Vielleicht sind die derzeitigen Rahmenbedingungen im Hausbau auch tatsächlich so, daß agiles Vorgehen nicht geht. Da sich z.b. rechtliche Bedingungen meistens an sequentiellen Abfolgen orientieren.

    Zumindest würde ein Product Owner es nicht zulassen, daß man sich zuerst mit dem Schlafzimmer beschäftigt, wenn noch eine Abhängigkeit besteht (Keller, Aushub, etc.).

  3. Pingback: Ein agiler Change für die Gesellschaft muss her « rainwebs.net

  4. Hallo Holger Häuslebauer,

    grundsätzlich schließe ich mich Peter an [wen wundert’s 🙂 ]:
    „Dein fiktives Haus würde ich als Bauunternehmer also klassisch bauen und Dir empfehlen, Deine Spezialwünsche so gekapselt wie möglich durchzuführen.“

    Ich empfehle das deswegen auch, weil Du die Frage, ob ein Hausbau auch mit agilen Methoden machbar wäre aus der Sicht des Projektleiters und Auftraggeber stellst. Wie das Projekt gemanagt werden soll, hängt aber hier v.a. vom Umfeld ab.

    Im Text gehst Du auf einige stakeholder ein, deren Prozesslandschaft nach meiner Kenntnis nicht so definiert ist, dass Scrum/ Agilität dort wirksam werden kann. Sowohl Genehmigungsbehörden (Bauanzeige), Banken (Auszahlung nach Baufortschritt) und erstellende Firmen (Peters Hinweise sind da ja gut nachvollziehbar) arbeiten nach dem klaren Wasserfall -Modell. Da kann der Projektleiter ein noch so großes Methodenfeuerwerk abbrennen, er hat nicht die Verhandlungsmacht, dass das Umfeld sein PM Vorgehensmodell verändert.

    Was ich von der Idee halte, dass Du Auftraggeber und Projektleiter gleichzeitig sein willst, kannst Du Dir ja denken.( http://de.slideshare.net/olafhinz/bervterunentscheidbare-entscheidungen-und-helden-wirksame-projektleitung )
    Da droht die Rollenüberdehnung und der grandiose Alleskönner, der gleichzeitig mit Banken verhandelt, Baubesprechungen führt und sich eine smart Home Software programmiert.

    …und dann kann ich mir es nicht verkneifen: Der Hausbau mag für Dich zwar ein Projekt sein, für das o.g. Umfeld ist das eine Standard – Aufgabe. Deshalb stellt sich Deine Frage auch nicht!

    Immer eine Handbreit Wasser unter dem Kiel wünscht
    Olaf Hinz

  5. Hallo Holger,

    ich würde Versuchen, die zugrundeliegende Motivation zu ergründen und von dort aus eine Selektion von Methoden durchzuführen:

    1. Da sich die Anzahl & Art der Gebäude sich nicht plötzlich ändern wird, lassen sich diese wunderbar klassisch-Wasserfall-artig umsetzen

    2. Detail-Entscheidungen zum Thema Ausstattung (z.B. Bodenbelag) können sich dabei zeitlich so einordnen, dass diese so spät wie möglich zu treffen sind, um sich nicht unnötig festzulegen. Eine spätere Änderung hätte dann erhebliche finanzielle Auswirkungen, die sich zu dem jeweiligen Zeitpunkt gegenüber einer Verbesserung abwiegen lassen.

    3. für die Anlage zur Steuerung würde sich „Agil“ anbieten, hier würde ich in Form eines Prototypen vor Beginn der Rohbauarbeiten eine Hardware-Entscheidung treffen, und dann parallel zum Hausbau eine Ausprogrammierung von Details durchführen; mit regeln moderner Agiler Softwareentwicklung: Continous Delivery, #NoEstimates, Priorisierung gemäß Cost-Of-Delay…

    Innerhalb von 1 lassen sich durchaus aber Elemente aus Agilen Methoden verwenden. Mein eigener Bauträger nutzt z.B. Timeboxing zur Steuerung der einzelnen Gewerke, und verzichtet gegenüber Subunternehmern auf Fixe Termine zugunsten einer Inspect & Adapt Mentalität; mit entsprechend kleinen & kurzfristigen Vertragseinheiten, statt ausgiebigen Rahmenverträgen, die wenig Handlungsspielraum bieten.

    Grüße,
    Robert

  6. Hallo Olaf,

    besten Dank. In der Tat hätte ich erwähnen müssen, dass selbstverständlich meine Frau Auftraggeberin und spätere Häuslebesitzerin ist und ich der Projektleiter sein darf. 🙂

    Was den Projektcharakter der Aufgabenstellung betrifft, ist es für jemanden, der das erste Haus seines Lebens baut, in der Tat ein Projekt. Für den Architekten sollte es vermutlich ein zumindest in weiten Teilen standardisierter Prozess sein. Ebenso für die beteiligten Handwerker. Genau diesen Aspekt finde ich an der Aufgabenstellung „Hausbau“ spannend, da er aus meiner Sicht in solchen und ähnlichen Vorhaben immer wieder für Konflikte sorgt. Der eine will seine Vorgehensweise durchziehen und versteht gar nicht, dass der andere das nicht versteht.

    Da wesentliche Beteiligte (also Auftraggeberin und Projektleiter) in diesem Fall eine einmalige Aufgabe vor sich haben, komme ich zu dem Schluss, dass diese grundsätzlich Projektmanagement-Methodik anwenden sollten, da ein automatischer Prozess nicht funktionieren wird. Teile des Projekts, etwa die Finanzierung, sind beim Architektenhaus in einem potenziellen Standardprozess nur bedingt enthalten, gehören aber zum Gesamtlieferumfang des Vorhabens. Der Garten wird womöglich durch die Eigentümer selbst erstellt, die dafür (noch) keinen Standard haben. Für mich sind dies weitere Indizien, dass es sich um ein Projekt handelt und Projektmanagement nötig sein wird. Dieses sollte nun jedoch auf möglichst viele Standardprozesse der Beteiligten zugreifen, um effizient zu sein.

    Deckt sich das mit Deinem Verständnis oder hast Du eine andere Einschätzung dazu?

    Beste Grüße
    Holger

  7. Hallo Robert,

    zu einem sehr ähnlichen Schluss komme ich auch. Wobei ich mir in Sachen klassisches Projektmanagement immer wieder eine Frage stelle: im Zuge agiler Techniken wird immer wieder das starre Konstrukt klassischen Projektmanagements in Form von Terminplänen hervorgehoben. Egal von welcher Seite ich mich klassischem Projektmanagement nähere, kann ich nicht verstehen, wie es dazu kam, dass Pläne als etwas Feststehendes betrachtet werden. Pläne bilden für mich lediglich eine Annahme ab, die zeigt, wie es gelingen könnte die vereinbarten Ziele zu erreichen.

    Unter diesem Gesichtspunkt darf ich nicht davon ausgehen, dass die Realität sich an die Pläne halten wird. Vielmehr muss mein Projektmanagement-System so ausgelegt sein, dass es mit Fehlern, neuen Erkenntnissen und anderen Änderungen möglichst leicht umgehen kann. Diese möglichst leicht integrieren kann. Aus dem Unterschied zwischen Plan und Realität kann ich erkennen, wo Handlungsbedarf besteht – etwa Ressourcen anders eingeplant werden müssen – und wo ich nicht eingreifen muss. Agile Methoden speichern für mich diese Denkweise unter der Überschrift „inspect & adapt“.

    Weißt Du, woher diese Annahme kommt, dass Terminpläne starr gehalten werden müssen? Den Endtermin muss ich halten. O.k. Vielleicht noch wichtige Zwischentermine. Auch in Ordnung. Aber doch nicht jeden Abgabetermin jeder einzelnen Tätigkeit. Pläne sind schlicht Hilfsmittel, um Ziele zu erreichen. Kein Selbstzweck.

    Beste Grüße
    Holger

  8. Hallo Peter,

    die von Dir beschriebene Kapselung der Sonderwünsche, im gegebenen Beispielprojekt etwa mein Steuerung, halte ich ebenfalls für einen wichtigen Erfolgsfaktor, um unterschiedliche Methoden innerhalb eines Projekts einsetzen zu können. Bisher sieht mein Ansatz eine Integration von Scrum-Teilen in einem klassisch geführten Projekt so aus, dass sowohl als Eingangsvoraussetzung für den Scrum-Teil ein definiertes Ergebnis in Form eines Meilensteins vorliegen muss, wie auch das Ergebnis des agilen Teils via Meilenstein in die klassische Welt überführt wird. Die Strecke zwischen diesen Meilensteinen wird dann beispielsweise in einem Gantt-Diagramm als langer schwarzer Balken geführt, dessen Fortschritt über ein Burndown-Chart übergeben wird.

    In diese Richtung scheint das auch in der Praxis gut zu funktionieren. Noch keine mich zufriedenstellende, praktikable Lösung habe ich, wenn das Gesamtprojekt nach Scrum geführt wird und ein bestimmter Teil, warum auch immer, klassisch gelöst werden soll. Wobei ich ersteren Fall in der Praxis auch eher für sinnvoll halte, da er aus meiner Erfahrung öfter vorkommt. Etwa bei der Markteinführung eines Software-Produkts, bei dem die Vermarktungskampagne klassisch (und termingesteuert) sinnvoll organisiert werden kann, während das Software-Release als Teil des Gesamtpakets mittels beispielsweise Scrum geliefert wird.

    Danke für Deinen Beitrag!

    Beste Grüße
    Holger

  9. Hallo Holger,

    wenn ich mich richtig an meine klassische PM-Literatur erinnere, sind nur die (extra dafür eingeführten) Termine eines „Meilensteins“ fest – das ist ja das Alleinstellungsmerkmal.

    Die implizite (falsche) Verbindlichkeit der „übrige“ Termine (z.B. Ende eines Arbeitspakets) kommt IMHO aus der Situation, dass durch Matrix-Organisation, Projektportfolio-Management und Ressourcenplanungen ein extremes Micromanagement eingeführt wurde. Darüberhinaus bietet es sich außerdem an, „wenn man schon einen Vertrag hat (hier: mit externen/Subunternehmern), dann kann man auch gleich den Termin in den Vertrag schreiben.“

    Ich Verweise dazu gerne auf die #NoProjects Diskussion….

    Grüße,
    Robert

  10. Tut mit leid Holger, es kommt mir vor, als soll hier ein Gegenstand unbedingt in ein Projekt gepresst werden, der da nicht hineingehört!

    Du schreibst: „Der eine will seine Vorgehensweise durchziehen und versteht gar nicht, dass der andere das nicht versteht.“
    — Ja, das kommt oft vor, wenn der Gegenstand des Projektes für den Kunden einmalig ist, für den Lieferanten des Gegenstandes aber eine bekannte Aufgabe. Nur weil der Kunde ein coustomizing will, macht das doch nicht notwendig, dass sich der Lieferant (hier Architekten, Bauunternehmer, etc…) auf PM Methoden einlässt, weil der Kunde findet, PM sei hier notwendig.

    Mich erinnert das sehr an das Vorgehen von Premium-Herstellern in der Industrie, die Ihren Lieferanten Vorgaben für deren Prozesse machen und das auch noch zertifizieren. Ich kenne als Berater genügend Beispiele, wo das nur kurzfristig effektiv war…

    Es macht viel Sinn, dass ihr als Kunden das als Projekt seht und für Euch den Bau auch so begleitet. Da kann ich mir vorstellen, dass ihr Euren Einfluss als Kunde bei Abnahmen, Abschlagszahlungen, Qualitätskontrolle besser einbringt, als wenn ihr Euch von den Lieferanten durch den Bauprozess führen lasst.
    Aber ob ihr die Verhandlungsmacht habt, die Lieferanten auf PM zu verpflichten, bezweifle ich so lange, wie die Lieferanten PM für ihre Kernleistung als nicht sinnvoll/ wertschöpfend empfinden.

  11. Wenn ich noch was einwerfen darf, nach dem ich mir alles durchgelesen habe: Was passiert eigentlich bei so einem Projekt im Falle eines Changes? Nehmen wir an, das Büro soll kein Büro mehr werden, sondern auf der Fläche eine Einliegerwohnung… in welche Projektphase muss man zurückspringen? Was hängt da alles dran?

  12. Pingback: Zum Hausbau mit Software: Scrum und Klassik integriert | Projektmensch-Blog

Kommentar verfassen