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