Kitabı oku: «Agile Organisation – Methoden, Prozesse und Strukturen im digitalen VUCA-Zeitalter»

4.4 Agile Koordination

Weil sich die Charakteristika der Koordination in agilen Unternehmen nicht 1:1 den Prozessen bzw. Strukturen zuordnen lassen, sondern die folgenden Koordinationsprinzipien für Prozesse und Strukturen gelten, werden sie hier in einem eigenen Kapitel 4.4 vorgestellt. Wie diese Koordinationscharakteristika in konkreten agilen Methoden und Ansätzen angewendet bzw. umgesetzt werden, wird dann später in den Kapiteln 6 bis 8 erläutert.

Selbstorganisation

Die Koordination innerhalb agiler Prozesse und Strukturen erfolgt nicht durch detaillierte Pläne, festgelegte Prozessbeschreibungen oder eine übergeordnete Instanz, sondern „auf Augenhöhe“ zwischen den Mitgliedern innerhalb der Teams im Rahmen definierter Rahmenprozesse. Das heißt, statt Fremdorganisation (vgl. Kapitel 3.4) erfolgt Selbstorganisation. Selbstorganisation im unternehmerischen Sinne bedeutet, dass Akteure eigenverantwortlich darüber entscheiden, wie sie die zu erledigenden Aufgaben ausüben. Denn es wird davon ausgegangen, dass bessere Entscheidungen getroffen werden, wenn sich diejenigen, die die Aufgaben operativ tun – und damit näher am Problem und Kunden dran sind – direkt selbst untereinander abstimmen und dabei ihre unterschiedlichen Kompetenzen und Perspektiven einbringen.¹¹⁰ Der kollektiven Intelligenz/Kompetenz des Teams an der Basis werden bessere Entscheidungen zugetraut als der individuellen Intelligenz/Kompetenz einer Führungskraft oder eines Vorgesetzten.

Selbstorganisation ist aber nicht gleichbedeutend mit Hierarchiefreiheit. Stattdessen kann treffender von „hierarchiearm“ gesprochen werden.¹¹¹ Eine gewisse Über- und Unterordnung gibt es meist auch in agilen Organisationen (vgl. Kapitel 8). Untergeordnete Organisationseinheiten (z. B. Subkreise, Squads) müssen sich natürlich irgendwie an den Entscheidungen in der übergeordneten Organisationseinheit (z. B. Kreis, Tribe) ausrichten – und alle am gemeinsamen Zweck (Purpose). Einzelne Rollen (z. B. Lead Link, Tribe Lead) können durchaus disziplinarische Macht ausüben.¹¹² Und es gibt Rechtsvorschriften (z. B. § 76 AktG, § 35 GmbHG, § 26 BGB), die geschäftsführende Positionen einfordern. Darüber hinaus werden temporäre Hierarchien, in denen sich Führungsaufgaben auf mehrere bzw. wechselnde Personen verteilen, oft auch in agilen Strukturen akzeptiert. Schließlich bilden sich bei fehlenden formellen Hierarchien sehr häufig informelle Machtstrukturen bzw. Hierarchien. Von daher führt Selbstorganisation zu Hierarchiearmut, aber nicht Hierarchiefreiheit.

In agilen Organisationen gilt deshalb das organisatorische Subsidiaritätsprinzip, das besagt, dass Entscheidungen möglichst weit „unten“ getroffen werden und „höhere“ Einheiten nur dann eingreifen sollten, wenn die Möglichkeiten des Einzelnen bzw. des Teams auf der niedrigeren Ebene allein nicht ausreichen, um eine bestimmte Aufgabe zu lösen. Dabei kann sich die Entscheidungshoheit nicht nur auf die Art und Weise der Aufgabenverrichtung erstrecken, das Wie, sondern umfasst u. U. auch die Entscheidung darüber, welche Zielsetzung und welche Aufgaben überhaupt verfolgt werden, das Was. Das schließt beispielsweise die Entwicklung eigener Prinzipien zur Selbststeuerung und Selbstführung mit ein – Ausführungs-, Ergebnis-, Prozess- und Führungsverantwortung sind gebündelt und liegen in einer Hand. Dazu benötigen die Akteure weitreichende Kompetenzen bzw. Rechte. Zu große Freiräume bei Akteuren oder Teams können die Gesamtorganisation jedoch schnell überlasten.

Welcher Grad an selbstorganisiertem und eigenverantwortlichem Handeln sinnvoll ist, hängt vom jeweiligen Kontext ab. In selbstorganisierten Systemen geht der Bedarf nach Regeln und Struktur idealtypisch von dem Rolleninhaber aus, bei dem dieser entsteht und wird nach Möglichkeit auch durch diesen gelöst. Nur wenn eine organisatorische Einheit den Regelungsbedarf nicht selbst lösen kann bzw. weitere Rollen oder Teams in die Entscheidung involviert oder von dieser betroffen sind, treten übergreifende Koordinationsmechanismen in Kraft (vgl. nächsten Punkt). Der Regelungsbedarf wird auf dafür geschaffene Plattformen bzw. Ebenen „gehoben“ und allen Beteiligten und Betroffenen transparent gemacht.

Das Unternehmen W. L. GORE & ASSOCIATES zieht seine Agilität aus klaren Regeln, die sich aus vier verbindlichen Unternehmensprinzipien ableiten: Freiheit, Selbstverpflichtung, Fairness und Waterline. Das Waterline-Prinzip vergleicht das Unternehmen mit einem Schiff, das sich bereits auf hoher See befindet, an dem jedoch ständig weitergebaut wird. Hier ist es wichtig, dass Entscheidungen unterhalb der Wasserlinie, die das Schiff ins Wanken oder sogar in eine existenzielle Schieflage bringen könnten, konsultativ und verantwortungsvoll getroffen und getragen werden. Dabei gelten die Prinzipien der Verhältnismäßigkeit und Eigenverantwortung – die Akteure entscheiden eigenverantwortlich, ob sie sich mit ihren Entscheidungen und Handlungen über oder unter der Wasserlinie befinden.¹¹³ Ein Lernprozess, der jedem Mitarbeiter (Associate/Teilhaber) abverlangt wird und nach eigenen Aussagen zwei bis drei Jahre dauern kann, bis man dieses Prinzip verinnerlicht hat.¹¹⁴

Ebenfalls inspirierend ist das Beispiel des US-amerikanischen Chemieunternehmens WD-40 COMPANY. Hier gilt für die Mitarbeiter bezogen auf ihren Verantwortungsbereich: “I am responsible for taking action, asking questions, getting answers, and making decisions. I won’t wait for someone to tell me. If I need to know, I’m responsible for asking. I have no right to be offended that I didn’t get this sooner. If I’m doing something others should know about, I’m responsible for telling them.”¹¹⁵ Diese Aussage, WD-40 spricht von „Maniac Pledge“ (verrücktes Versprechen), bringt sehr klar zum Ausdruck, welche Freiheiten, aber auch welche Verantwortung mit Selbstorganisation verbunden sind.

Viele agile Initiativen kranken an einer Überdosis verordneter Selbstorganisation und missverstandener Delegation. Agiles Management bedeutet aber nicht „laissez faire“, Verantwortung einfach zu delegieren und auf Mitarbeiter oder Teams zu übertragen, eine „Open Door Policy“ auszurufen oder ab „jetzt sofort“ auf Dress-Codes zu verzichten. So gesehen ist auch die Selbstorganisation zu organisieren.

Definierte Abstimmungs- und Entscheidungsprozesse

Wenn die Organisation durch die operativen Mitarbeiter (Rolleninhaber) selbst bzw. durch die Mitglieder der agilen Teams – und nicht durch Fremdorganisation einer „höheren“ Instanz – erfolgt, dann ist es für ein effizientes Vorgehen wichtig, dass genau festgelegt ist, wer welche Entscheidungen treffen darf bzw. wie Entscheidungen getroffen werden. Lange Diskussionen mit unklaren Verantwortungen sind weder effektiv noch effizient. Aus diesem Grund gibt es auch in agilen Organisationen definierte Abstimmungs- und Entscheidungsprozesse.

Es gibt eine Vielzahl an konkreten Entscheidungsverfahren bzw. -werkzeugen. Einige der Beiträge in diesem Buch gehen auf diese Thematik ein und erläutern die im jeweiligen Unternehmen angewendeten Verfahren (vgl. bspw. HEILER/BORCK, FISCHERMANNS, SCHULLER/FUCKER und TILLMANNS-ESTORF et al.).¹¹⁶ Etwas vereinfacht lassen sich die verschiedenen Entscheidungsverfahren in dem Kontinuum von Abbildung 21 verorten. Auf der einen Seite gibt es Themen und damit Entscheidungen, für die eine Rolle verantwortlich ist und eigenständig und autonom entscheiden kann. Dies ist insbesondere bei operativen Aufgaben sinnvoll, die vielzahlig auftreten, keine weitere Kompetenz benötigen, keinen wesentlichen Einfluss auf andere Rollen haben und vor allem kein Risiko für das Gesamtsystem darstellen. Auf der anderen Seite des Kontinuums stehen Entscheidungen von strategischer Bedeutung für das Gesamtsystem (vgl. auch GORE-Beispiel weiter oben). Hier sind Gruppenentscheidungen im Konsens (alle stimmen zu), im Konsent (keiner hat einen begründeten, schwerwiegenden Einwand) oder nach Mehrheitsregeln möglich. In agilen Teams wird dabei häufig dem Konsentverfahren gefolgt. Wenn keiner einen schwerwiegenden Einwand hat, dann ist es „safe enough to try“, was übersetzt so viel heißt wie: „Wenn es momentan keine nachgewiesenen Einwände gegen diesen Vorschlag gibt, dann hindert uns nichts daran, ihn auszuprobieren.“ Ebenfalls sehr beliebt ist der konsultative Einzelentscheid, bei dem die verantwortliche Rolle oder eine gemeinschaftlich bestimmte Person verpflichtet ist, relevante Stakeholder bzw. Experten zum Thema zu konsultieren und deren Meinung einzuholen.

Abb. 21: Kontinuum von Entscheidungsverfahren¹¹⁷

Die konkreten, in agilen Organisationen vorzufindenden Entscheidungsverfahren, lassen sich prinzipiell in diesem Kontinuum einordnen. Entscheidend ist vor allem, dass es definierte Abstimmungs- und Entscheidungsprozesse gibt und die Entscheidungen dort getroffen werden, wo das dafür notwendige Wissen am größten ist.

Transparenz

Eine Grundvoraussetzung für Agilität – für obsessive Kundenausrichtung, ein funktionierendes Pull-Prinzip, autonome Teams, Selbstorganisation usw. – ist es, dass die Rolleninhaber und agile Teams über alle notwendigen Informationen verfügen. Agilität benötigt Transparenz. Transparenz bzw. Offenheit ist die Voraussetzung für Freiheit und Verantwortung in agilen Prozessen und Strukturen.

Damit Mitarbeiter die Bedeutung und Konsequenzen von Aufgaben und Entscheidungen einschätzen und im Sinne des Gesamtunternehmens sinnvoll eigenständig bearbeiten und entscheiden können, brauchen sie z. B. Transparenz über die strategische Ausrichtung, Priorisierungskriterien, Unternehmens-, Finanz- und Wirtschaftlichkeitskennzahlen sowie sonstige entscheidungsrelevante Informationen. Sichtbarkeit – in Verbindung mit Verständnis – ist eine wesentliche Voraussetzung für die Beseitigung von Problemen. Nur bei einer ausgeprägten Transparenz ist eine kurzfristige Einflussnahme und Anpassung möglich. Daher benötigen die Akteure jederzeit Zugang zu empirischen Informationen über Kunden, Produkte, Preise, wirtschaftliche Indikatoren und Kennzahlen. In agilen Organisationen gilt die Grundregel „transparency by default“ bzw. „open by default“.¹¹⁸ D. h. im Normalfall sind alle Informationen für alle zugänglich. Geheimhaltung gibt es nur in begründeten bzw. zu begründenden Ausnahmefällen.

Etliche Beiträge in diesem Buch betonen die Bedeutung von Transparenz.¹¹⁹ Bei TELE HAASE beispielsweise wurden in den letzten Jahren vielfältige Informationsgrenzen – nach innen und auch außen – abgebaut und man hat sich ganz bewusst „in die Karten schauen“ lassen (vgl. STELZMANN/REININGER). Denn eine solche Offenheit wird als fruchtbarer Boden für neue Geschäftsmodelle in Zeiten der Digitalisierung betrachtet. Man hat erkannt, dass dann, wenn Menschen ins Gespräch kommen, anstatt sich hinter selbst gebauten Mauern zu verstecken, Dinge ins Rollen kommen und neue, innovative Ansätze entstehen. Auch bei HEILER (vgl. HEILER/BORCK) und IBO (vgl. FISCHERMANNS) wird eine ausgeprägte Transparenz verfolgt. Alle Mitarbeiter wissen über die wirtschaftliche Lage des Unternehmens immer Bescheid. Gleiches gilt für die Performance und Wirtschaftlichkeit im eigenen Team und Verantwortungsbereich.

Zur Umsetzung von Transparenz wird bei agilen Organisationsansätzen gerne und intensiv mit für alle zugänglichen digitalen und physischen Kommunikations- und Informationsplattformen gearbeitet. Bei agilen Methoden, wie bspw. Kanban und Scrum (vgl. Kapitel 6), spielen transparente Backlogs und Task-Boards meist eine zentrale Rolle in der Koordination der arbeitsteiligen Arbeit. Es ist wichtig, dass alle wissen, wo man steht, was noch zu tun ist und wie sich die Performance verändert. Bei SIEMENS wird deshalb mit Obeyas (japanisch für „großer Raum“) gearbeitet, in denen alle zentralen Projektinfos visualisiert sind und die Projektmeetings stattfinden (vgl. den Beitrag von KALNIK). Dadurch sind immer alle zentralen Infos für alle transparent und greifbar. Auf diese Weise wird für schnelle Kommunikation und kurze Entscheidungswege gesorgt.¹²⁰

Eine solche Transparenz bzw. Offenheit erfordert und fördert ein großes Vertrauen und Zutrauen in die Mitarbeiter (vgl. Kapitel 9). Dies sollte sich in einem hohen Engagement und verantwortungsvollen Mitentscheiden und Mitgestalten niederschlagen. Transparenz ersetzt so in agilen Systemen umfangreiche Kontrollsysteme.¹²¹

Purpose-Orientierung

