Dennis Willkomm - Roadmap durch die VUCA-Welt

Diese Abfolge mit all ihren Übergaben wird gerne stufenförmig wie eine Treppe dargestellt, was dann an einen Wasserfall erinnert. Daher hat diese Vorgehensweise den Namen Wasserfallmodellbekommen.

Besonders stark diskutiert wird dieses Modell im Bereich der Softwareentwicklung, auch wenn es bei weitem nicht nur dort auftaucht. Aber im Bereich der Softwareentwicklung war man zeitlich schon sehr früh in einem recht komplexen Umfeld, was gewisse Erkenntnisse hier beschleunigt hat. Daher wurden einige Diskussionen, die auch in den meisten anderen Branchen von Relevanz sind, in dieser Domäne losgetreten und zuerst geführt. Denn so einfach, wie oben dargestellt, ist der Weg von einem Kundenwunsch zu einem fertigen Produkt, das diesen Wunsch erfüllt, bei Weitem nicht.

Es beginnt schon damit, dass die meisten Schnittstellenzwischen den Abteilungen so gestaltet sind, dass wenig direkte Kommunikation stattfindet. Die meisten Prozesse sehen vor, dass die Übergabe in Form standardisierter, schriftlicher Dokumente stattfindet. Dieses Dokument als Ergebnis der einen Abteilung stellt dann den Startpunkt für die Arbeit der nächsten Abteilung dar. Allerdings kommt es hier nicht selten zu Missverständnissen oder Fehlinterpretationen. Und so schleichen sich, nach dem Prinzip der stillen Post, zunehmend mehr Fehler ein. Wenn man Glück hat, dann fallen die Fehler während der Entwicklung bereits auf. Daher spielt hier die Qualitätssicherung eine wichtige Rolle.

Die bekannteste Beschreibung des Wasserfallmodells stammt von Winston W. RoyceRoyce, Winston W. aus dem Jahr 1970 (Royce 1970). Das Wasserfallmodell ist aber schon deutlich älter und Royce hat in seinem oft herangezogenen Paper eher auf ein paar Schwachstellen verwiesen und vorgeschlagen, wie man sie beheben könnte.

Abb. 10 :

Schematische Darstellung des Wasserfallmodells mit Rückkopplung

Dabei hatte Royce früh darauf hingewiesen, dass das Wasserfallmodell um ein paar Elemente erweitert werden müsse, die schon in eine recht agile Richtung deuteten. Das genutzte Wasserfallmodell stellte sich nämlich für ihn zunehmend als problematisch dar. Waren die ersten Programme noch vorhersehbar, so wurden die gewünschten Funktionalitäten zunehmend komplexer. Royce bemängelte vor allem, dass am Ende mitunter sogar unbrauchbare Ergebnisse herauskamen, auch wenn alle Abteilungen ihren Job hervorragend erledigt hatten. Er plädierte dafür, dass man Rückkopplungen berücksichtigen müsse. Dies würde zwar die Effizienz senken und Kosten verursachen, ihm war aber klar, dass dies notwendig war, um am Ende auch das zu liefern, was dem Kunden wirklich weiterhilft. So plädierte er für eine frühzeitige Beteiligung des Kunden in den Entwicklungsprozess, was, wie wir noch sehen werden, ein Grundbestandteil agilen Arbeitens darstellt.

Im Gegensatz zu diesem sequenziellen Durchlaufender verschiedenen Schritte und der Aufteilung der Arbeit unter mehreren Abteilungen, konnten Takeuchi und Nonaka bei ihrer Betrachtung im „New new product development game“ sehen, dass der Erfolg sich einstellte, wenn genau diese Abfolge aufgelöst wurde. Nicht nur Canon, sondern auch die anderen untersuchten Firmen hatten Teams gebildet, die interdisziplinär aufgestellt waren. Das heißt, aus allen Abteilungen, die an der Entstehung des Produktes beteiligt waren, war mindestens ein Vertreter in einem Projektteam zugegen. Dieses Projektteam konzentrierte sich auf nichts anderes, als das gewünschte Ergebnis zu erreichen. Vorher hatten die Mitarbeiter im Rahmen ihrer Abteilung nur die Verantwortung für einen bestimmten Arbeitsschritt getragen. Nun waren sie, zusammen mit den anderen Teammitgliedern, dafür verantwortlich, dass das Produkt insgesamt fertig wurde und erfolgreich war. Zwar konzentrierten sie sich immer noch auf ihre Spezialgebiete, aber sie waren in einem engen Austausch miteinander und unterstützten sich auch bei fachfremden Aufgaben so gut es ging.

