Читать книгу Roadmap durch die VUCA-Welt - Dennis Willkomm - Страница 30

In vielen großen Unternehmen gibt es Fachabteilungen für bestimmte Aufgaben. Dies ergibt Sinn, weil es Fachleuten erlaubt, sich auf ihre Spezialgebiete zu konzentrieren. Ab einer bestimmten Größe braucht es noch Zwischenpositionen, also Manager, die darauf achten, dass die Zusammenarbeit zwischen den Abteilungen reibungslos funktioniert. Wie Sie eingangs schon gesehen haben, gibt es eine Reihe von Abteilungen, die Schnittstellen haben, an denen sie die Arbeit an die nächste Abteilung übergeben.

So geht zum Beispiel ein Vertreter der Verkaufsabteilung zum Kunden und fragt ihn, was er benötigt. Der Kunde erklärt ihm jetzt eine fixe Idee und der Verkäufer kehrt zurück mit einem Katalog von Anforderungen. Diesen übergibt er nun einem Kollegen aus der Analyseabteilung und er selbst geht wieder nach draußen und besucht einen anderen Kunden. Sein Job ist an dieser Stelle für dieses Projekt erledigt. Der Analyst aus der Analyseabteilung setzt sich nun mit seinen Kollegen zusammen und diskutiert die Anforderungen. Sie schauen, was alles in das vorherrschende Konzept passt und ob und wann es umgesetzt werden kann. Wenn die Pläne konkreter werden, schreiben sie ihre Anmerkungen in ein Dokument und lassen es per Hauspost den Kollegen aus der Spezifikationsabteilung zukommen. Dann setzen sie sich zusammen und schauen sich den Anforderungskatalog eines anderen Kunden an. Die Mitarbeiter aus der Spezifikationsabteilung sehen sich das übergebene Dokument an und fangen an, sich Gedanken über die konkrete Umsetzung zu machen. Am Ende haben sie eine sehr schöne Funktionsbeschreibung, die Antworten auf die meisten Fragen zu bieten hat. Dieses umfangreiche Dokument wird dann der Entwicklungsabteilung zukommen lassen. Hier sitzen die Experten für die Umsetzung zusammen. Sie lesen sich die Funktionsbeschreibung durch und schreiten zur Tat. Schnell entsteht ein richtig schönes Produkt, welches sie jetzt, zusammen mit ein paar Kommentaren, welche Besonderheiten beachtet werden müssen, an die Qualitätssicherung übergeben. Hier wird das neue Produkt auf Herz und Nieren getestet. Wenn alle Tests erfolgreich durchlaufen sind, dann erfolgt eine Übergabe an eine Verkaufsabteilung, die das Produkt zum Kunden transportiert.

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 Wasserfallmodell bekommen.

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 Schnittstellen zwischen 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 Durchlaufen der 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 Teamaufstellung war 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?