In dynamischen und komplexen Umfeldern mit hoher Unsicherheit ist es nicht möglich bzw. nicht sinnvoll, sehr konkrete Ziele und ausgefeilte Pläne zu definieren. Im ungünstigsten Fall ist der Plan bereits obsolet, bevor er zu Papier gebracht worden ist. Da es aber auch in solchen Umfeldern einer Koordination der verschiedenen Aktivitäten bedarf, richten agile Unternehmen ihr Handeln meist an einem Purpose aus. Er ist zentraler Orientierungspunkt und Grundlage für alle Entscheidungen, die auf der Unternehmensebene, in Teams und von jedem einzelnen Organisationsmitglied getroffen werden. Er stellt die Existenz in den Mittelpunkt und beantwortet die einfache, jedoch grundsätzliche Frage, warum es ein Unternehmen gibt bzw. wofür es da ist. Aus individueller Sicht betrachtet könnte diese Frage auch lauten: „Warum tue ich das, was ich tue?“

Ein Purpose beschreibt damit aus unternehmerischer Sicht einen gemeinsamen, kohäsiven Sinn und Zweck, an dem sich alle Aktivitäten orientieren. Er soll sicherstellen, dass alle Organisationsmitglieder ihr Handeln auf die Erfüllung markt- und kundenorientierter Bedürfnisse ausrichten und gleichzeitig eigenverantwortlich und wertschöpfend zur Aufrechterhaltung und (Weiter-)Entwicklung des Ökosystems beitragen, indem sie als Individuen innerhalb und außerhalb des Unternehmens agieren. SIMON SINEK beschreibt mit dem sogenannten Golden Circle idealtypisch, wie Organisationen ausgehend von der Antwort auf das Warum/Why (Sinn und Zweck), das Wie/How (Strategien und Prinzipien) ableiten, um das Was/What (Produkte und Leistungen) zu beantworten (vgl. Abbildung 22).¹²²

Abb. 22: Elemente eines Purpose¹²³

Ein guter Purpose integriert die Bedürfnisse jedes einzelnen Organisationsmitglieds in einem übergreifenden Statement, erzeugt dadurch eine persönliche und emotionale Verbundenheit und sorgt auf diese Weise für die notwendige Abstimmung und Ausrichtung der Gesamtorganisation. Dem Purpose-Statement geht daher häufig ein intensiver Findungsprozess voraus, in den die Organisationsmitglieder (repräsentativ) eingebunden werden sollten, damit sie sich an dessen Formulierung und Ausgestaltung beteiligen können.¹²⁴ Er reicht somit weiter, als die bei vielen Unternehmen bisher oft übliche Ausprägung bzw. Verankerung von Vision oder Mission. Prinzipiell ist es unerheblich, wie das Kind am Ende heißt, im agilen Kontext hat sich aber der Purpose-Begriff durchgesetzt (vgl. Exkurs-Box).¹²⁵ Die sogenannten Purpose Driven Organizations sind aktuell populärer Untersuchungsgegenstand zahlreicher Studien.¹²⁶

„Wir gestalten Lebensräume für zukünftige Generationen – We create living spaces for generations to come.“ So lautet der Purpose des 1917 gegründeten und international tätigen Familienunternehmens VIESSMANN (Warum/Why). Der Hersteller und Anbieter von Energie- und Klimalösungen ist sich seiner Verantwortung bewusst. Die rund 12.300 Familienmitglieder leisten Tag für Tag ihren Beitrag zur Erreichung der Klimaschutzziele. Sie setzen dabei konsequent auf Digitalisierung als unabdingbare Voraussetzung für die Energiewende und sorgen so für ein gesundes Zuhause, eine emissionsfreie Stadt und einen lebenswerten Planten. Untrennbar damit verbunden ist der Wandel der eigenen Unternehmenskultur, in den alle aktiv eingebunden sind. Verantwortlich, teamorientiert und unternehmerisch – das sind die Werte und Wesenszüge, die jedes Familienmitglied tagtäglich in seinem Handeln prägen (Wie/How) und u. a. in den intelligenten und nachhaltigen Energiesystemen und Kühllösungen für die Bereiche Wohnen, Industrie und Gewerbe zum Ausdruck kommen (Was/What).¹²⁷

Die Kernbotschaft von VIESSMANN „ist sehr stark durch den Klimawandel getrieben. Wir überlegen, wie wir die Menschen unterstützen können CO₂ einzusparen. Damit wir diesen Planeten nicht verlassen müssen, sondern dableiben können. Von da aus kann man den Rest leicht runterbrechen: Unternehmensziele, Strategie, Vision. Und daran die Einzelaufgaben für jeden ableiten“, sagt MARKUS PFUHL, Chief of Staff & Strategy, VIESSMANN FAMILY HOLDING.¹²⁸

Ein Purpose ist kein Ersatz für Strategien oder Ziele. Vielmehr bildet er den zentralen Gravitationspunkt für die Unternehmenssteuerung und ermöglicht insbesondere in unsicheren Zeiten Flexibilität bei der operativen Entscheidungsfindung im Tagesgeschäft als auch zur übergreifenden (Re-)Priorisierung umfangreicherer Projekte und Themen. Vielleicht war es gerade deshalb auch dem „Heizungsbauer“ VIESSMANN möglich, während der Corona-Krise innerhalb kürzester Zeit einen Teil seiner Produktion auf Beatmungsgeräte umzustellen (vgl. Kapitel 1). In einem Workshop kamen u. a. Intensivmediziner und VIESSMANN-Entwickler zusammen – nach drei Tagen lag der erste Prototyp vor, nach drei Wochen das entwickelte Beatmungsgerät, das ausschließlich Teile enthält, die VIESSMANN in seinen Heizungsgeräten und Wärmepumpen verbaut. Dabei stammen sämtliche Ideen von eigenen Mitarbeitern und Partnern.¹²⁹

In agilen Organisationen kennen idealerweise alle Organisationsmitglieder auf allen Ebenen ihren eigenen Purpose – vom Individuum und einzelnen Rollen (vgl. Rollendefinition bei Holacracy in Kapitel 8.3), über die Ebene der einzelnen agilen Teams bzw. Module und ggf. weiterer Substrukturen (z. B. Purpose für Subkreise, Squads o. ä., vgl. Kapitel 8), bis zur Unternehmensebene (vgl. VIESSMANN-Beispiel). Das folgende Beispiel eines Medienhauses zeigt, wie ein Purpose über verschiedene Ebenen formuliert und ineinandergreifen kann.

„Menschen mit authentischen Geschichten inspirieren und ermutigen, selbstbewusst durchs Leben zu gehen.“ (Purpose des Medienhauses – Unternehmensebene).

„Wir suchen leidenschaftliche Geschichten, die uns inspirieren, andere zu inspirieren.“ (Purpose im Kreis der Redakteure – Bereichs-/Team-Purpose).

„Ich produziere wertvolle Inhalte und nutze nachhaltige Formate.“ (Purpose des Mediengestalters – Rollen-Purpose).

Einen Zustand aus völliger Kongruenz aller „Purposes“ zu erreichen ist jedoch eher utopisch, denn durch die permanente Dynamik innerhalb und zwischen den verschiedenen (Sub)Systemen beeinflussen sich diese gegenseitig, stehen in einer ständigen Wechselwirkung und sind Gegenstand von Aushandlungsprozessen auf operativer und strategischer Ebene (vgl. den OKR-Ansatz in Kapitel 6.6).

Purpose-Orientierung bedeutet, dass es – gerade in VUCA-Umfeldern – hilfreich bzw. effektiv ist, wenn (agile) Teams, Unternehmensbereiche und ganze Unternehmen eine starke gemeinsame Ausrichtung haben. Wichtig ist dabei die sinnvolle Ausgestaltung, nicht die Begrifflichkeit. Ob man den – aktuell „gehypten“ – Purpose-Begriff benutzt, oder (weiter) mit dem klassischen Begriff Mission arbeitet, ist prinzipiell unerheblich. Zwar wird der (Corporate) Purpose z. T. dadurch von einer (Unternehmens-)Mission¹³⁰ abgegrenzt, dass es um einen „höheren“, nicht rein geschäftlichen Sinn geht bzw. gehen soll – im Sinne einer Mischung aus Geschäftsauftrag und sozialen bzw. ökologischen Werten (Unternehmensphilosophie). Aber eine gute Mission war schon immer mehr als „Geld verdienen“, das sollte eigentlich keine wirklich neue Erkenntnis sein. Von daher bräuchte es neben Vision und Mission nicht zwingend noch eines weiteren Begriffs. Wichtig ist es aber in jedem Fall, dass das Handeln eine klare, motivierende und gemeinsame Ausrichtung bekommt, welche die Besonderheiten des konkreten Teams, Bereichs und Unternehmens berücksichtigt.

Bei kritischer Reflexion hat hier – wie häufiger im Management – ein „neuer“ Begriff einem alten Thema neuen Schwung gegeben. Das ist auch nicht schlimm. Wenn sich alte Begriffe und Konzepte ausgelaufen haben, kann es sinnvoll sein, wichtigen Themen mit neuen Namen wieder „Leben einzuhauchen“. In jedem Fall sollten aber nicht mit großem Brimborium und Beraterkosten allgemeingültige Plattitüden ohne Unternehmensbezug („Wir verbessern die Welt“) auf Hochglanzpapier produziert werden. Auch sollte man nicht glauben, dass ein (Corporate) Purpose alleine – wie klar und attraktiv auch immer – zur Sinnstiftung ausreicht und dann „automatisch“ alle im Unternehmen mit „großem Hurra“ am selben Strang in die gleiche Richtung ziehen. Vielmehr muss dieser Anspruch mit vielen anderen Dingen im tagtäglichen Unternehmensgeschehen korrespondieren.

Spannungsgetriebene Konfliktbearbeitung

Die oben beschriebenen Charakteristika Selbstorganisation, Transparenz, Abstimmungs-/Entscheidungsprozesse und Purpose zeigen die Kriterien auf, nach denen sich Akteure in agilen Strukturen und Prozessen koordinieren. Sie sind wie Puzzleteile, die, wenn sie adäquat zusammengefügt und integriert werden, ein Spielfeld bereitstellen, auf dem die Organisationsmitglieder interagieren können.

Dort, wo Interaktion stattfindet, treffen nicht selten unterschiedliche Wahrnehmungen und Erwartungen aufeinander. Sie sind der Nährboden für Spannungen und Konflikte. Eine agile Organisationsgestaltung öffnet bewusst Räume und schafft Plattformen, um Spannungen (Tensions) und Konflikte offenzulegen und aus diesen zu lernen. Die Bearbeitung von Konflikten und die Lösung von Spannungen liegen in agilen Organisationen nicht auf den Schultern ausgewählter Personen oder sind in eigens dafür geschaffenen Bereichen, wie z. B. Organisationsentwicklung oder Change-Management, verankert. In agilen Organisationen ist jeder einzelne Rolleninhaber dafür verantwortlich.

Agiles Arbeiten ist u. a. auch aufgrund dieser Relevanz von Spannungen und Konflikten, die von Rolleninhabern und Teams selbst gelöst werden müssen, „ganz schön“ anstrengend. Es fehlt (bewusst) an der übergeordneten Instanz, die schwierige Entscheidungen abnimmt. Auch deshalb passt agile Arbeit nicht in jeden Kontext.

Eine Spannung ist in diesem Zusammenhang die Momentaufnahme einer erlebten Differenz zwischen einem Ist- und einem erwarteten Soll-Zustand.¹³¹ Wie TILLMANNSESTORF et al. in ihrem Beitrag in diesem Buch treffend formulieren, ist Spannung die Energie zwischen dem Status quo und dem, was sein könnte, oder was sein sollte. Spannungen treten häufig dann auf, wenn Entscheidungen nicht eigenverantwortlich oder fallabschließend getroffen werden können, sei es aufgrund von Kapazitätsengpässen, Priorisierungskonflikten oder Missverständnissen zwischen Rollenerwartung und Rollenwahrnehmung (vgl. Kapitel 4.3). Das ist insbesondere dann der Fall, wenn den betroffenen Rolleninhabern wesentliche Informationen fehlen oder die Selbststeuerung mit erheblichem Abstimmungsaufwand verbunden ist bzw. zu Doppelarbeiten und zu Verschwendungen führt. Inwieweit Rolleninhaber ihre Kompetenzen im Sinne des Unternehmens möglichst optimal einbringen können, hängt also stark davon ab, welche Erwartungen das Umfeld an eine Rolle hat. Diese Erwartungen werden aber häufig nicht ausgesprochen, sind mitunter sogar unbewusst. Eine rollen- oder teamübergreifende Abstimmung und Koordination auf „höherer“ – nicht hierarchischer Ebene – ist dann meist zielführender und akzeptierter, als wenn Rolleninhaber diese Konflikte mit sich selbst ausmachen oder versuchen, diese informell untereinander zu klären (vgl. hierzu z. B. die Impediment-Arbeit des Scrum Masters in Kapitel 6.3). „Nichts hat so viel Macht wie das Ungesagte“, das zu erkennen und offen zu thematisieren ist häufig ein langer Prozess.

FISCHERMANNS bspw. beschreibt in seiner 7-jährigen Lernreise eindrücklich, welche Herausforderungen es in dieser Hinsicht zu bewältigen gab. Unterstützend und hilfreich waren in diesem Prozess verbindliche und akzeptierte Entscheidungsregeln ebenso wie strukturierte Synchronisations- und Meetingformate, die eine permanente Arbeit am und im System gewährleisten. Am Beispiel des OKR-Ansatzes (vgl. Kapitel 6.6) und der Holokratie (vgl. Kapitel 8.3) macht FISCHERMANNS deutlich, wie solche rollenübergreifenden Entscheidungsprozesse stattfinden und Spannungen prozessiert werden können. Und manchmal hilft auch der symbolische Akt des „Schreibtischzersägens“, um zu verdeutlichen, dass die offene, ehrliche und eigenverantwortliche Bearbeitung von Konflikten und Spannungen kein Tabu-Thema mehr ist. HARTMANN macht in seinem Beitrag am Beispiel eines Versicherungsunternehmens deutlich, wie die Qualität einer Organisation von der Qualität der Interaktionen zwischen den Individuen abhängt und wie diese im Rahmen einer Veränderungsarchitektur optimiert werden können.

Transparente Koordinationsmechanismen, die selbstorganisiert geschaffen werden und wieder vergehen, sobald diese durch neue Formen der Abstimmung ersetzt oder obsolet werden, tragen dazu bei, dass die Verbindlichkeit gegenüber Prozessen und das Vertrauen unter den Organisationsmitgliedern gestärkt werden. Je besser es gelingt, die Erwartungen offen auszuhandeln, Spannungen zu lösen und die Beziehungen bewusst zu gestalten, desto besser können Rolleninhaber in selbstorganisierten Unternehmen wirken. Im Idealfall besteht eine Kongruenz aus Rollenbeschreibung, Rollenwahrnehmung und Rollenerwartungen, wie in Abbildung 23 aufgezeigt wird.

Abb. 23: Wirksame Rollenausübung