Abb. 11:

Interdisziplinäre Teamsinterdisziplinäre Teams decken alle Fachrichtungen ab und arbeiten iterativ.

Durch die abteilungsübergreifende Teamaufstellungwar es nun möglich, kleine Zwischenstände der Arbeit schon nach relativen kurzen Zeiträumen zu präsentieren und mit den Kunden zu testen. Durch die frühe Einbeziehung des Kunden war es auch möglich, dass er die Rückmeldung gab, dass ihm das Produkt in einem gewissen Zustand schon vollkommen ausreiche. Dann konnte das Team überflüssige Anforderungen einfach von der Liste streichen. Im Wasserfall zuvor wurde einfach der komplette Anforderungskatalog abgearbeitet.

Lyssa AdkinsAdkins, Lyssa, die eine Verfechterin der agilen Vorgehensweisen ist, stellt in einem YouTube-Video sehr schön dar, welche Vorteile es mit sich bringt, statt auf Wasserfall auf interdisziplinäre Teams und kurze Zyklen zu setzen.3 Dabei vergleicht sie die Abarbeitung mit Schichten einer Hochzeitstorte. Beim Wasserfallmodell isst man sozusagen Schicht für Schicht der mehrlagigen Hochzeitstorte. Zuerst die Sahne (und zwar komplett), dann Biskuit (und zwar ebenfalls komplett) und so weiter, bis man schließlich am Boden angelangt ist. Kein besonders reizvoller Ansatz, um einen Kuchen zu essen. Will man eine Torte „agil essen“, schneidet man sich hingegen einfach ein Stück aus der Torte heraus und isst es auf. Dabei entfaltet sich dann der Geschmack, der sich aus den Kombinationen der unterschiedlichen Lagen ergibt. Und wenn man satt ist, dann hört man einfach auf. So lange schneidet man sich einfach Stück für Stück aus der Torte heraus. Auf welche Art und Weise würden Sie lieber eine Torte genießen?

Im Jahr 2001 fanden sich einige Vertreter aus dem Bereich der Softwareentwicklung zusammen und unterzeichneten gemeinsam das Agile Manifestagiles Manifest4. Auch wenn es im Bereich der Softwareentwicklung seine Wurzeln hat, so ist es so universell, dass sein Einfluss deutlich darüber hinausreicht. Heutzutage gibt es einige Initiativen, die sich dafür stark machen, das ursprüngliche Manifest zu überarbeiten und die Verweise auf die Software zu ersetzen oder das komplette Manifest noch einmal zu modernisieren. Aber auch in der momentanen Form bietet das Agile Manifest einen Kern von dem, was als Agilität in unterschiedlichsten Bereichen, Branchen und Domänen verstanden wird.

Das Agile Manifest formuliert vier Werteund zwölf Prinzipien. Den Originaltext finden Sie in der Box. Die vier Werte, die im Agilen Manifest propagiert werden, werden ins Verhältnis gesetzt zu anderen Werten, die sich zumeist auf die gängigen Praktiken in der Realität der Unterzeichner wiedergefunden haben. Dabei wird der kleine Nachsatz, unterhalb dieser Werte, gerne einmal übersehen. Dieser weist darauf hin, dass die Unterzeichner durchaus einen Nutzen in den Werten auf der rechten Seite sehen, aber den Nutzen auf der linken Seite deutlich höher werten. Dies führt häufiger auch zu Missverständnissen, wenn über Werte im agilen Umfeld diskutiert wird. So hält sich zum Beispiel hartnäckig der Mythos, bei agilen Vorgehensweisen brauche man keine Dokumentation oder müsse nicht in die Zukunft planen. Dies ist natürlich nicht so, was die Verfasser durch den erwähnten Zusatz noch einmal unterstreichen wollten.

An oberster Stelle steht im Agilen Manifest, dass Individuen und Interaktionenhöher zu gewichten sind als Prozesse und Werkzeuge. Man möchte nicht mehr schriftlich miteinander kommunizieren, sondern durch direkten Kontakt und Kollaboration. Dies zeigt sich auch in den agilen Prinzipien, zu denen wir später kommen.