Entwicklungsprojekten heutzutage zunehmend erschwert wird und klassische Herangehensweisen somit womöglich an Eignung verlieren. Nicht jedes Unternehmen schafft es, in dieser VUCA-Welt zu bestehen. Firmen verschwinden und die Lebenszeit von Organisationen verkürzt sich.
Nur 11 Prozent der Fortune 500 Unternehmen aus dem Jahr 1955 befinden sich auch heute noch auf dieser Liste. War die durchschnittliche Lebensdauer eines Fortune 500 Unternehmens im Jahr 1920 noch 67 Jahre, so beträgt diese heute (2016) gerade mal noch 15 Jahre. Aus diesem Grund wird immer mehr nach Möglichkeiten gesucht, das eigene Unternehmen agiler zu gestalten, um diesen Bedingungen besser gewachsen zu sein. Eine weitere Entwicklung scheint diesen Wandel zu befeuern: Nahezu branchenunabhängig steigt der Anteil an Softwareentwicklung in Projekten. Besonders in der Automobilbranche zeigt sich dieser Umstand deutlich.
Vuca Schaubild P3
Waren Autos früher lediglich das, was wir auch heute grundsätzlich unter dem Begriff verstehen, nämlich „Motorisierte Fahrzeuge“, die uns die Möglichkeit geben uns von A nach B zu bewegen, so sind heute Autos von Softwareanteilen nur so durchzogen: Wir nutzen Infotainment-Features, unser Auto interagiert über Schnittstellen wie Sprachsteuerungen und Displays mit uns, wir nutzen Fahrzeuge für Shared Mobility und das Auto übernimmt unter Umständen gar Fahrfunktionen für uns.
Vor der Hintergrund der Herkunft agiler Entwicklungsmethoden aus der Softwareentwicklung liegt also auch hier nahe, den steigenden Softwareanteil als Grund für die agile Transformation zu sehen. Dennoch, die Herausforderungen der VUCA-Welt sind die Treiber dieses Wandels, und diese betreffen nicht nur Softwareprojekte.
Ist agilität immer die antwort?
Trotz dieser Entwicklungen und dem Verständnis darüber, dass agile Arbeitsweisen eine geeignete Antwort darauf sein können, werden in den meisten Entwicklungsprojekten auch heute noch klassische Ansätze genutzt. Agilität beschreibt dabei auch nicht lediglich die Umsetzung von agilen Frameworks und Methoden wie Scrum oder Kanban, sondern vor allem auch Grundverständnisse und Unternehmenskultur. Doch wie kann nun ein Unternehmen, das bislang in der Vergangenheit mit stabilen Prozessen erfolgreich gearbeitet hat, die Brücke hin zur Agilität schlagen?
Der wichtigste Grundsatz dabei: Projekte sind verschieden und einzigartig. Aus diesem Grund klassifizieren wir Entwicklungsprojekte in vier verschiedene Klassen. Dabei werden zur Einordnung zwei grundlegende Fragen herangezogen: Ist Agilität in dem Projekt nötig?
Machen das Produkt und das Umfeld des Entwicklungsprojekt eine agile Herangehensweise überhaupt zwingend erforderlich? Beeinflusst wird die Antwort auf diese Frage durch die Komplexität und den Innovationsgrad des Produktes. Weiter unterscheidet sich die Notwendigkeit von Agilität in der Art des Produktes, beispielsweise den Software- bzw. Hardware-Anteil oder den Grad der Einbeziehbarkeit des Kunden. Auch die Komplexität des Entwicklungsprojektes selbst, also Teamgrößen, die aktuelle Phase des Projektes, externe Partner oder die Stabilität der Prozesse geben Aufschluss.
Die zweite Frage zur Einordnung eines Projektes lautet: Ist Agilität möglich? Hierbei steht das Umfeld der Organisation und deren Befähiger der Agilität im Vordergrund. Welche Kompetenzen besitzen die Mitarbeitenden der Organisation? Versteht sich die Führungsebene als Servant Leader? Welche personellen Kapazitäten hat das Projekt inne? Hinzu kommen Evaluationen der Organisationsstruktur und -kultur: Wird eine Fehlerkultur gelebt? Wie funktionieren die Kommunikationswege in diesem Projekt?
Hat die Organisation Erfahrungswerte in der agilen Zusammenarbeit? Durch diese zwei zentralen Fragen können viele Entwicklungsprojekte in eine der folgenden vier Klassifizierungen eingeordnet werden: Classic – wir nennen diesen Typus auch den „Delfin“, Selective Agile – der „Gepard“, Agile Practitioners – der „Nandu“, Full Agile – der „Mauersegler“. Wieso wir diese Typen so benennen?
Hat die Organisation Erfahrungswerte in der agilen Zusammenarbeit? Durch diese zwei zentralen Fragen können viele Entwicklungsprojekte in eine der folgenden vier Klassifizierungen eingeordnet werden: Classic – wir nennen diesen Typus auch den „Delfin“, Selective Agile – der „Gepard“, Agile Practitioners – der „Nandu“, Full Agile – der „Mauersegler“. Wieso wir diese Typen so benennen?
DER DELFIN
Delfine lernen kontinuierlich und haben ein ausgezeichnetes Gedächtnis. Selbst nach zwanzig Jahren erkennen sie ihre Gefährten an ihrem individuellen Namenspfiff wieder. Delfine sind „always on“, eine Gehirnhälfte ist stets wach. Sie leben in großen Gruppen („Delfinschulen“).
Weitere Eigenschaften: Delfine sind Meister der Orientierung, geprägt von ihrer loyalen und sozialen Art und einer starken Bindung zur Führung.
DER GEPARD
Auf der Jagd kann der Gepard Geschwindigkeiten über 90 km/h erreichen und ist mit diesen Sprints der effizienteste Einzeljäger im Tierreich. Er setzt seine Kraft gezielt und stets punktgenau für kritische Phasen ein.
Der Gepard besitzt darüberhinaus die Fähigkeit, sich wendig und reaktionsschnell durch sein Revier zu bewegen.
DER NANDU
Der Nandu zählt zu den schnellsten Tieren der Welt. Nandus leben mit ihren Artgenossen in kleineren Gruppen, schließen sich gelegentlich aber auch Herden anderer Tierarten an (z.B. Antilopen oder Zebras). Sie müssen theoretisch nicht trinken, der Flüssigkeitsbedarf kann fast ausschließlich über die Nahrung gedeckt werden. Diese Eigenschaften machen ihn zu einem gleichermaßen schnellen und flexiblen, als auch zu einem wachsamen und ausdauernden Tier.
DER MAUERSEGLER
Etwa 10 Monate im Jahr verbringt der Mauersegler nonstop in der Luft, selbst im Schlaf und beim Fressen fliegt er. In Trupps fliegen die Vogel von Europa ins südliche Afrika. Dabei passen sie ihre Route den entsprechenden Wetterbedingungen an, um auf dem Weg möglichst viel Nahrung zu finden und möglich nur kurze Zeit starkem Regen ausgesetzt zu sein. In den großen Gruppen zeigt sich: Der Mauersegler ist ein Teamplayer. Stets fokussiert und anpassungsfähig legt er voller Ausdauer große Strecken zurück.
Klassische ansätze und agile ansätze – wie feuer und wasser?
In Projektumfeldern, in denen klassische und agile Ansätze aufeinandertreffen und möglichst Hand in Hand arbeiten müssen, ergibt sich die Schwierigkeit der Synchronisierung zwischen agilen Ergebnissen im Takt von Sprints mit einem klassischen Meilensteinplan. Es gilt also, die Synchronisationspunkte dieser beiden Parteien herauszufinden und aktiv zu verwalten. Eine Variante: Das Wasserfallteam „diktiert“ durch die geplanten Meilensteine und das agile Team liefert in diesen diktierten Plan „hinein“. Die Alternative: Idealerweise wird es möglich, eine gemeinsame Kadenz zwischen diesen Teams zu schaffen. Ist es für das klassisch arbeitende Team nicht möglich, die Dauer eines Sprints in ihrer Arbeit zu erreichen, dann kann es dennoch sinnvoll sein, einen übergeordneten, gemeinsamen Takt zu vereinbaren, ggf. auch das vielfache des Taktes des agilen Teams (z.B. 2 Wochen Takt SW-Team und 4 Wochen HW-Team).
Eine weitere Problemstellung: In hybriden bzw. selektiven Teams sind dessen Mitglieder zumeist nur anteilig in diesem Projekt beschäftigt. Es fehlt also die 100-prozentige Dedication zu diesem Entwicklungsprojekt. Hierbei kann es hilfreich sein, ein Kernteam zu definieren, dass in diesem Projekt zu 100 Prozent vollbeschäftigt ist und anteilige Teammitglieder um dieses Kernteam herum anbauen. Dennoch sollte in Projekten wie diesen das Erwartungsmanagement angepasst werden. Ein Team, in dem nicht alle Mitglieder 100-prozentig beschäftigt sind, wird nicht dieselben Ergebnisse liefern können.
Wird ein Modus erreicht, in dem durch entsprechende Synchronisationspunkte eine Ko-Existenz von klassischer Arbeit und agiler Arbeit innerhalb desselben Entwicklungsprojektes gemanaged wird, können mit dieser Zusammenstellung durchaus erfolgreiche Ergebnisse erzielt werden! Die beiden Arbeitsweisen sollten also weniger als Gegensätze verstanden werden, sondern als unterschiedliche Herangehensweisen für unterschiedliche Problemstellungen, die auch in Gemeinsamkeit ein Mittel für spezifische Problemstellungen sein können.
Sind wir auf dem weg zur agilität?
Aufgrund der beschriebenen Entwicklungen streben viele Unternehmen danach, sich hin zu einer vollständig agil arbeitenden Organisation zu entwickeln. Jedoch ist dieser Wandel kein einziger Stellhebel, der von einem Moment auf den nächsten umgelegt werden kann, sondern erfordert eine lang andauernde Transformation, die nicht nur die Top-Down-Einführung von agilen Frameworks beinhaltet, sondern insbesondere Bottom-Up-Entwicklungen der Kultur und des Selbstverständnisses der Organisation und deren Mitarbeitenden. Sind wir also nun auf dem Weg zur Agilität? In der langen Sicht, ja! Aber, um es mit den Worten von Keynes zu beschreiben: „Langfristig gesehen sind wir alle tot.“
Zugegeben, die Aussage mag hart erscheinen. Dennoch gilt, besonders in schnelllebigen Umfeldern wie der VUCA-Welt, verstärkt die mittelfristige Sicht! In dieser mittelfristigen Sicht befinden wir uns also heute in vielen Organisationen auf der Reise von alten, bewährten Abläufen hin zur Agilität als Antwort auf die VUCA-Welt. Aus diesem Grund empfehlen wir, sich diesen Umstand bewusst zu machen, ein individuelles Arbeitsmodell für den spezifischen Einsatz zu entwickeln, und sobald dieses gefunden und erprobt wurde, das „eigene Rahmenwerk“ zu skalieren.
So wird ein passendes Vorgehen für die Ko-Existenz der beiden Ströme klassischer und agiler Arbeit angewendet, diese Ko-Existenz aktiv und bewusst gemanaged und auf lange Sicht eine Konvergenz dieser beiden Ansätze erreicht.
Fazit
Dieser Blogpost hat gezeigt: Häufig geht es nicht um klassisch oder agil. Es geht nicht um schwarz oder weiß und es geht auch nicht darum, auf Biegen und Brechen überall Agilität „einführen“ zu wollen. Vielmehr geht es um klassisch und agil. Es geht darum, individuelle Lösungen für Situationen zu finden, in denen eine Ko-Existenz der beiden vermeintlichen Gegenströme die richtige Vorgehensweise ist. Besonders aufgrund dessen, dass der Wandel hin zur Agilität Zeit braucht, ist es besonders wichtig, sich kurz- bzw. mittelfristig mit der Ko-Existenz zu befassen.
Weiter geht es auch darum, sich nicht grundsätzlich auf Agilität als Lösung für jedes Problem festzufahren. Helfen mir agile Ansätze überhaupt bei meiner Problemstellung? Sind diese agilen Ansätze in meiner individuellen Situation überhaupt anwendbar? Hat sich ein Modell mit der Ko-Existenz von klassisch und agil arbeitenden Teams entwickelt, setzt meist ein Effekt ein, der einem schwarzen Loch ähnelt: Klassisch arbeitende Teams kreisen um die hoch performanten agil arbeitenden Teams und profitieren von deren Ergebnissen und Erfahrungen.
Wir als P3 unterstützen Unternehmen als kompetenter Partner auf diesem Weg der Transformation mit besonderer Berücksichtigung der Individualität einer jeden Organisation. Denn kein Rahmenwerk und keine Methode sind eine allmächtige Lösung für jedes Problem. Unsere Erfahrungen helfen uns stets dabei, Unternehmen nicht nur dabei zu unterstützen, langfristig agil zu werden, sondern auch dabei, den Weg dort hin mit hybriden und selektiven Ansätzen erfolgreich zu steuern.