Zusammenfassend lässt sich für Kapitel 4.4 festhalten, dass die Koordination in agilen Prozessen und Strukturen nicht fremdorganisiert erfolgt, sondern auf Selbstorganisation durch die operativ tätigen Rollen und Teams basiert. Damit Selbstorganisation funktioniert, braucht es eine ausgeprägte Transparenz über alle relevanten Informationen, definierte Abstimmungs- und Entscheidungsprozesse sowie die Bereitschaft und Fähigkeit von allen Beteiligten, Spannungen und Konflikte zu lösen. Um das arbeitsteilige, selbstorganisierte Entscheiden und Handeln zu koordinieren, ist schließlich eine gemeinsame Ausrichtung an einem klaren, akzeptierten und motivierenden Purpose (auf verschiedenen Ebenen) sehr hilfreich.

4.5Zusammenspiel von stabilen und dynamischen Elementen in agilen Organisationsansätzen

Die Darstellung der Charakteristika agiler Organisation in den Kapitel 4.2 bis 4.4 hat gezeigt, dass der Anpassungs- und Adaptionsfähigkeit eine große Bedeutung zukommt (z. B. iteratives Vorgehen, kontinuierliches Lernen, kleine autonome Teams, lose Kopplungen, dynamische Rollen, flexible Ressourcenallokation). Agile Organisationsmethoden und -ansätze weisen eine höhere Entwicklungs- und Anpassungsfähigkeit auf als klassisch-hierarchische Ansätze. Damit haben sie in VUCA-Umfeldern klare Vorteile.

Aber damit notwendige und bewährte Routineaufgaben/-prozesse des Tagesgeschäfts nicht dem überschäumenden Flexibilitätsanspruch und dem Drang nach Veränderung zum Opfer fallen, und komplexe unvorhersehbare Vorhaben nicht in ziellosem Aktionismus enden, benötigen auch agile Unternehmen einen Orientierungsrahmen, in dem flexibel und ausgerichtet (inter)agiert werden kann. Anpassungsfähigkeit und Veränderung sind nur mit dem Rückgriff auf „entlastende“ Routinen und Prozesse möglich.¹³²

Genauso wenig wie eine klassisch-hierarchische Organisation völlig starr und unflexibel ist, auch wenn dies von ein paar Agilitäts-Evangelisten teilweise so übertrieben dargestellt wird, genauso wenig kommt eine agile Organisation ohne stabilisierende Aspekte aus (z. B. klare Rahmenprozesse, fixe Meetingstrukturen oder definierte Abstimmungs- und Entscheidungsregeln). Agile Organisationsansätze fokussieren zwar auf Anpassungsfähigkeit in VUCA-Umfeldern, aber auch hier gibt es stabile Elemente bzw. Praktiken, die dem Handeln einen sicheren Rahmen geben und einen Teil der Unsicherheit absorbieren. Stabilität und Anpassungsfähigkeit schließen sich nicht aus. In unserer digitalen VUCA-Welt bedingen sie sogar einander.¹³³

Damit die Organisationsmitglieder selbstorganisiert und eigenverantwortlich wirken können, braucht es klare und verbindliche Regelwerke, definierte Rahmenprozesse und akzeptierte Strukturbausteine.¹³⁴ Selbstorganisation und Eigenverantwortung lassen sich nicht einfach verordnen.¹³⁵ Es gilt: „Wer auf einmal hierarchische Strukturen und Systeme abbaut, aber keine neuen schafft, die künftig vorgeben, wie sich selbstgesteuerte Teams bilden, wie Rollen definiert und zugewiesen werden, wie man zu einem Job kommt oder ihn wieder verliert und wie Entscheidungen getroffen werden, landet geradewegs im Chaos.“¹³⁶

Ein solcher, stabiler Rahmen sollte aber nicht starr oder völlig statisch sein, sondern muss flexibel genug sein, damit die inneren und äußeren Kräfte, die auf eine Organisation wirken, aufgefangen und kompensiert werden können. Es muss möglich sein, zugleich im und am System zu arbeiten, ohne dass sich diese Vorhaben gegenseitig im Wege stehen oder zulasten der Effizienz oder Effektivität gehen.

Die in den Kapitel 6 aufgeführten agilen Projekt- und Prozessmethoden, die Skalierungsansätze in Kapitel 7 und die agilen Strukturansätze in Kapitel 8 folgen allesamt konkreten Routinen und Prozessschritten, beinhalten definierte, verbindliche Praktiken und geben standardisierte Rollen vor. So manifestieren sich z. B. der iterativ-inkrementelle Charakter und das Pull-Prinzip beim Scrum-Ansatz in Formeines definierten Rahmenprozesses. Wie Scrum abläuft, ist definiert und stabil; was und wie in Scrum inhaltlich entwickelt wird, ist dagegen offen und flexibel. Ähnlich ist es z. B. bei LeSS, SAFe oder beim OKR-Ansatz. Agile Strukturansätze wie Holacracy schreiben standardisierte Prozesse und Abläufe vor, nach denen Rollen und Kreise (Module) gebildet werden und wie die Arbeit im und am System effizient und effektiv gestaltet werden kann (z. B. Rollen wie Lead Link, Facilitator, Secretary). Diese stabilen Elemente bieten Sicherheit und Verlässlichkeit, gleichzeitig aber auch Räume für Intervention und Adaption. Retrospektiven bei Scrum dienen in erster Linie der Verbesserung der Zusammenarbeit im Team, Reflexionsschleifen bei Design Thinking stellen die Integration neuer Erkenntnisse in den Innovationsprozess sicher, Tactial und Governance Meetings bei Holacracy dienen der Bearbeitung und Lösung von Spannungen.

Es gilt der Leitspruch „freedom within a frame“, d. h. es gibt definierte, stabile Metaprozesse/-strukturen, die den Rahmen vorgeben, die inhaltliche Ausfüllung erfolgt aber mit großen Freiheiten, um anpassungsfähig an neue bzw. veränderte Erkenntnisse (über Kunden, Märkte, Wettbewerber, Technologien) zu sein. Und es gibt auch Freiheiten, am Rahmen zu drehen.

Agile Organisationen sind somit sowohl dynamisch als auch stabil. Auch agile Ansätze benötigen so gesehen eine gewisse Beidhändigkeit (vgl. nächstes Kapitel). Sie müssen so flexibel sein, dass sich die Handelnden und mithin die Organisation laufend an neue Bedingungen anpassen und kontinuierlich dazu lernen kann, und stabil genug, um dies auf effiziente und effektive Weise systematisch und geordnet zu tun. Im Verhältnis zu klassisch-hierarchischen Organisationen sind agile Prozesse und Strukturen aber in Summe deutlich dynamischer.

Weil dieser Fokus auf Anpassungs- und Entwicklungsfähigkeit aber auch im Digitalzeitalter nicht zu jedem Bereich und jeder Aufgabenstellung passt, sondern verschiedene Bereiche unterschiedlich stark VUCA (vgl. Kapitel 1) sind, sollten agile Ansätze nicht immer und überall gewählt werden. Agile Organisation ist nicht die „Eierlegende Wollmilchsau“. Gerade in größeren Unternehmen braucht es z. T. auch klassische Ansätze. Umgekehrt ist es natürlich auch nicht empfehlenswert, aus Angst vor der eigenen Courage jedes Risiko zu umschiffen und alles so zu lassen wie es ist – nach dem Motto „Das haben wir schon immer so gemacht!“ Das folgende Kapitel 5 geht deshalb nun auf das Zusammenspiel von klassischen und agilen Ansätzen ein.

5 Zusammenspiel von klassischen und agilen Organisationsansätzen (Beidhändigkeit)

Wie bereits mithilfe der Stacey- und Cynefin-Matrix in Kapitel 2.4 erläutert, passen klassische Ansätze, die eher auf Stabilität setzen, in bekannte Umfelder, in denen die Anforderungen und die dafür notwendigen Technologien auf der Hand liegen – das Was und das Wie sind relativ klar. Agile Ansätze wiederum entfalten ihr Potenzial, wenn Umweltbedingungen unbekannt und unbeständig sind, geprägt durch hohe Dynamik.

Beidhändigkeit bzw. situativ-adäquate Balance von klassisch und agil

Die aktuell vielerorts vorzufindenden, unterschiedlichen Organisations- und Führungsansätze in ein und demselben Unternehmen deuten darauf hin, dass es bei der Suche nach den richtigen Organisations- und Führungsprinzipien weniger um ein „entweder oder“, sondern um ein „sowohl als auch“ geht.¹³⁷ Auch sind die Übergänge von klassisch-hierarchisch zu agil teilweise fließend. Es gibt sowohl klassisch-hierarchische Grundstrukturen mit agilen Elementen (z. B. agile Einheiten und Methoden in einem traditionellen Konzern) als auch agile Grundstrukturen, die in Teilen klassisch-hierarchisch gelebt werden (z. B. Kreise in einer Holacracy-Struktur, die wiederkehrende Routineprozesse mit wenigen Unklarheiten und Veränderungen bearbeiten). Eine scharfe Trennlinie zwischen klassisch-hierarchischen und agilen Ansätzen zu ziehen, hätte folglich, wenn überhaupt, nur einen analytischen Mehrwehrt und ist lediglich theoretischer Natur. Es geht beim Organisieren nicht darum, sich als Gesamtunternehmen eindeutig und einseitig zwischen klassisch-hierarchischer und agiler Organisation zu entscheiden. Gesucht sind vielmehr situations-adäquate Organisationsansätze für ein erfolgreiches Handeln im jeweiligen, spezifischen Kontext – und dieser Kontext kann innerhalb eines Unternehmens sehr unterschiedlich sein.

Der scheinbare Konflikt zwischen Stabilität und Wandel bzw. Effizienz und Innovation ist ein schon lange existierendes Kernproblem jedweder Organisationsgestaltung. Die Diskussion um die dynamische Balance aus Stabilität und Wandel hat eine lange Historie und wird aktuell mit dem Fokus auf agile Ansätze erneut befeuert. Etliche Autoren befassen sich in empirischen Untersuchungen mit dem vermeintlichen Widerspruch zwischen Stabilität und Wandel bzw. Agilität (Agilitäts-Stabilitäts-Paradox).¹³⁸ Die Ergebnisse zeigen, dass eine dualistische, trennende Betrachtungsweise, insbesondere vor dem Hintergrund der aktuellen Umweltentwicklungen (vgl. Kapitel 1), nicht haltbar ist. „Organisieren ist diesen Überlegungen zur Folge kontinuierliches Oszillieren zwischen Verwandeln und Bewahren, zwischen Risiko und Sicherheit.“¹³⁹ Es gilt, die Balance zwischen Stabilität und Dynamik immer wieder aufs Neue auszuloten.

Einseitige Extreme sind i. d. R. zu vermeiden. Die Bekämpfung jedweder Unsicherheit und Komplexität durch den Abruf vermeintlich bewährter Muster und das Abspulen reflexhafter, tradierter Routinen und Standards kann ebenso wenig funktionieren wie exzessiver Wandel und permanenter Umbau durch ein Zuviel an Agilität.¹⁴⁰ In diesem Zusammenhang haben sich die Begriffe der „organisationalen Ambidextrie“ bzw. „Beidhändigkeit“ etabliert (engl. Ambidexterity, abgeleitet aus dem Lateinischen ambo „beide“ und dexter „rechte Hand“), die heute längst über die Grenzen der theoretischen Organisationslehre hinaus Anwendung finden und mittlerweile in den praktischen Sprachgebrauch von Organisationsentwicklern übergegangen sind.

Der Begriff basiert auf einem wegweisenden Aufsatz von MARCH aus dem Jahr 1991. Darin hat er Exploration und Exploitation als zwei Formen des organisationalen Lernens unterschieden.¹⁴¹ Während Exploration für Experimente, Alternativensuche, Varianzerhöhung und Risiko steht, repräsentiert Exploitation die Aspkete Regeleinhaltung, Standardisierung, Varianzreduktion und Risikovermeidung. Organisationale Ambidextrie beschreibt die Fähigkeit, einen organisatorischen Rahmen zu bieten, der es den Organisationsmitgliedern erlaubt, gleichzeitig effizient und flexibel zu agieren. Es beschreibt eine Organisation, in der sowohl bestehendes Wissen und bewährte Routinen auf effiziente und effektive Weise genutzt und optimiert werden können, um den operativen Geschäftsbetrieb am Laufen zu halten (Exploitation), als auch neues Wissen generiert und nach neuen Technologien geforscht wird, um Innovationen hervorzubringen und das Unternehmen zukunftsfähig auszurichten (Exploration) – und das zur gleichen Zeit (vgl. Abbildung 24).¹⁴² Untersuchungen zeigen, dass Unternehmen, die über einen längeren Zeitraum erfolgreich sind, es schaffen, sich kontinuierlich an neue Marktbedingungen anzupassen und zu verändern und gleichzeitig die eigene Identität zu bewahren, indem sie sich auf bestehende Strukturen und Kulturen stützen und diese bewusst reflektieren und weiterentwickeln.¹⁴³

Vor diesem Hintergrund haben unterschiedliche organisatorische Ansätze unter einem „Dach“ also nach wie vor ihre Berechtigung. Trotz dieser Erkenntnisse wurden klassische Organisationsansätze in den letzten Jahrzehnten immer wieder abgeschrieben und stehen aktuell mehr denn je im Kreuzfeuer der Kritik.¹⁴⁴ Tatsächlich werden aber viele der zentralen Kernaspekte klassischer Organisation nach wie vor angewendet – und auch agile Ansätze bedienen sich an diesen, wie in Kapitel 4.5 aufgezeigt wurde.

Abb. 24: Organisatorische Beidhändigkeit¹⁴⁵

Die Hartnäckigkeit, mit der sich klassische Ansätze im aktuellen Kontext behaupten, liegt also nur zum Teil an der mentalen Starrheit und der fehlenden Veränderungsbereitschaft von Entscheidern. Es liegt eben auch daran, dass ein gesundes Maß an organisatorischen Regeln und Ordnung sinnvoll ist und sich auch für die Arbeitsteilung und Koordination in komplexen und unbeständigen Umfeldern bewährt. Es gilt: „There is nothing inherently virtuous in agility, or … nothing inherently evil in bureaucracy. They are only tools in the service of a strategy for achieving results.“¹⁴⁶

Arten der Beidhändigkeit

Es werden meist zwei Ansätze der organisatorischen Beidhändigkeit unterschieden – und vor dem Hintergrund der Wirkungsweise sozialer Systeme wird unten noch ein dritter ergänzt. Bei der strukturellen Ambidextrie finden Exploitation und Exploration in organisatorisch getrennten Strukturen bzw. Organisationseinheiten/ -bereichen statt, was folglich die Herausforderung mit sich bringt, mit durchaus unterschiedlichen Arbeitsweisen, Führungsstilen und Kulturen unter einem Dach umzugehen. ARNDT/METTNER erläutern in ihrem Buchbeitrag am Beispiel der R+V, wie strukturelle Ambidextrie in der Praxis aussehen kann.

