vor allem auf die schnelle Entwicklung und Lieferung auf Produktkomponenten. „Schnell“ bedeutet hierbei frühestens alle 14 Tage.
Welchen Vorteil bietet es aber, eine neue Produkt-Komponente alle 14 Tage fertigzustellen oder gar auf den Markt zu bringen? Ganz einfach: Feedback von den Kunden. Hierdurch ermöglicht man eine Entwicklung, bei der der Kunde im Entwicklungsprozess sehr stark eingebunden ist. Der Kunde kann Feedback geben und man kann weiter an seinem Produkt arbeiten – und zwar so, wie es dem Kundenbedürfnis am ehesten entspricht. Der KundeKunde muss dann nicht wieder ein ganzes Jahr, sondern lediglich 14 Tage auf die Berücksichtigung oder Einarbeitungen des Feedbacks warten. Das bedeutet einerseits, dass man sehr schnell erkennt, ob die kundenseitige Anforderung in die Realität umgesetzt, wirklich das bringt, was man sich erhofft hat. Andererseits wird das Risiko reduziert etwas zu entwickeln, was vollkommen am Kundenbedarf vorbeigeht. In diesem Fall wäre eine Zeitverschwendung von 14 Tagen im Vergleich zu einem Jahr sehr viel kostengünstiger.
Wer ist der Kunde und was ist das Produkt?
Wer der Kunde ist, ist völlig frei zu definieren. Hierbei kann es sich um den klassischen Endkunden handeln, es kann aber auch ein unternehmensinterner Kunde sein – also beispielsweise eine Unternehmensabteilung.
Auch das Produkt, das hier generisch beschrieben wird, ist frei wählbar. Jedoch fällt schnell auf, dass diese Produkte, die im besten Fall 14 Tage bis zur Auflieferung brauchen, eher Software basiert sind.
Hierbei ist TeslaTesla wieder einmal ein sehr gutes Beispiel. Ein Tesla Model 3 ist in seiner Hardware nach Auslieferung nur noch schwer, nämlich über Werkstattbesuche oder Rückrufaktionen, zu ändern oder gar weiterzuentwickeln. Darüber hinaus kann ein bestehendes analoges Produkt eher schwer umgebaut werden – im Vergleich zu einer Software. Es kann am Auto nicht mühelos ein Teil weggesägt werden und ein neues hinzugefügt werden. Dies würde jegliches Kosten-Nutzen-Verhältnis zerstören.
Anders sieht es bei der Software des Fahrzeugs aus: Ob der Software-Entwickler einen Button oder gar eine ganze Funktion ändert, ist im Verhältnis kein großer Aufwand. Hinzu kommt, dass diese Änderung nur ein einziges Mal durchgeführt werden muss und dann „per Knopfdruck“ über das Internet in jedes Tesla-Fahrzeug weltweit eingebunden werden kann. Und wenn es am Ende nicht den erhofften Mehrwert für den Kunden bringt, dann kann es auch wieder relativ einfach entfernt werden.
Das beschreibt einfach und gleichzeitig eindrucksvoll, wo Scrum wirklich seinen vollen Mehrwert im Produktbereich entfalten kann. Weitere Mehrwerte sind neben der schnelleren und bedarfsgerechten Produktentwicklung, vor allem im Team-Softskill-Bereich einzuordnen.
Um dieser Frage gerecht zu werden, lohnt es sich etwas mehr im Bereich des Projektmanagements auszuholen. Grundsätzlich werden drei Projektmanagementansätze unterschieden:
klassisch
agil
hybrid
Klassisch:
Klassisches ProjektmanagementProjektmanagement beschreibt demnach einen Ansatz, ein Projekt von Anfang bis Ende grob durchzuplanen und dabei lange, über mehrere Monate andauernde Phasen zu durchlaufen und am Ende mit einem „Big Bang“ das Produkt auf den Markt zu bringen. Wer sich jetzt an das Beispiel aus den vorherigen Kapiteln erinnert, dem wird auffallen, dass wir dort nie ein Produkt in einem „Big Bang“ auf den Markt gebracht haben, sondern dieses Produkt immer inkrementell, also Stück für Stück, mit dem Markt entwickelt haben.
Was ist klassisches Projektmanagement; ► https://www.youtube.com/watch?v=FKCom8wziEk
Abb. 7
Agil:
Wirft man nun einen Blick auf das agile Vorgehen, so fällt auf, dass die Phasen aus dem klassischen Projektmanagement auch hier Anwendung finden, diese aber nicht einmalig über einen langen Zeitraum funktionieren, sondern innerhalb unserer beispielhaften 14 Tage. Also viel schneller. Das Produkt ist dann ebenfalls zur selben Zeit wie im klassischen Beriech im „finalen“ Zustand angekommen, jedoch in einer ganz anderen Ausprägung. Und: Teile des jetzt finalen Produkts waren bereits viel früher für den Kunden verfügbar. Dadurch ergeben sich schnelles Feedback vom Kunden und auch ein bereits generierter Umsatz.
Hybrid:
Hierbei wird über ein agiles Vorgehen auf Team-Ebene, ein klassisches Projektmanagement gestülpt. Hintergrund ist, dass Unternehmen, die aus dem Bereich des klassischen Projektmanagements ein Zwischenmodell fahren wollen, um keine erheblichen Veränderungen beispielsweise in der Unternehmensorganisation durchzuführen. Weitere Vorteile der hybriden Vorgehensweise sind, dass man Teams in den Genuss von agiler, selbstorganisierter Arbeit kommen lassen will, aber dennoch ein Projekt mit einem „Big Bang“ auf den Markt bringen will. Ein hybrides Vorgehen birgt neben der großen Chance, Vorteile aus beiden Welten zu vereinen, das große Risiko am Ende mit den Nachteilen aus beiden Welten zu arbeiten.
Nach Differenzierungsdarstellung wird klar, dass ein agiles Vorgehen – auch im Projektmanagement – mit Sicherheit grenzender Wahrscheinlichkeit nie ein klassisches Vorgehen komplett verdrängen wird. Vielmehr gilt es für jedes Vorhaben die Frage zu beantworten, wann wird welches Modell eingesetzt?
Diese Frage ist gewiss nicht das erste Mal gestellt worden. Hier hilft das Cynefin-Framework weiter.
Ein Lehr- und Fachbuchklassiker: ist das ebenfalls bei utb erschienene Werk Projektmanagement von Franz Xaver Bea, Steffen Scheurer und Sabine Hesselmann:
https://www.utb.de/doi/book/10.36198/9783838587066
Was versteht man unter dem Cynefin-Framework?
Um dieser sich immer wieder wiederholenden Frage, wann geht man agil und wann klassisch an ein Projekt heran, mit einer soliden Antwort zu entgegnen, kommt man an dem CynefinCynefin-Framework nicht vorbei. Auch große und bekannte Projektmanagementmethoden wie PRINCE2PRINCE2 erwähnen es, um diese zentrale Frage zu beantworten.
Hintergrund dieses Frameworks ist es, durch verschiedene Sachverhaltsbeispiele herauszufinden, welches Vorgehen zu welcher Herausforderung möglicherweise am besten passt. Wichtig dabei ist das Wort „möglicherweise“. Denn auch ein Cynefin-Framework oder eine Voreinschätzung der Ausgangssituation kann sich irren. Es gibt damit keine Garantie die richtige Wahl zu treffen. Es hilft allerdings dabei, das Risiko der falschen Vorgehensweise zu reduzieren.
Im Folgenden wird das Cynefin-Framework in der vollen Breite, jedoch nicht in der vollen Tiefe durchleuchtet.
Abb. 8
Schaut man sich nun das verbildlichte Cynefin-Framework an, so fällt auf, dass es hierbei 5 Bereiche gibt, welche als unterschiedliche Herausforderungslagen beschrieben werden:
Obvious,
Complicated,
Complex,
Disorder (mittleres, unbeschriftetes Feld) und
Chaotic.