Nachdem Thomas Michl auf Google+ so nett darauf hingewiesen hat, dass ich ein Impulsegeber zum Thema Hausbau mit Software: Scrum und-oder klassisch? sein könnte, möchte ich die Gelegenheit nutzen mal einige Thesen in den Raum zu stellen, die auch gut zu der seit längerem laufenden Diskussion auf openPM bzw. PM-Blog passen.
In den bisherigen Diskussionen wurde vielfach darauf hingewiesen, dass agil zu arbeiten in Kontexten wie Haus- oder Anlagenbau nicht möglich sei. Wenn man nur auf die konkrete Umsetzungstätigkeit schaut, kann man sich das kaum vorstellen. Da die agilen Ideen alle vom Toyota Produktionssystem abgeleitet sind, das sich zur Aufgabe gemacht hat qualitativ hochwertige Autos mit möglichst geringer Verschwendung zu bauen, kann eigentlich kein Unterschied zwischen physischer und virtueller Produktion (Software) gemacht werden. Die Erfahrung zeigt, dass in beiden Kontexten hochwertige Produkte entstehen können.
Die agilen Werte, wie ich sie etwa im Blue Scrum Prozessmodell beschrieben habe, können damit wohl als allgemeingültig einsetzbar und effektiv betrachtet werden. Mal die ganzen Probleme und fehlgeleiteten Versuche, diese in der Praxis umzusetzen, beiseite lassend, stellt sich die Frage, warum kommt man letztendlich zu dem Schluss, dass etwa ein Haus zu bauen nach agilem Vorgehen als nicht machbar einzuschätzen ist?
In allen Bereichen, in denen die Produktion nicht nur von unternehmensinternen und kundenspezifischen Vorgaben abhängt, sondern auch gesellschaftliche Rahmenbedingungen, etwa mit gesetzlichem Charakter, zu erfüllen sind, tritt ein Phänomen auf, dass erst bei einem Blick über den Tellerrand der Umsetzungstätigkeit hinaus offensichtlich wird: die Annahmen darüber wie Produktion zu funktionieren hat.
Wann ist es mir erlaubt ein Haus tatsächlich zu bauen? Nachdem ich alles durchgeplant habe. Erst dann bekomme ich die Genehmigung, die Finanzierung, etc. Die Gesellschaft geht davon aus, dass sie Entscheidungen des Für und Wider für bestimmte Kontexte erst treffen kann, wenn das Produkt komplett geplant ist. Die Denke ist Wasserfall, nicht iterativ. Der gute alte Taylor eben.
Es ist nicht verwunderlich, dass sich etwa das Handwerk dementsprechend aufstellt beim Hausbau. Niemand würde auf die Idee kommen, noch großartig Abstimmungen zwischen den Handwerkern zu erwarten, nachdem der Architekt doch die Vorgehensweise festgelegt und durchgeplant hat. Wenn er etwas übersehen hat, ist das halt Pech (mal vorausgesetzt, dass die Handwerker in ihrem Teil der Umsetzung wissen, was sie tun).
Somit ergeben sich gar keine Rahmenbedingungen, die ein agiles Arbeiten sinnvoll machen. Der Bedarf wäre ohne Frage vorhanden. Der Bauherr will und kann nicht am Anfang jede Entscheidung für das Endprodukt richtig treffen. Es wäre viel einfacher am vorhandenen Teilergebnis seiner Träume während der Umsetzung noch die Ausrichtung zu präzisieren. Agiles Vorgehen würde vieles also einfacher machen ;-).
Man kann natürlich jetzt einwerfen, dass gewisse bauliche Standards etabliert sind, die damit zwangsläufig unterlaufen werden müssten. Ich würde aber mal zur Diskussion stellen, ob sich diese nicht gerade deshalb so herausgebildet haben, weil man bisher immer wasserfall-artig geplant hat. Was wäre, wenn ich die Standards darauf hin auslegen würde, dass sich Möglichkeiten des Umentscheidens grundsätzlich ergeben sollen. Die Grenzen dieser Möglichkeiten würden sich natürlich an den finanziellen Aufwänden orientieren, die der Bauherr bereit wäre zu zahlen. Aber wenn ich die Change Requests, die zwangsläufig eintreten, dagegen stelle, wird es dann wirklich teurer? Ich könnte ja durch diese neue Art von Flexibilität viel einfacher auf die Wünsche des Bauherrn eingehen.
Dieser Ansatz würde einige Verwerfungen nach sich ziehen: andere Arten von Baumaterial, andere Arbeitsweisen und ganz besonders die enge Zusammenarbeit zwischen Handwerkern müsste her, um dahin zu kommen. Wir würden einen disruptiven Ansatz durchsetzen müssen. Und genau hier sind wir bei dem Hauptproblem, das wir ebenfalls in den Unternehmen mit ihren klassischen, tayloristischen Organisationen beobachten: der dafür notwendige Change und die damit verbundenen Probleme. Die Gesellschaft müsste sich einem Mindset-Wechsel unterziehen, der das neue Vorgehen erlauben würde.
Was in Unternehmen schon eine halbe Ewigkeit dauert, mindestens ein bis zwei Jahre, kann für die Gesellschaft nur in Generationen gerechnet werden. Alleine die Anpassung der Rechtsprechung für eine Art iterativer Genehmigung von Hausabschnittstätigkeiten oder eine dazu passende iterative Finanzierung würden zentrale gesellschaftliche Gruppen heute für völlig indiskutabel halten.
Damit ist agiles Vorgehen für den Hausbau in hunderten von Jahren wohl nicht agil zu betreiben. q.e.d. ;-)
Comments:
Interessant in diesem Zusammenhang ist folgendes Zitat von Ken Schwaber aus seinem Buch “Agile Project Management with Scrum”, 2004: „Another change that Scrum engenders can be best described by thinking of how a house is built. The buyer of the house cannot move into the house until the entire house is completed. Suppose that there were an incremental, iterative approach for home construction. Suppose that using this approach, houses were built room by room. The plumbing, electrical and infrastructure would be built in the first room and then extended to each room as it was constructed. Buyers could move in as soon as they had decided that enough rooms had been completed. Then additional rooms could be constructed depending on the needs of the buyer.”
Posted by rainwebs at 18. Mär 2014 15:56
|