Im Gegensatz zu dieser Form der beidhändigen Organisation, findet bei der kontextuellen Ambidextrie keine strukturelle Trennung von Exploitation und Exploration statt, sondern es wird je nach Kontext bzw. konkreter Aufgabe situativ aus unterschiedlichen Organisationsprinzipien gewählt und nach diesen agiert, was die Beidhändigkeit im Denken und Handeln von jedem einzelnen Organisationsmitglied erfordert. Die Beiträge von STELZMANN/REININGER (TELE HAASE) und FISCHERMANNS (IBO) zeigen, wie kontextuelle Beidhändigkeit in der Praxis funktionieren kann.

Exploitation und Exploration stehen also nicht im Widerspruch. Wie Stabilität und Wandel bedingen sie sogar einander. Sie befinden sich wie zwei Pole in einem permanenten Spannungsfeld, das es immer wieder neu auszutarieren gilt. Wenn einer von beiden wegfällt, dann gerät die dynamische Balance aus der kontinuierlichen Optimierung des Bestehenden sowie der Innovation in und am System ins Wanken – und das Unternehmen in eine gefährliche Schieflage. Dieses Verständnis ermöglicht es, dass in ein und demselben Unternehmen der Fokus auf der effizienzgetriebenen Vermeidung von Verschwendung, dem fehlerfreien Ablauf standardisierter Prozesse und der kontinuierlichen Optimierung von Prozessen liegt (Exploitation), während zur gleichen Zeit in Experimente und neue Geschäftsmodelle mit ungewissem Ausgang investiert wird und Recruiting betrieben wird, um neue Talente und Kompetenzen zu gewinnen. Diese vermeintliche Paradoxie bzw. diesen Widerspruch gilt es im unternehmerischen Alltag mitzudenken und auszuhalten.¹⁴⁷ Denn zum einen ist die Investition in Exploration im engeren Sinne nur möglich durch eine effiziente und wertschöpfende Exploitation. Zum anderen hängt die zukünftige Exploitation und damit die Aufrechterhaltung des Geschäftsbetriebs maßgeblich von der erfolgreichen Exploration ab, die in der Gegenwart betrieben wird.

So befindet sich der gesamte Bankensektor aktuell in einem schwierigen Spannungsfeld. Gerade traditionelle Banken, dazu zählen z. B. Privathäuser sowie Sparkassen und Volksbanken, haben mit der andauernden Niedrigzinsphase und den damit verbundenen Margenrückgängen zu kämpfen. Um diese Entwicklungen zu kompensieren, werden beispielsweise Aufgaben und Zuständigkeiten gebündelt, in Beratungs- und Kundencentern zentralisiert und das Filialnetz verschlankt. Damit einher gehen umfangreiche Vorhaben zur Prozessautomatisierung und Standardisierung. Gleichzeitig müssen sich die Banken aber auch neu erfinden und den aufstrebenden Fintechs Paroli bieten, wenn sie weiterhin für Kunden attraktiv bleiben wollen. So hat z. B. die SPARKASSE DÜSSELDORF die sogenannte „netzwerkstatt“ gegründet. In eigens dafür geschaffenen Räumen wird in cross-funktionalen Teams und mithilfe agiler Arbeitsmethoden offen und kreativ an innovativen Produktlösungen und Vertriebsansätzen gearbeitet.¹⁴⁸

Eine eindeutige und trennscharfe Unterscheidung der beiden Ambidextrieformen in der Praxis fällt oft nicht leicht. Das gilt insbesondere, wenn sich Unternehmen gerade in einer Transformation befinden. So lassen sich aktuell unzählige Organisationsvarianten und Spielarten beobachten, die auch als hybride Formen der Ambidextrie bezeichnet werden können, z. B. ausgeprägte agile Einheiten neben Einheiten mit klassisch-hierarchischen Rahmenstrukturen, innerhalb derer die Organisationsmitglieder mithilfe agiler Prozess- und Projektmanagementmethoden netzwerkartig interagieren (vgl. Kapitel 8.6). Es ist aber in den kommenden Jahren zu erwarten, dass der Anteil agiler Organisationselemente weiter zunehmen wird.¹⁴⁹

Für die BMW-Group-IT gilt seit November 2016 das Motto „100 % agile“. Zu diesem konsequenten Schritt hat sich die IT-Führung um CIO KLAUS STRAUB entschieden, nachdem er den Versuch des sogenannten bimodalen Modells der zwei Geschwindigkeiten – das Nebeneinander klassischer und agiler Ansätze – für gescheitert erklärt hatte. Das Ziel war es, bis Ende 2019 alle IT-Projekte auf agil umgestellt zu haben. Eine echte Herausforderung, bedeutete es doch, dass auch die Fachbereichsseite ihre Arbeitsweise ändern musste. Die klassische Projektorganisation und das bisherige Vorgehen in Projekten wurde durch eine agile Produktstruktur mit End-to-end-Verantwortung auf Teamebene ersetzt (vgl. Kapitel 4). IT und Fachbereiche arbeiten gemeinsam an Produkten. Die Konzern-IT erweitert damit den DevOps-Ansatz – die Verschmelzung von IT-Entwicklung (Development) und IT-Betrieb (Operations)¹⁵⁰ – und bezieht auch die Fachbereiche konsequent in die agile Arbeitsweise ein (sog. BizDevOps). CIO STRAUB verfolgt damit einen agilen Ansatz, der auf alle Unternehmensbereiche ausstrahlt, mit Auswirkungen auf die gesamte Konzernorganisation und -kultur.¹⁵¹

Die Transformationen bei BMW insgesamt lässt sich in ihren Ansätzen durchaus in den Bereich der strukturellen Ambidextrie einordnen – eine Phase, in der klassisch-hierarchische Organisationsformen und -elemente (in den meisten Bereichen der BMW Group) weiterhin neben agilen Formen der Zusammenarbeit (insb. in der BMW IT) bestehen, im weiteren Verlauf aber durchaus sukzessive in eine stärker kontextuelle Form der Ambidextrie übergehen können bzw. strukturelle und kontextuelle Beidhändigkeit mischen.¹⁵²

Das Festhalten an vermeintlich bewährten Mustern und das Verpuffen vieler mit dem Etikett der Agilität versehenen Initiativen verdeutlichen die Herausforderungen, mit denen viele Entscheider in der Praxis aktuell konfrontiert sind.¹⁵³ Die oben aufgeführten Praxisbeispiele sowie die weiteren Beispiele in Kapitel 8.6 zeigen, dass für eine synergetische und erfolgreiche Koexistenz unterschiedlicher organisatorischer Ansätze eine Beidhändigkeit vonnöten ist, die nicht nur in Form einer strukturellen oder kontextuellen Ambidextrie methodisch und organisatorisch auf Unternehmens- und Teamebene ansetzt, sondern das Individuum als kleinste organisatorische Einheit in den Mittelpunkt des Geschehens rückt, damit der bewusste Umgang mit Veränderung selbst zum Muster werden kann. Denn eine Methode, eine Organisationsform oder ein Betriebssystem ist immer nur so gut, wie es zur aktuell gelebten Kultur passt, der Summe an Interaktionen und Kommunikation, die in einem Unternehmen passieren. Es braucht also auch eine kulturelle Beidhändigkeit. Diese impliziert ein beidhändiges Mindset verinnerlicht zu haben, sich am Unternehmenserfolg auszurichten, Musterbrüche zu erkennen und undogmatisch, sowohl klassisch-hierarchisch als auch agil denken, kommunizieren und handeln zu können. Dass diese Kompetenz nicht das Privileg Einzelner bleiben oder auf sogenannte Kopfmonopole reduziert sein darf, liegt auf der Hand. Für eine erfolgreiche Beidhändigkeit im Unternehmen(sbereich) müssen viele der beteiligten Mitarbeiter beidhändig denken und handeln können. Dies ist die Voraussetzung für gelebte Ambidextrie.¹⁵⁴

Damit dies gelingt, sind der Wille und die Bereitschaft entscheidend, sich mit der eigenen Situation offen und ehrlich auseinanderzusetzen und andere auf dieser „Learning Journey“ mitzunehmen. FISCHERMANNS beschreibt in seinem Beitrag, wie eine solche Lernreise aussehen kann. Dabei kommt den Führungskräften eine wichtige Rolle zu. Zwar kann eigenverantwortliches Denken und Handeln weder delegiert noch angeordnet werden und letztlich entscheidet jeder Einzelne selbst über den Grad der Eigenverantwortung. Führungskräfte können und sollten den Mitarbeitern allerdings den Weg bereiten und sie ermutigen, mehr Verantwortung zu übernehmen, d. h. Selbstorganisation bzw. Selbstführung braucht Führung – Agile Führung (vgl. Kapitel 9 sowie die Beiträge von HARTMANN und SCHULLER/FUCKER).¹⁵⁵

Die vorgestellten Arten der Beidhändigkeit lassen sich folgendermaßen zusammenfassen:

Art der Beidhändigkeit	Erläuterung
Strukturelle Beidhändigkeit	Ich bin in der Lage, unterschiedliche Unternehmens- bzw. Aufgabenbereiche – je nach Anforderung – stärker klassisch-hierarchisch oder stärker agil zu gestalten.
Kontextuelle Beidhändigkeit	Ich bin in der Lage, innerhalb eines stärker klassisch-hierarchisch organisierten Unternehmens- bzw. Aufgabenbereichs – je nach situativem Kontext – auch agile(re) Organisationselemente zu nutzen – und umgekehrt.
Kulturelle Beidhändigkeit	Ich habe ein beidhändiges Mindset verinnerlicht, richte mich am Unternehmenserfolg aus, erkenne Musterbrüche und kann undogmatisch sowohl klassisch-hierarchisch als auch agil denken, kommunizieren und handeln.

Abb. 25: Arten der Beidhändigkeit

6 Agile Prozess- und Projektmethoden
6.1 Überblick

In den folgenden Kapitel 6 bis 8 werden verschiedene konkrete agile Prozess- und Strukturansätze vorgestellt, welche auf den in Kapitel 4 erläuterten Charakteristika agiler Organisation basieren. Wie in Kapitel 3.1 dargestellt, sollten – auf einer gegebenen Organisationsebene – i. d. R. zuerst die Prozesse und dann erst die Strukturen gestaltet werden (Primat der Prozesse), da die Prozesse die Unternehmensleistung generieren und es die Prozessergebnisse sind, die vom Kunden wirklich wahrgenommen werden. Dementsprechend starten wir in Kapitel 6 mit Methoden zur agilen Gestaltung von Prozessen bzw. – wenn sie einmaligen Charakter haben – Projekten.

Laut der Studie „Status Quo (Scaled) Agile 2019/20” nutzen 91 % der befragten 642 Unternehmen im deutsche Sprachraum agile Methoden.¹⁵⁶ Mit 84 % ist Scrum der meistgenutzte agile Ansatz. Ebenfalls eine große Bedeutung für die Mehrheit der Befragten hat Kanban. In der Regel erfolgt die Nutzung ergänzend zu klassischen Methoden, nur 20 % der Befragten bezeichnen sich als durchgängig agil. Die häufigsten Einsatzbereiche agiler Methoden sind Software-Entwicklung (75 %), IT-nahe Themen (52 %), Aktivitäten ohne besonderen IT-Bezug wie bspw. Marketing, Strategie- und Organisationsentwicklung (39 %) und die physische Produktentwicklung (19 %).

Die in der Studie am häufigsten genannten Ziele des Einsatzes agiler Methoden sind Optimierung der Produkteinführungszeit (56 %), Optimierung der Qualität (39 %), Reduzierung von Risiken (38 %) und Optimierung der Teammoral (35 %). 85 % der Anwender agiler Methoden berichten auch von realisierten Verbesserungen bei Ergebnissen und Effizienz. Der Zeitvergleich zu früheren Auflagen der Studie offenbart aber auch, dass die Einschätzung der Erfolgsquote agiler Ansätze in den letzten Jahren – mit der zunehmenden Verbreitung – insgesamt gesunken ist.

Im globalen „14th Annual State of Agile Report” geben 95 % der 1.000 befragten IT-Experten und Manager an, dass in ihrem Unternehmen agile Methoden genutzt werden – also ähnlich zum Befund der vorher genannten Studie für den deutschen Raum.¹⁵⁷ Auch international ist eindeutig Scrum die am häufigsten genutzte agile Methode. Auch die häufigsten Einsatzbereiche sind weltweit ähnlich. Laut der globalen Studie bescheinigen sich 16 % der befragten Unternehmen einen hohen agilen Reifegrad. Die Mehrheit nutzt zwar agile Praktiken, sieht sich diesbzgl. aber noch in einem Reifeprozess.

Im Hinblick auf die realisierten Erfolge berichten 70 % von einer erhöhten Anpassungsfähigkeit auf geänderte Prioritäten, jeweils 65 % erkennen eine höhere Projektsichtbarkeit und eine bessere Abstimmung von IT und Business. 60 % der Befragten haben die „Time to Market“ reduziert. Fast ebenso viele berichten von einer höheren Teammotivation (59 %) und Teamproduktivität (58 %). Reduzierte Kosten erkennen 26 %.

Im Folgenden werden die wichtigsten bzw. bekanntesten agilen Prozess- bzw. Projektmethoden vorgestellt.

6.2 Kanban

Eine sehr bekannte agile Prozessmethode ist Kanban.¹⁵⁸ Der Ansatz wurde ursprünglich 1947 von TAIICHI OHNO bei der TOYOTA MOTOR CORPORATION entwickelt (vgl. Kapitel 2.1 und 2.3). Ausgangspunkt der Überlegungen waren lange Durchlaufzeiten sowie hohe und damit kostenintensive Lagerbestände an Roh- und Halbfertigmaterialien. Als Ursache identifizierte OHNO den zentral an einer Stelle und bis ins kleinste Detail vorausgeplanten Materialfluss. Dieses Vorgehen passte nicht dazu, dass es in der Realität immer wieder zu Schwankungen bzw. Planabweichungen an verschiedenen Stellen im System kam. Die Fähigkeit, kurzfristig und an der Produktionsstelle „vor Ort“ auf solche Schwankungen zu reagieren, war sehr begrenzt. Dadurch kam es entweder zu zeitlichen Verzögerungen (lange Durchlaufzeiten) oder aber die mangelnde Flexibilität wurde durch Vorratshaltung kompensiert (kapitalintensive Lagerbestände).

Vor diesem Hintergrund suchte OHNO nach einem stärker dezentral gesteuerten Ansatz, der sich weniger an vorausgeplanten Mengen und mehr am tatsächlichen Verbrauch von Materialien am Bereitstell- und Verbrauchsort orientiert. Seine Kernidee bestand darin, den Materialfluss in der Produktion stärker nach dem Supermarkt-Prinzip zu organisieren. Das heißt, wenn sich eine Lücke im Regal abzeichnet, weil viele Verbraucher zugreifen, wird diese bemerkt und aufgefüllt. Im Produktionsbereich bedeutet dies, dass (erst bzw. schon) dann, wenn sich eine reale Lücke bzw. ein Engpass abzeichnet, der Auftrag zur Anlieferung bzw. Nachproduktion angestoßen wird – egal wie das ursprünglich einmal zentral angedacht und geplant war.

Auf Basis dieser Überlegung baute OHNO die Produktionsprozesssteuerung tiefgreifend um. An die Stelle einer sehr komplexen, verschachtelten und aufwendigen Zentralsteuerung treten dezentrale, selbstregelnde, autonome Regelkreise. Die primäre Steuerung wandert von der zentralen Planungseinheit zum letzten Glied der Produktionsprozesskette. Wenn dort der Lagerbestand eines bestimmten Materials einen definierten Mindestwert bzw. Meldebestand unterschreitet, wird dies an das vorgelagerte Glied der Produktionskette bzw. das zuständige Lager gemeldet. Hierfür werden Melde- bzw. Signalkarten verwendet, die dem Ansatz den Namen gegeben haben, denn „Kan“ bedeutet im Japanischen Signal und „Ban“ Karte. Bei Erhalt einer Signalkarte (Kanban) stellt das jeweilige Glied der Produktionskette entweder das Material bereit und/oder meldet seinerseits einen Bedarf an die vorgelagerte Prozessstufe. Dadurch wird ein regelmäßiger Fluss (Flow) im Prozess hergestellt und die Anpassungsfähigkeit wird erhöht. Durchlaufzeiten werden kürzer und Lagerbestände geringer.

Weil in diesem Ansatz die Materialien quasi vom Ende der Kette gezogen (pull) und nicht von einer Zentraleinheit durch den Produktionsprozess durchgedrückt (push) werden, wird von einem Pull-System bzw. einem Pull-Prinzip gesprochen (vgl. Kapitel 4.2). Dieses Prinzip ist letztlich der zentrale Kern von Kanban.

Ein wichtiges Element, damit dieses dezentrale Pull-System funktioniert, ist Transparenz. Die Prozessbeteiligten benötigen transparente Informationen über den aktuellen Stand, insb. mögliche Engpässe. Dies wird insbesondere über verschiedene Tafeln bzw. Kanban-Boards gewährleistet.

In der IT hat sich im Laufe der Zeit ein spezieller Kanban-Ansatz entwickelt, der meistens gemeint ist, wenn im agilen Umfeld von Kanban gesprochen wird. Wesentlicher Treiber der Entwicklung von Software-Kanban (bzw. Kanban für die IT) war DAVID ANDERSON.¹⁵⁹ Er benutzt Kanban-Boards, um den bestehenden Softwareentwicklungsprozess zu visualisieren. Auf den Tafeln wird dargestellt, wie die Aufgaben die verschiedenen Prozessschritte bzw. -phasen durchlaufen. Häufig werden dafür einfache Whiteboards mit verschiedenen Spalten für die Prozessschritte/ -phasen sowie Haftnotizen (Post-its) für die Aufgaben verwendet. Es gibt aber natürlich auch elektronische Varianten (wie z. B. Trello, Asana).

Im einfachsten Modell besteht ein Kanban-Board aus lediglich drei Spalten:

To Do/Zu erledigen: In der linken bzw. ersten Spalte stehen die noch nicht begonnenen, aber zu erledigenden Aufgaben.

In Progress/In Bearbeitung: Aufgaben, die sich in der Bearbeitung befinden, stehen in der mittleren Spalte.

Done/Fertig: Fertiggestellte Aufgaben stehen in der rechten bzw. letzten Spalte.

Diese einfachste Variante eines Kanban-Boards ist in vielen Bereichen ausreichend und wird in unterschiedlichen Anwendungsfeldern (z. B. im Rahmen von Scrum) benutzt. Bei komplexeren Prozessen ist es aber auch oft nötig bzw. sinnvoll, den „In Progress“-Bereich noch weiter aufzuspalten. Wie dies im Rahmen der Softwareentwicklung aussehen kann, zeigt Abbildung 26. Grundsätzlich sind Teams aber frei, die Prozessphasen bzw. Kanban-Spalten passend zum konkreten Prozess zu gestalten.

Abb. 26: Kanban-Board (beispielhaft)¹⁶⁰

Gemäß dem Pull-Prinzip ziehen sich die Teams bzw. die Teammitglieder aktiv neue Aufgaben aus der To-do-Spalte bzw. der vorgelagerten Prozessphase, wenn ihre vorherige Aufgabe abgeschlossen ist. Das heißt, die Aufgaben werden nicht von links nach rechts gedrückt, sondern von den für die Aufgabenerfüllung zuständigen Mitarbeitern „vor Ort“ immer eine Spalte weiter nach rechts gezogen.

Solche Kanban-Boards schaffen Transparenz über den Prozess und machen mögliche Probleme deutlich, die den Prozessfluss (Flow) behindern (könnten). Durch den Einsatz von Kanban-Boards wird der Prozess kontinuierlich beobachtet und wenn nötig optimiert. Zum Beispiel entstehen oft Flaschenhälse, an denen sich die Arbeit aufstaut. Dort muss dann eingegriffen werden, was beispielsweise durch das Umschichten von Ressourcen oder eine andere Aufteilung der Arbeit passieren kann. Auch kommt es immer mal wieder vor, dass einzelne Aufgaben aufgrund besonderer Umstände oder fehlender Ressourcen blockiert sind. Dies sollte im Kanban-Board visualisiert und damit transparent gemacht werden (vgl. Abbildung 26), was den Druck für eine zeitnahe Problemlösung erhöht. Somit ist ein Kanban-Board ein Prozessvisualisierungs-, -analyse- und -steuerungsinstrument. Die zentrale Steuerungsgröße ist die Vor- und Durchlaufzeit.

Ein wichtiges Element zur Steuerung sind dabei Work-in-Progress-Limits (WIP-Limits). Zur Unterstützung der Fokussierung (vgl. Kapitel 4.2) und zur Vermeidung bzw. frühzeitigen Erkennung von Engpässen sollte die Anzahl von Aufgaben in den einzelnen „In Bearbeitung“-Prozessphasen beschränkt werden. Im Beispiel in Abbildung 26 dürfen sich bspw. nur 4 Aufgaben in der Entwicklungs- und 3 Aufgaben in der Testphase befinden.

Ein Kanban-Board sollte möglichst an einem zentralen Ort stehen, der jederzeit für alle Teammitglieder zugänglich ist. Dadurch wird erreicht, dass immer alle Teammitglieder einen Überblick über den Prozessstatus haben. Dies regt dazu an, im Gesamtzusammenhang zu denken und fördert die Selbstorganisation.¹⁶¹

Bei der Arbeit mit den Kanban-Boards haben sich folgende drei Meetingformen etabliert:

Tägliche Status-Meetings: In kurzen (ca. 15 min) Meetings werden der Projektfortschritt, (mögliche) Probleme und Lösungswege besprochen. Längere Diskussionen werden bewusst ausgelagert.

Ursachenanalyse-Meetings: Bei größeren bzw. regelmäßigen Problemen (z. B. gestaute Aufgaben, unausgelastete Prozessteile, lange Warte- oder Durchlaufzeiten) wird diesen in Analysemeetings auf den Grund gegangen (Root Cause Analysis). Es geht darum, Fehlerursachen zu finden und zu beseitigen.

Operations Review Meetings: Unregelmäßige Treffen, um aus den gemachten Erfahrungen im Umgang mit dem Board, im Prozess und in der Zusammenarbeit zu lernen (vergleichbar zu Retrospektiven in anderen agilen Methoden).

Kanban eignet sich in Situationen, in denen es einen standardisierten, aber nicht voll automatisierten Prozess gibt, den unterschiedliche Aufgaben durchlaufen. Hier hilft der Ansatz dabei, Transparenz herzustellen, Selbstorganisation zu ermöglichen, Probleme frühzeitig zu erkennen und den Prozess kontinuierlich zu verbessern. In diesem Buch beschreibt KALNIK anhand ihres Beitrags, wie wichtig der tägliche Abgleich und die Visualisierung der Themen ist, um als Team zusammenzuarbeiten. Die kontinuierliche Verbesserung ist in der wöchentlichen Team-Runde fest verankert.

Die Kanban-Methode setzt tendenziell an gegebenen Prozessen an, die mehrmals durchlaufen werden, und versucht diese (immer weiter) zu optimieren (im Sinne einer kontinuierlichen Verbesserung). Bei projektartigen Einzelprozessen bzw. der Entwicklung von Neuem passen andere agile Ansätze besser – bspw. Scrum.

6.3 Scrum

Scrum ist der bekannteste agile Ansatz.¹⁶² Hierbei handelt es sich um ein Vorgehensrahmen bzw. -gerüst (Managementframework). Der Ansatz stammt zwar ursprünglich aus der Softwareentwicklung, kann aber auch für andere, projektartige Prozesse, wie bspw. Produktentwicklungen (z. B. im Maschinenbau) bzw. kontinuierliche Produkt- (z. B. von Flughäfen) oder Serviceverbesserungen (z. B. von Dienstleistungsunternehmen) angewendet werden.

Das ab 1993 von KEN SCHWABER und JEFF SUTHERLAND entwickelte und insb. auf den Kerngedanken von Lean Thinking (vgl. Kapitel 2.3) und den Arbeiten von TAKEUCHI/NONAKA und DEGRACE/HULET STAHL basierende Framework¹⁶³ baut auf der Erkenntnis auf, dass es in dynamischen und komplexen Umfeldern – wie es in der Softwareentwicklung schon länger üblich ist – nicht zu den besten Lösungen führt, wenn sich wenige Experten eine (vermeintlich) optimale Lösung für ihre Kunden überlegen, einen fixen Plan aufstellen und dann über einen detaillierten, langwierigen Prozess, der hierarchisch gesteuert wird, (vermeintlich) perfekt – inkl. perfekter Dokumentation – umsetzen (lassen). Denn in einem solchen Vorgehen ist die Lösung abhängig von der Genialität weniger Experten, die sich anmaßen, den wahren Kundenbedarf zu erkennen, obwohl die meisten Kunden diesen oft selbst nicht wirklich benennen können. Auch ändern sich Kundenanforderungen und -erwartungen im Zeitablauf – gerade vor dem Hintergrund exponentieller Technologieentwicklungen. Und die hierarchische Steuerung behindert flexibles Reagieren und das Einbringen neuer Ideen im Prozess. Nicht zuletzt ist es in vielen Fällen vermessen, im ersten Versuch direkt eine „perfekte“ Lösung erstellen zu wollen. Oft zeigt sich erst am Markt, was funktioniert bzw. wirklich vom Kunden angenommen wird.¹⁶⁴

Eine zentrale Kernidee von Scrum ist es daher, Unklarheit und Komplexität durch Zwischenergebnisse (sogenannte Produktinkremente) zu beseitigen, zu denen immer wieder Feedback eingeholt wird. Auf Basis der Zwischenergebnisse bzw. der Rückmeldungen dazu lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungs- und Planungsphase. Die Entwicklung läuft dann iterativ in kleinen Schritten (sogenannte Sprints), bei denen es nicht schlimm ist, wenn auch mal ein Versuch zum Irrtum und nicht (direkt) zur Lösung führt.

Durch das wiederkehrende Feedback von Produktverantwortlichen (sogenannte Product Owner), Auftraggebern und Nutzern wird eine ständige Ausrichtung an den wirklichen Kundenbedürfnissen erreicht. Dadurch ist man ständig am Lernen und Optimieren (vgl. Kapitel 4.2).

Ein weiterer Kernaspekt ist es, ein cross-funktional, mit ausgewiesenen Experten besetztes Team eigenständig und selbstorganisiert an der Umsetzung arbeiten zu lassen. Dies basiert auf der Überzeugung, dass in komplexen Umweltsituationen durch eine solche Konstellation und bei möglichst viel operativer Abstimmung „an der Basis“ i. d. R. bessere Ergebnisse entstehen als bei der (Vorab- und Gesamt-) Planung durch eine übergeordnete Managementinstanz.

Das Scrum-Framework besteht aus einem Prozessmodell mit standardisierten Phasen, Meetings und Artefakten sowie spezifischen Rollen. Im Folgenden soll zunächst das (etwas vereinfachte) Prozessmodell vorgestellt werden (vgl. Abbildung 27).

Abb. 27: Prozessmodell von Scrum¹⁶⁵

Ausgangspunkt ist eine Produktidee bzw. Produktvision, d. h. eine grobe Vorstellung über das angestrebte Ergebnis.

Hieraus werden Produktfunktionalitäten abgeleitet, die beschreiben, was das Produkt dem Nutzer bietet – dies erfolgt häufig in der Form von kleinen „Geschichten“ über den Einsatz durch die Benutzer (User Stories¹⁶⁶).

Die priorisierten Funktionalitäten/User Stories – ergänzt um eine, im Prozess immer wieder aktualisierte Schätzung des Umsetzungsaufwands (in einem Estimation Meeting) – bilden zusammen das Product Backlog. Im Gegensatz zu einem fix aufgestellten Plan/Konzept beim klassischen „Wasserfallmodell“, ändert sich das Product Backlog kontinuierlich durch die im Prozess neu gewonnenen Erkenntnisse (Product Backlog Refinement).

Die iterative Umsetzung der einzelnen Funktionalitäten/User Stories erfolgt in Form von Sprints. Dies sind Phasen von typischerweise 2-3 Wochen, in denen störungsfrei (d. h. innerhalb dieser Zeit ändern sich die Vorgaben nicht) einzelne Elemente/Funktionalitäten aus dem Product Backlog umgesetzt und vorzeig-/nutzbare (man spricht von „usable“ oder auch „potentially shippable“) Produktteile bzw. -inkremente entwickelt werden.

Am Anfang eines jeden Sprints finden zwei Planungen statt. Im Sprint Planning 1 wird festgelegt, welche Elemente des Product Backlogs bearbeitet werden (Selected Product Backlog). Im Sprint Planning 2 geht es um die Frage, wie diese Elemente umgesetzt werden sollen. Es entsteht eine Liste von Aufgaben für den anstehenden Sprint (Sprint Backlog).

Im Sprint wird meist auch mit Prinzipien und Praktiken aus Kanban gearbeitet – u. a. Aufgabenboards (Task Boards, auf denen der Umsetzungsstatus der Elemente des Sprint Backlogs dargestellt sind), dem Pull-Prinzip und WiP-Limits.

In einem kurzen, täglichen Meeting (Daily Scrum oder auch Daily Standup Meeting) stimmen die Teammitglieder ihre Aufgaben untereinander ab. Das Meeting soll kurzgehalten werden (typ. 15 min, immer zur gleichen Zeit) und findet deshalb im Stehen statt. Ziel ist es, den aktuellen Stand auszutauschen, Abhängigkeiten festzustellen und von anderen Teilnehmern Hinweise/Ideen zum Lösen von Problemen zu bekommen.

Am Ende jedes Sprints steht ein fertiggestelltes Produktinkrement (mit den umgesetzten Funktionalitäten/User Stories). Über eine sogenannte „Definition of Done“ wird definiert, was konkret unter „fertig“ verstanden wird.

Am Ende des Sprints stellt das Team das fertiggestellte Produktinkrement vor – mindestens dem Product Owner, am besten auch den Kunden und/oder Nutzern –, um Feedback zum Produkt einzuholen (Sprint Review).

Außerdem gibt es nach jedem Sprint eine Sprint Retrospektive, in der das Team die Zusammenarbeit reflektiert und überlegt, wie man diese weiter optimieren kann. Während es also beim Review um das Produkt geht (Fokus: Effektivität), geht es hier um die Arbeitsprozesse (Fokus: Effizienz).

Auf Basis der Erkenntnisse aus Sprint und Review kann das Product Backlog aktualisiert und der nächste Sprint geplant werden, d. h. die nächste Iteration startet.

Der Scrum-Prozess endet typischerweise dann, wenn die vorgegebene Zeit bzw. das vorgegebene Budget verbraucht ist. Dann sind zwar nicht zwingend alle Funktionalitäten/User Stories aus dem Product Backlog umgesetzt, aber die wichtigsten. Hier unterscheidet sich die Scrum-Logik von der klassischen Planungslogik, bei der der Scope fixiert ist, aber Zeit und Budget regelmäßig „aus dem Ruder“ laufen.¹⁶⁷

Parallel zu diesem operativen Prozess wird ein sogenanntes Impediment Backlog geführt. Dies ist eine Liste aller Hindernisse, die das Team bei der Arbeit stören und (vom Scrum Master verantwortet) aus dem Weg geräumt werden sollten, um eine effektive und effiziente Arbeit zu ermöglichen.

Innerhalb dieses Prozessmodells agieren die folgenden Rollen (wobei nur die ersten drei Rollen zum Kern des Frameworks gehören):

Der Product Owner ist für das zu erstellende Ergebnis/Produkt und die finanzielle Seite des Projekts verantwortlich. Er lenkt die Produktentwicklung durch eine möglichst greifbare Produktvision sowie klar formulierte Rahmenbedingungen. Er ist verantwortlich für die kontinuierliche Aktualisierung des Produkt Backlogs und arbeitet täglich mit dem Entwicklungsteam.

Das Entwicklungsteam besteht aus den, i. d. R. cross-funktional/multi-disziplinär zusammengesetzten, Personen (typischerweise 5-9), die für die Entwicklung des Produkts erforderlich sind. Es steuert seine Arbeitsmenge selbst und trägt die Verantwortung für die professionelle Produkterstellung.

Der Scrum Master kümmert sich um die (kontinuierliche Erhöhung der) Produktivität des Teams. Auch wenn er nicht weisungsbefugt ist, sorgt er dafür, dass der Scrum-Prozess eingehalten wird (Prozessverantwortung) und kontinuierliches Lernen und Verbessern stattfindet. Außerdem kümmert er sich um das Lösen von Problemen (Impediments), die das Scrum-Team vom Arbeiten abhalten. Viele dieser Impediments resultieren aus Abhängigkeiten von anderen Organisationseinheiten oder Externen.

Product Owner, Entwicklungsteam und Scrum Master bilden zusammen das Scrum-Team.

Diejenigen Personen, die die Ressourcen (insb. die beteiligten Personen) zur Verfügung stellen und generelle Rahmenbedingungen setzen, werden in der Scrum-Terminologie als „das Management“ bezeichnet. Der Scrum Master geht auf das Management zu, um gemeinsam die identifizierten Probleme (Impediments) zu lösen.

Der (interne oder externe) Kunde soll das Ergebnis des Projekts kaufen. Er ist somit der Finanzier bzw. Budgetverantwortliche.

Der User (Nutzer) verwendet das Produkt bzw. Projektergebnis. Damit seine Bedürfnisse möglichst gut erfüllt sind, sollte er in regelmäßigen Reviews die Zwischenergebnisse testen und Feedback geben.

Durch dieses Framework bzw. Rahmenmodell schafft Scrum ein definiertes, verlässliches Gerüst, das Sicherheit und Orientierung bietet. Man macht nicht einfach irgendwas, sondern das ganze hat Struktur bzw. ist organisiert. Aber Scrum macht ganz bewusst keine inhaltlichen Vorgaben, d. h. es wird z. B. gerade nicht festgelegt, wie die eigentliche Produktentwicklung abläuft und was für ein Produkt entwickelt wird. Es wird „nur“ definiert, wie die Arbeitsteilung und Koordination im Team erfolgt. Das heißt, der Metaprozess ist geregelt und standardisiert. Innerhalb dieses Standardprozessmodells hat das Team alle Freiheiten („freedom within a frame“, vgl. Kapitel 4.5). Dementsprechend eignet sich Scrum dann, wenn es keinen klaren inhaltlichen Problemlösungsprozess gibt. In der Logik der Stacey-Matrix (vgl. Kapitel 2.4) also insbesondere bei komplexen Aufgaben. Dies ist der zentrale Unterschied zu Kanban.

Es ist auch durchaus möglich, einzelne Praktiken aus Scrum zu verwenden, um weitere Unternehmensprozesse agil zu gestalten oder diese mit klassischen Organisationselementen in einer hybriden Form zu kombinieren. Ein Beispiel liefert der in Kapitel 10 vorgestellte agile Strategieprozess der SAXONIA SYSTEMS AG. Und NAGEL/WILHELM beschreiben in ihrem Beitrag, wie sie in der NRW.BANK mithilfe der Stacey-Matrix Scrum als agiles Methodengerüst in eine hybride Projektstruktur integrierten.

Soll Scrum für größere Projekte bzw. Produktentwicklungen angewendet werden, muss der Ansatz skaliert werden. Wie dies möglich ist, zeigen die agilen Skalierungsframeworks in Kapitel 7, die wesentlich auf dem Scrum-Framework aufbauen.

6.4 Lean Startup

Der Grundgedanke von Scrum, nicht in einem großen Ansatz ein komplettes Produkt zu erstellen, sondern iterativ vorzugehen und dabei durch Feedback zu lernen, findet sich so auch bei der Lean-Startup-Methode.¹⁶⁸ Der Ansatz wurde von ERIC RIES entwickelt, der Anfang dieses Jahrtausends in die Gründung und den Aufbau mehrerer Start-ups involviert war, die „naturgemäß“ nicht alle erfolgreich waren. Insbesondere scheiterten einige daran, dass das Geld ausging, bevor das geplante Produkt fertig war und an den Markt gehen konnte.

Basierend auf dieser Erkenntnis und unter Nutzung einiger Ideen von STEVE BLANK und aus dem Lean-Management-Umfeld (vgl. Kapitel 2.3) entwickelte RIES ein schlankes Learning-by-Doing-Modell für Start-ups. Kernidee ist ein iteratives, inkrementelles Vorgehen, bei dem Hypothesen mit echten Kunden bzw. Nutzern getestet werden. Durch dieses Lernen vom bzw. am Markt wird Unsicherheit reduziert.

Der Kern des Modells ist der in Abbildung 28 dargestellte, sich wiederholende Zyklus aus Bauen, Messen und Lernen (Build, Measure, Learn). Auf Basis einer Geschäftsbzw. Produktidee wird bewusst nicht in einem großen Schritt ein „komplettes“ Geschäft bzw. Produkt gebaut, sondern es wird lediglich ein „minimal funktionsfähiges Produkt“ erstellt und am Markt mit echten Kunden bzw. Nutzern getestet. Auf Basis der am echten Markt gemessenen Befunde wird gelernt (validiertes Lernen), was funktioniert und – genauso wichtig – was nicht. Dieser Prozess wird ständig wiederholt, um das Geschäft bzw. Produkt kontinuierlich zu verbessern. Dadurch soll gesichert werden, dass ein Geschäft bzw. Produkt entwickelt wird, das auch wirklich vom Markt angenommen wird. Nicht tragfähige Ideen bekommen frühzeitig – bevor große Summen investiert sind – die Rückmeldung, dass hierfür kein Markt existiert.

Abb. 28: Prozessmodell von Lean Startup¹⁶⁹

Die Denklogik des hypothesengetriebenen Vorgehens ist genau andersherum, d. h. es sollte in der Logik von Abbildung 28 gegen den Uhrzeigersinn gedacht werden. Sinnvollerweise sollte bei der Konzeption damit gestartet werden, zu überlegen, was man lernen bzw. wissen will (Welche Hypothese über das Produkt bzw. den Markt soll geprüft werden?). Darauf aufbauend sollte ein passendes Test- bzw. Messmodell konzipiert werden (Wie kann man das testen und messen?) und auf der Basis dann das dazu passende minimal funktionsfähige Produkt (Was muss das Produkt bieten/können, damit der Test möglich ist?) gebaut werden.

Ein schönes Beispiel liefert der US-amerikanische Online-Modehändler ZAPPOS.¹⁷⁰ Das 1999 von NICK SWINMURN gegründete Unternehmen basierte auf der damals keineswegs sicheren Annahme, dass es möglich ist, Schuhe gewinnbringend über das Internet zu verkaufen. Während SWINMURN an diese Idee glaubte, bezweifelten dies viele seiner Gesprächspartner und potenziellen Investoren, weil Schuhe und Füße unterschiedlich ausfallen, verschiedene Modelle anprobiert werden müssten und daher entweder erst gar nicht online bestellt oder zu extrem großen Rücksendungen (und damit hohen Retourkosten) führen würden.

Aufgrund dieser großen Gefahr bzw. Unsicherheit wäre es extrem risikoreich gewesen, eine komplette, voll funktionsfähige Website mit einer großen Datenbank mit Schuhen zu erstellen sowie ggf. sogar ein Sortiment an Schuhen zu kaufen und dann erst festzustellen, ob die Idee überhaupt zu einem tragfähigen Geschäft führt. Im Negativfall wäre viel Zeit und Geld verschwendet.

Um herauszufinden, ob Schuhe überhaupt online gekauft werden und wie hoch die Rücksendungen tatsächlich sind, wandte sich SWINMURN stattdessen an örtliche Schuhgeschäfte, fotografierte deren Bestände, stellte die Bilder nur auf einer sehr einfach gehaltenen Website online, kaufte die Schuhe nach dem Verkauf zum vollen Preis in den Geschäften und versandte sie dann direkt an die Kunden. Die Rückmeldungen vom echten Markt zeigten, dass die Kundennachfrage vorhanden und die Rücksendungen geringer als befürchtet bzw. handhabbar waren.

Im Beispiel von ZAPPOS ist die einfache Website mit Fotos von Schuhen und der Möglichkeit diese zu bestellen das „minimal funktionsfähige Produkt“ (MFP) – im Englischen Minimal Viable Product (MVP) – um die beiden zentralen Hypothesen (bzgl. Bestellungen und Retouren) zu testen. Es bietet alle notwendigen Kernfunktionen, verzichtet aber auf jedweden ergänzenden „Schnick-Schnack“. Dadurch wird zum einen der Aufwand und Ressourcenbedarf minimal gehalten und zum anderen wird gesichert, dass der Erfolg bzw. Misserfolg auch tatsächlich auf dem untersuchten Element und nicht irgendeiner ergänzenden Funktion oder einem tollen Design basiert. In weiteren Iterationen können dann zusätzliche Funktionalitäten ergänzt und wiederum getestet werden.

Oft wird vor einem wirklichen MVP auch schon mit Prototypes bzw. Mockups, d. h. Attrappen, die das Design bzw. (Teil-)Funktionen eines Produktes demonstrieren, gearbeitet, um mit minimalen Kosten einen ersten Markteindruck zu bekommen. In diesem Fall wird das Produkt dann lediglich auf Papier den Kunden bzw. Nutzern vorgeführt. Dies liefert schonmal erste Rückmeldungen, hat aber das Problem, dass es oft Unterschiede zwischen dem gibt, was Menschen in Interviews als interessant bezeichnen und dem Verhalten, wenn tatsächlich Geld dafür zu bezahlen ist.

Die Lean-Startup-Methode eignet sich natürlich insbesondere für Start-ups. Zum einen verfügen sie typischerweise über sehr beschränkte finanzielle Mittel und zum anderen operieren sie in einem Umfeld großer Ungewissheit. Kundensegment und Produkt sind zwar z. T. definiert, basieren aber oft auf Vermutungen. Bei etablierten Unternehmen ist zwar im Regelfall mehr Geld vorhanden und es ist finanziell eher möglich, direkt ein komplettes Produkt bzw. Geschäftsmodell zu bauen. Aber auch sie bewegen sich bei Innovationen, insbesondere in einer VUCA-Umwelt, in großer Ungewissheit. Um diese Ungewissheit zu reduzieren und nicht am Markt und den Kunden vorbei zu entwickeln, empfiehlt sich auch hier die Anwendung der Lean-Startup-Methode bzw. -Denke.

Der Marktlaunch eines MVPs ermöglicht das Überprüfen von grundlegenden Geschäftshypothesen und Annahmen am wirklichen Markt. So können frühzeitig die tatsächlichen Wünsche und Bedürfnisse der Zielgruppe ermittelt werden. Eine frühe Marktrückmeldung durch zahlende Kunden ermöglicht schnelle Anpassungen und erlaubt es, neue Richtungen einzuschlagen. Durch validiertes Lernen ist es möglich, Entscheidungen anhand von Daten zu treffen, anstatt auf Vermutungen zu bauen.

Die zentralen Grundideen von Lean Startup zeigen einige Gemeinsamkeiten zu Scrum. In beiden Fällen geht es um iteratives Lernen und Optimieren durch regelmäßiges Feedback. Während Scrum aber eher auf die Entwicklung eines Produktes fokussiert, zielt Lean Startup auf die Entwicklung von Geschäft(smodell)en.

6.5 Design Thinking

Gedanklich vor Scrum und Lean Startup bewegt sich Design Thinking. Es handelt sich um eine agile Methode zum systematischen Erfinden und Innovieren.¹⁷¹ Der Ansatz orientiert sich an der Arbeit von Designern, was den Namen erklärt. Design steht dabei aber weniger für schönes Aussehen, sondern mehr für die dahinterliegenden Funktionalitäten.

Der Design-Thinking-Prozess besteht, wie in Abbildung 29 dargestellt, aus sechs klar definierten, aber nicht streng linear ablaufenden Prozessschritten. Dabei sind die ersten drei Schritte (Verstehen, Beobachten und Sichtweise definieren) darauf ausgerichtet, zunächst einmal die Situation, Position und Motivation der Anwender genau zu verstehen. Diesem Aspekt wird bewusst ein großer Raum gegeben. Hier zeigen sich deutliche Unterschiede zu Scrum und Lean Startup.

Im zweiten Prozessteil (Ideen finden, Prototyp(en) entwickeln und testen) zeigen sich dagegen etliche Parallelitäten zu Scrum und Lean Startup. Es sollen Lösungsideen gefunden sowie passende Prototypen entwickelt und getestet werden, um daraus zu lernen. Auch Design Thinking folgt einem iterativen Vorgehen, d. h. man kann und soll jederzeit ein oder mehrere Schritte vor- und zurückgehen, bis das Ergebnis stimmig ist.

Abb. 29: Prozessmodell von Design Thinking¹⁷²

Der in Abbildung 29 dargestellte, an der D-SCHOOL des HASSO-PLATTNER-INSTITUTS in Stanford und Potsdam angewandte Prozess lässt sich folgendermaßen erläutern:

1. Kontext verstehen: Das Team versucht zunächst alle relevanten Dimensionen der Problemstellung zu verstehen (Analyse vorhandener Literatur und vergleichbarer Projekte), um Wissenslücken zu erkennen und Themen für die qualitative Recherche zu definieren.

2. Menschen beobachten: Das Team wendet qualitative Forschungsmethoden (z. T. in kreativer Art und Weise) an. Durch teilnehmende Beobachtungen und Interviews sollen die Vorstellungs- und Lebenswelten, Nutzungskontexte, Erwartungen und Erfahrungen von potenziellen Nutzern analysiert und Verhaltensmuster, Emotionen und Bedürfnisse erkannt werden (oft wird dabei mit „Customer Journey“-Modellen gearbeitet).

3. Sichtweise definieren: Das Team führt die Ergebnisse aus den vorherigen rechercheorientierten Prozessschritten zusammen, fokussiert sich auf die vielversprechendsten Erkenntnisse und entscheidet, in welche Richtung und für welche Nutzergruppen (typischerweise in Form von „Personas“) es Lösungen entwickeln möchte.

4. Ideen finden: Das Team generiert mithilfe verschiedener Kreativmethoden möglichst zahlreiche Ideen (Mix aus stiller, konzentrierter Einzelarbeit und energetischer Teamarbeit) und gruppiert diese (u. a. nach Umsetzbarkeit und Nutzenpotenzial).

5. Prototyp(en) entwickeln: Das Team arbeitet ausgewählte Ideen mithilfe unterschiedlicher Medien und Materialien (z. B. Kunststoffverpackungen, Pappkartons, Legosteine etc.) konkreter aus. Ziel der oft multimedialen Prototypen ist es, einerseits eine konkrete Vorstellung vom finalen Ergebnis zu entwickeln und andererseits die Ideen schnell und (be)greifbar an Dritte vermitteln zu können.

6. Prototyp(en) testen: Anders als bei traditionellen Entwicklungsprozessen wird jeder Prototyp in iterativen Zyklen mit (aktuellen und) potenziellen Nutzern getestet. Basierend auf den Erkenntnissen entscheidet das Team, ob es noch einmal im Prozess zurückgehen möchte, um den Prototypen zu verbessern. Durch jede Iterationsschleife werden die Prototypen realistischer, da sie mit steigender Detailgenauigkeit konkreter und funktionaler werden.

Der Kern von Design Thinking ist die konsequente Orientierung und Ausrichtung am Kundennutzen. Die Methode stellt heraus, dass es wichtig ist, bei den Bedürfnissen und Motivationen der Menschen anzusetzen, die „am Ende” die Anwender und Nutzer der jeweiligen Ergebnisse sind. Der Innovations- und Entwicklungsprozess muss sich auf diese Nutzer – und deren Bedürfnisse – ausrichten, dafür ist es wichtig sie umfassend zu beobachten und sich in sie hinein zu versetzen.

Ein Kernaspekt von Design Thinking ist auch das immer wieder ausweiten und verengen des Betrachtungshorizonts, sog. Divergieren und Konvergieren (vgl. Abbildung 29). Im Prozess wechseln ganz bewusst Phasen ab, in denen es einerseits darum geht, weit und breit zu denken und möglichst viele Eindrücke zu bekommen und Ideen zu entwickeln, und andererseits, die vielfältigen Ansätze und Ideen auf ein konkretes gemeinsames Verständnis bzw. einen Prototyp zu fokussieren.

Neben dem Prozess sind selbstorganisierte, interdisziplinäre Teams und flexible Arbeitsumgebungen zwei weitere Kernelemente des Design-Thinking-Ansatzes:

Wie bei Scrum sollte auch bei Design Thinking in selbstorganisierten, interdisziplinären Teams gearbeitet werden. Der Ansatz basiert auf der Annahme, dass Probleme besser gelöst werden können, wenn Menschen unterschiedlicher Disziplinen und mit verschiedenen Kompetenzen in einem die Kreativität fördernden Umfeld zusammenarbeiten.

Typisch für Design Thinking sind auch freie und flexible Arbeitsumgebungen, die (spontan) auf die Bedürfnisse des jeweiligen Projektes anpassbar sind. Dies impliziert bewegbare Möbel, ausreichend Platz für Whiteboards und Präsentationsflächen sowie Materialien zur prototypischen Gestaltung von Ideen.

Das Ergebnis von Design Thinking sind (visuelle und haptische) Prototypen und Modelle, keine fertigen Produkte. Dementsprechend lässt sich dieser agile Kreativitäts- und Innovationsansatz mit Lean Startup oder Scrum verbinden, wo es dann darum geht, das Produkt umzusetzen bzw. den Prototyp oder das (minimal funktionsfähige) Produkt am Markt zu testen bzw. das Produkt zu bauen.

6.6 Objectives & Key Results (OKR)

Bereits in den 1950ern hat PETER DRUCKER zur Koordination der arbeitsteiligen Aufgabenerfüllung in Unternehmen das Konzept des Management by Objectives (MbO) entwickelt.¹⁷³ Hierbei erfolgt die Koordination der von verschiedenen Menschen(gruppen) erbrachten Arbeit durch Ziele. Top-down abgeleitete, über verschiedene Hierarchieebenen hinweg kaskadierte und aufeinander abgestimmte Ziele sorgen für eine einheitliche Ausrichtung des gesamten Unternehmensgeschehens. Es ist aber – in definierten Grenzen – den die Aufgaben erfüllenden Menschen(gruppen) überlassen, wie sie diese Ziele erreichen (Selbstorganisation). Entscheidend ist, ob die Ziele erreicht werden. Daran werden Mitarbeiter und Manager gemessen.

Diese Steuerungslogik hat sich in den letzten Jahrzehnten im Management durchgesetzt und gilt auch heute nach wie vor. Über einige Jahre war dabei die Balanced Scorecard (BSC) von KAPLAN/NORTON der am weitesten verbreitete konkrete Umsetzungsansatz für ein MbO.¹⁷⁴ Der Ansatz – bzw. treffender die Art, wie er in vielen Unternehmen gelebt wird bzw. wurde –, hat sich aber im Zeitverlauf z. T. als relativ träge und kompliziert gezeigt. Auch sind die Ziele häufig zu stark von oben vorgegeben.

Deswegen hat sich im Laufe der Zeit ein agilerer und stärker partizipativer Ansatz zur Steuerung von Unternehmen(sbereichen) entwickelt – Objectives & Key Results (OKR).¹⁷⁵ Entwickelt wurde dieser ursprünglich ab 1971 durch ANDY GROVE bei INTEL. Weiterentwickelt wurde er dann vom ehemaligen INTEL-Praktikanten JOHN DOERR ab 1999 bei GOOGLE. In den letzten Jahren ist die Anzahl der Unternehmen, die mit diesem Ansatz arbeiten, kontinuierlich gewachsen.¹⁷⁶

Das zentrale OKR-Prozessmodell ist in der Abbildung 30 dargestellt. Ausgangspunkt sind die angestrebte Vision und die Mission bzw. der Purpose (vgl. Kapitel 4.4) des Unternehmens. Diese definieren die langfristige, normative Ausrichtung des Unternehmens. Sie geben allem Handeln im Unternehmen eine gemeinsame Richtung. Sie sollen kurz und knapp, aber für alle Beteiligten transparent und klar zum Ausdruck bringen, in welche generelle Richtung man gemeinsam gehen will.

Abb. 30: Prozessmodell von OKR¹⁷⁷

Aufgrund des langfristigen Horizonts und der oft abstrakten Formulierung von Vision und Mission, werden diese – wie auch im klassischen Management üblich – in mittelfristige Ziele (sogenannte „Mid-term Goals“ bzw. Moals) für das kommende Jahr überführt. Um die vorhandenen Kräfte sinnvoll zu bündeln, empfiehlt der OKR-Ansatz die Konzentration auf maximal drei bis vier Moals pro Jahr. Diese sollten die zentralen strategischen Themenfelder für das kommende Jahr abdecken. Moals müssen von ihrem Charakter her nicht zwingend messbar sein, sondern können auch als qualitative Ziele formuliert werden. Die Objectives & Key Results knüpfen an die Moals an.

Ein Objective (Ziel) ist ein umfassendes qualitatives Ziel, welches das Unternehmen bzw. den Unternehmensbereich in die gewünschte Richtung treiben soll (Wo will ich hin bzw. was möchte ich erreichen?). Je Organisationsebene werden nicht mehr als 4 Objectives empfohlen, um den Fokus nicht zu verlieren. Objectives haben bewusst nicht den Anspruch, dass aus ihnen direkt deutlich wird, was wirklich getan werden muss, denn dafür gibt es die Key Results.

Pro Objective sollten zwei bis maximal fünf Key Results (Schlüsselergebnisse) definiert werden. Dies sind quantitative Unterziele, die das „richtige“ Verhalten fördern sollen (Was muss ich tun, um das Ziel zu erreichen?) und anhand derer gemessen werden kann, ob ein Objective erreicht wurde oder nicht. Wie der Begriff „Results“ herausstellt, sollte es sich nicht um Aufgaben, To-Dos oder KPIs handeln, sondern Ergebniszustände. Diese sollten SMART – also spezifisch, messbar, ambitioniert, (aber) realisierbar und terminiert – und mit den Key Results von anderen Teams, mit denen es Berührungspunkte gibt, abgestimmt sein.

Abb. 31: Beispiel für OKR

Alle OKR eines Unternehmens(bereichs) werden in einer gemeinsamen OKR-Liste abgebildet. Dies geschieht jeweils zu Beginn eines OKR-Zyklus im OKR-Planning. Die OKR-Liste sollte für jeden greifbar und jederzeit einsehbar sein, denn sie dient auch dazu, mögliche Synergien oder Konflikte zwischen einzelnen OKR-Teams zu identifizieren.

Kernelement des OKR-Prozessmodells ist der 2- bis 4-monatige (meist quartalsweise) Zyklus aus OKR-Planning, -Weekly, -Review und -Retrospektive (vgl. Abbildung 30). Hier zeigt sich eine gewisse Ähnlichkeit zu Scrum (vgl. Kapitel 6.3).

Am Beginn des OKR-Zyklus steht das OKR-Planning. Dieses findet mindestens auf zwei Ebenen statt, zum einen für das gesamte Unternehmen und zum anderen auf Ebene der einzelnen Teams. Weitere Zwischenebenen sind in großen Unternehmen üblich (z. B. Geschäftsbereiche, Abteilungen, Niederlassungen). Optional können auch OKR für einzelne Mitarbeiter definiert werden. In der Planung werden die OKR für den kommenden Zyklus definiert, wobei die Unternehmens-OKR den Rahmen für die Team-OKR festlegen. Die Kernfrage des Team-OKR-Plannings sollte lauten: „Wie können wir als Team unser Unternehmen (bzw. unseren Bereich) unterstützen, seine OKR zu erreichen?“ In einem top-down und bottom-up getriebenen Abstimmungsprozess sollten Team-OKR festgelegt werden, die von dem Team selbst direkt beeinflusst werden können und auf die sich das Team gemeinsam committet. Diese stärkere Einbindung und Selbstbestimmung bei der Zielfestlegung ist ein wesentlicher Unterschied von OKR zu klassischen MbO-Ansätzen. Mögliche Unstimmigkeiten oder Doppelarbeiten zu anderen Teams sollen durch die transparente OKR-Liste offenkundig gemacht und typischerweise durch einen OKR-Master (ähnlich zum Scrum-Master) adressiert werden.

Zur wöchentlichen Synchronisation sind auf allen Ebenen kurze, ca. 15-minütige OKR-Weekly vorgesehen (ähnlich zum Daily-Scrum). Diese sollen die OKR im Bewusstsein und Fokus halten und allen ein Gefühl geben, wie der aktuelle Fortschritt ist. Dazu werden typischerweise folgende Kernfragen behandelt: 1. Wie ist der aktuelle Stand unserer OKR? 2. Gibt es weitere größere Themen außerhalb der OKR, die uns beschäftigen? 3. Gibt es Hindernisse, die uns bei der Zielerreichung stören?

Wie ein Sprint in Scrum, endet auch der OKR-Zyklus mit einer Review und einer Retrospektive – jeweils auf allen OKR-Ebenen, also mindestens Unternehmens- und Team-Level. Inhalt des OKR-Review ist der Grad der Zielerreichung und die dahinterliegenden Gründe bzw. Ursachen. Also inwieweit wurden die Objectives & Key Results erreicht, woran lag dies und was kann man daraus lernen? In der OKR-Retrospektive geht es dagegen um die Zusammenarbeit innerhalb der jeweiligen Ebene auf Basis des OKR-Ansatzes. Optimiert werden soll hier der Einsatz von und die Arbeit mit OKR.

Review und Retrospektive schließen den OKR-Zyklus ab bzw. bilden die Basis für den nächsten Zyklus, beginnend mit der Planung neuer OKR – oder, was explizit möglich ist, einem „Nachschärfen“ von Moals oder gar einem Hinterfragen von Vision und Mission/Purpose.

Im Gesamtbild zeigen sich somit etliche Parallelitäten zum Scrum-Prozess. Wer mit diesem vertraut ist, kann sich daher OKR zwar etwas vereinfacht, aber durchaus treffend als MbO-Ansatz mit Scrum-Prozesslogik vorstellen.

Es lässt sich somit festhalten, dass der Kern von OKR die klassische MbO-Denke ist. Es geht um die Koordination der Aktivitäten im Unternehmen über definierte und aufeinander abgestimmte Ziele. Wie bei anderen, klassischen Steuerungsansätzen (z. B. BSC) auch, werden Ziele definiert und die Zielerreichung wird gemessen, um auf dieser Basis „nachsteuern“ zu können. Im Detail zeigen sich jedoch einige wesentliche Unterschiede bei OKR. Zu nennen sind insbesondere die folgenden:

Die eigentlichen Ziele (Moals und Objectives) dürfen bewusst qualitativ sein und müssen nicht konkret spezifiziert und messbar sein – z. B. wenn eine genaue Zieldefinition aufgrund der VUCA-Umwelt nicht wirklich sinnvoll ist bzw. eine Scheingenauigkeit erzeugt. Die Mess- und damit Steuerbarkeit wird über die Key Results gewährleistet.

Die OKR sind zwar aus der Vision und Mission des Unternehmens abgeleitet, der Zielfestlegungsprozess läuft aber bewusst nicht rein top-down ab, sondern die Teammitglieder sind aufgefordert, eigene Aktivitäten und OKR für die Erreichung der übergeordneten Ziele zu definieren – als erste Orientierung eignet sich eine Aufteilung von ca. 50 % top-down und 50 % bottom-up. Diese höhere Partizipation soll für eine höhere Motivation sorgen. Es wird aber auch „anstrengender“ für die Mitarbeiter, weil mehr unternehmerisches Denken gefordert ist.

Durch die OKR-Liste sind alle OKR im gesamten Unternehmen transparent und von jedem einsehbar. Es soll keine Hidden Agenda geben, sondern jeder soll wissen, wer welche Ziele verfolgt. Damit wird auch das Big Picture für die einzelnen Mitarbeiter leichter ersichtlich.

Vor dem Hintergrund der VUCA-Umwelt wird der OKR-Zyklus bewusst kurzgehalten und umfasst nur ein paar Monate (meist ein Quartal). Dies ist zwar auch im BSC-Ansatz so angedacht bzw. umsetzbar, wird aber in der Praxis dann doch oft anders gelebt (insb. was die Veränderung der Ziele angeht).

Unter anderem durch den kurzen Zyklus ist es auch möglich, mehr Fokus auf ein paar wenige strategische Themen bzw. Ziele zu legen. So soll es gelingen, „mehr Druck auf den Kessel“ zu bekommen und Themen in kürzeren Zeitfenstern fertigzustellen.

Es geht nicht zwingend darum, alle Objectives vollständig zu erreichen. Sie sollen bewusst (über-)ambitioniert formuliert werden („stretch goals“). Es wird eine Zielerreichung von in der Regel 70-90 % angestrebt.

Der OKR-Ansatz soll für Ausrichtung und Motivation im Unternehmen sorgen, es ist aber ganz bewusst keine Mitarbeiterbewertungsmethode. Dementsprechend sollen Zielabweichungen nicht sanktioniert werden, sondern als Daten- und Anhaltspunkte zum Lernen und zur Verbesserung dienen – ein in der Praxis nicht immer ganz so leicht umzusetzender Anspruch.

OKR sollen dementsprechend auch nicht an ein Bonussystem gekoppelt sein, denn auch dies führt dazu, dass Ziele oft nicht ambitioniert genug definiert werden, sondern so, dass man sie auch erreicht. Ziel des Handelns soll es aber sein, das Bestmögliche für das Unternehmen zu erreichen, nicht eine irgendwann mal politisch-abgewogen definierte „(Ziel-)Latte zu überspringen“.

Im Unternehmen sollte es verantwortliche Personen geben (oft OKR-Master genannt), welche den Ansatz aktiv vorantreiben und für die Mitarbeiter als Coach, Experte, Prozesswächter, Facilitator und Change-Agent agieren.

Wichtig ist auch die Erkenntnis, dass der OKR-Ansatz einen Rahmen liefert, innerhalb dessen es einen großen Spiel- und Gestaltungsraum gibt. Es ist möglich und gewünscht, dass die Nutzer die Methode je nach konkreter Umwelt-, Unternehmens- und Teamsituation adaptieren und gestalten. Hier steht OKR also ganz im Sinne agilen Denkens.

Und wie bei den anderen hier vorgestellten agilen Ansätzen gilt auch für OKR, dass es nicht ausreicht, einfach das agile Tool einzuführen oder die darin enthaltenen Begriffe zu nutzen, sondern die Methode lebt davon, dass auch „wirklich so gedacht“ wird. Von daher ist es sicherlich nicht sinnvoll, die Mitarbeiter mit neuen Begriffen (wie Objectives und Key Results) zu verwirren und damit dann doch ein klassisches Ziel- und Kennzahlenmanagement zu betreiben. Auch besteht durchaus die Gefahr, aus OKR ein bürokratisches System aufzubauen. Im Start-up-Umfeld wird u. a. deshalb häufig statt mit einem OKR- oder sonstigem Kennzahlensystem einfach mit wenigen Leitkennzahlen („North-Star-Metriken“) gearbeitet. Andersherum ist es durchaus möglich, am im Unternehmen bereits etablierten Steuerungssystem anzusetzen (z. B. Balanced Scorecard), die Umsetzung und Anwendung aber agiler zu gestalten.

6.7 Gemeinsamkeiten, Unterschiede und Auswahlkriterien

Im Rahmen der Darstellung der ausgewählten agilen Methoden dürfte klar geworden sein, dass diese für verschiedene Einsatzzwecke geeignet sind – und daher auch durchaus sinnvoll kombiniert werden können.¹⁷⁸

Design Thinking eignet sich zum systematischen Erfinden und Innovieren. Die Methode setzt sehr früh an, wenn oft das zu lösende Problem noch gar nicht richtig klar ist. Hier betont Design Thinking, dass es wichtig ist, an den Bedürfnissen und Motivationen der Menschen anzusetzen, die „am Ende” die Anwender und Nutzer der jeweiligen Ergebnisse sind. Der Ansatz bietet ein entsprechendes Instrumentarium, um die Situation, Position und Motivation der Anwender zu verstehen. Das Ergebnis sind Produktideen sowie (visuelle und haptische) Prototypen und Modelle, keine fertigen Produkte.

Auf Basis einer Produktidee und ersten Prototypen bspw. aus einem Design-Thinking-Prozess kann über die Lean-Startup-Methode und den „Bauen, Messen und Lernen“-Zyklus ein tragfähiges Geschäftsmodell entwickelt werden, indem Hypothesen zum Geschäft und „minimal funktionsfähige Produkte“ mit echten Kunden bzw. Nutzern getestet werden. Auf Basis der am realen Markt gemessenen Befunde wird gelernt, was tatsächlich funktioniert und – genauso wichtig – was nicht.

Die wirkliche Produktentwicklung und kontinuierliche Produktweiterentwicklung kann dann über die Scrum-Methode erfolgen, indem in einem iterativen Prozess immer neue bzw. optimierte Produktinkremente entwickelt werden, und jeweils Feedback dazu eingeholt wird. So gelangt man Stück für Stück zu einem immer besser zu den tatsächlichen Kundenbedürfnissen passenden (fertigen) Produkt.

Zum agilen Agieren in einem gegebenen Prozess – bspw. bei der Produktion des vorher über die anderen dargestellten agilen Methoden entwickelten Produkts – eignet sich dann der Kanban-Ansatz. Dieser hilft dabei, „vor Ort“ auf Schwankungen bzw. Planabweichungen an verschiedenen Stellen im System zu reagieren. An die Stelle einer sehr komplexen, verschachtelten, aufwendigen Zentralsteuerung treten dezentrale, selbstregelnde, autonome Regelkreise. Die primäre Steuerung wandert von der zentralen Planungseinheit zum letzten Glied der Prozesskette (Pull-Prinzip). Dadurch wird eine kontinuierliche Verbesserung unterstützt.

Diese vier agilen Methoden kann man sich also in einer gewissen zeitlichen Logik vorstellen. Quer bzw. ergänzend dazu – aber auch in anderen Kontexten – bietet der „Objectives & Key Results“-Ansatz ein Steuerungskonzept. OKR liefert einen agilen „Management by Objectives“-Ansatz, der im Hinblick auf den Ablauf einige Parallelitäten zum Scrum-Prozess aufweist. Die Methode hilft dabei, verschiedene Aktivitäten in einem Unternehmen(sbereich) auf gemeinsame Ziele auszurichten, ohne dadurch zu viel an Freiraum und Flexibilität zu nehmen.

Natürlich gibt es neben den hier aufgeführten Prozess- und Projektmanagementansätzen noch viele weitere agile Methoden. Zu nennen sind bspw. der im Beitrag von MAURER in diesem Buch beschriebene Effectuation-Ansatz zur agilen Planung oder die im Beitrag von SCHULLER/FUCKER, HEILER/BORCK und TILLMANNS-ESTORF/​GROßE/GUMULA vorgestellten Entscheidungsansätze.¹⁷⁹ Darüber hinaus gibt es eine unüberschaubare Anzahl an kleinen Veränderungen im Arbeitsalltag (sogenannte Workhacks bzw. Nudges), die ein agileres Handeln anstoßen und dadurch letztlich ein agiles Denken unterstützen.¹⁸⁰

Neben diesen Unterschieden beim Einsatzzweck der verschiedenen Methoden zeigen sich auch im Anwendungsprozess ein paar Unterschiede bzw. unterschiedliche Schwerpunkte. Die folgende Abbildung 32 gibt einen groben (weil verkürzten) Eindruck über den jeweiligen Fokus bzw. zentrale Kernaspekte der Methoden.

Abb. 32: Fokus und gemeinsamer Kern verschiedener agiler Methoden (vereinfacht)¹⁸¹

Die Abbildung weist aber auch bewusst einen gemeinsamen Kern auf. Denn aus der Darstellung der Methoden sollte auch klargeworden sein, dass Kanban, Scrum, Lean Startup, Design Thinking und OKR in der Denke etliche Gemeinsamkeiten aufweisen. Alle diese agilen Ansätze teilen eine gemeinsame Denkweise und Handlungslogik (Agile Mindset, vgl. Kapitel 2.2). Folgende Kernelemente der agilen Organisation (vgl. Kapitel 4) tauchen in den Darstellungen der Methoden wiederholt auf:

Kundenzentrierung (intensive Auseinandersetzung, regelmäßiger Abgleich)

Iterativ-inkrementelles Vorgehen (Sprints, Hypothesen, Experimente, Prototypenbau)

Integrierte Feedback- und Lernschleifen (Reviews, Retrospektiven)

Fokussierung (Zeit- und Mengenbegrenzungen über Time-Boxing, Work-in-Progress-Limits)

Autonome, cross-funktionale Teams (mit intensiver Interaktion auf Augenhöhe)

Selbstorganisation mit Pull-Prinzip (in den Teams)

Transparenz (Boards, Backlogs)

Definierte Abstimmungs- und Entscheidungsprozesse (Dailys, Review Meetings).

Diese Grundgedanken gilt es ins Unternehmen zu holen – mit welchem Ansatz auch immer. Es ist sowohl möglich, nur einzelne Teilaspekte der Ansätze herauszugreifen, als auch die verschiedenen Ansätze miteinander zu kombinieren.

Alle vorgestellten Methoden liefern ein Set an Regeln zur Gestaltung des Vorgehens. Diese Regelungen bewegen sich aber ganz bewusst auf der Ebene des Metaprozesses. Das heißt, es wird zwar ein Prozess geliefert, wie man grundsätzlich vorgeht, aber nicht, was inhaltlich konkret gemacht wird. Hier lassen die Methoden einen großen Spiel- und Gestaltungsraum („freedom within a frame“). Es ist möglich und gewünscht, dass die Nutzer die Methode je nach konkreter Situation anpassen und gestalten. Der Metaprozess ist aber geregelt und standardisiert, dadurch bieten die Methoden Sicherheit und Orientierung.

Bei aller Freiheit in der Ausgestaltung sollte aber darauf geachtet werden, dass z. B. statt SCRUM und KANBAN nicht „MURCS“ oder „NABNAK“ gemacht wird (vgl. Beitrag von HÜBNER). Dies kann insbesondere dann passieren, wenn agile Anfänger gemäß des Shu-Ha-Ri-Prinzips (vgl. Exkursbox) nicht erstmal versuchen, die tiefere Logik hinter den Regeln zu verstehen („shu“), sondern sich einfach irgendwelche einzelnen Elemente/Praktiken aus dem Ansätzen rausziehen und diese zweckentfremdet und ohne Verständnis in einer „vergewaltigten“ Form in ihrem alten Umfeld anwenden. In dem Fall besteht die Gefahr, dass die agilen Methoden als solche – wegen der falschen Anwendung – in Verruf geraten und als Konsequenz Ablehnung und Blockaden in der Belegschaft gegen jede Form von „Agilität“ entstehen.

Bei der Anwendung agiler Methoden ist es empfehlenswert, dem Shu-Ha-Ri-Prinzip zu folgen.¹⁸² Hierbei handelt es sich um ein altes japanisches Konzept des Lernens, das aus dem Kampfsport kommt und den Weg bzw. die Lernstufen zur Meisterschaft beschreibt. Demnach ist es für Anfänger sinnvoll, zunächst die definierten und i. d. R. bewährten Regeln zu lernen und sich „sklavisch“ an die Vorgaben zu halten (shu). Beim Anwenden agiler Methoden (z. B. Scrum) bedeutet dies eine Einführung „by the books“, d. h. gemäß Lehr- bzw. Handbüchern. Erst beim Anwenden versteht der Schüler die tiefere Logik hinter den Regeln. Hat man die Regeln gelernt, die Hintergründe verstanden und deren korrekte Anwendung verinnerlicht, darf man diese verändern und auch brechen (ha). Bei Scrum könnte man bspw. von einem täglichen auf einen zwei-täglichen Rhythmus bei den Daily Standup Meetings wechseln oder das Scrum-Board anders aufsetzen. Ist der Schüler zum Meister geworden und hat das dahinterliegende Denken verinnerlicht (ri), darf er sich komplett von Regeln trennen bzw. neue Regeln aufstellen. Dann geht es gar nicht mehr darum, Scrum anzuwenden, sondern es geht „nur noch“ darum, agil zu Denken und zu Handeln. Es gilt dann nach BRUCE LEE: “Adapt what is useful, reject what is useless, and add what is specifically your own.”

Wichtig ist es, dass grundsätzlich immer vom konkreten Problem bzw. der spezifischen Aufgabe her gedacht und dann die dazu passende (klassische oder agile) Methode gewählt werden sollte. Auch bei agilen Methoden gilt das berühmte Bonmot, dass man nicht in allem einen Nagel sehen sollte, nur weil man gerade einen Hammer in der Hand – bzw. eine spezielle agile Methode erlernt – hat. Scrum z. B. passt zwar in vielen verschiedenen Situationen, aber sicher nicht in allen. Die vorgestellten agilen Methoden gehören aber in jedem Fall in einen zeitgemäßen Management-Werkzeugkoffer. Die Kunst besteht darin, in der konkreten Situation das passende Werkzeug auszuwählen und adäquat einzusetzen.