Unternehmensweite Business Agilität - jenseits von Scrum (Teil 1 - Entwurf)

Scrum steigert die Produktivität von Teams - skaliert aber schlecht.

Wie man Business Agilität und starke Unternehmen jenseits von Scrum entwickelt.

Agil jenseits von Scrum

Einführung

Es gibt eine angestammte Dichotomie in der Wirtschaft und im Projektmanagement. Sie bezieht sich auf die Frage, wie man Arbeitsaufgaben bestimmt und wie man sie erledigt. Während bestimmte Projektkontexte eine pedantische, spezialisierte Planung im Voraus erfordern, verlangen andere nach Kreativität und informeller Zusammenarbeit, um neue Ideen und Produkte erfolgreich auszubrüten.

Wissenschaftliches Management, 1911 von Frederick Winslow Taylor entwickelt, verfolgte die Idee, jede einzelne manuelle Bewegung zu optimieren, um höchste Effizienz zu erreichen. In den Schlachthöfen von Chicago konsequent umgesetzt, stellte diese “Erfindung des Schlachtplans” die Grundlage des modernen Projektmanagements. Da alle Rindfleischsorten die gleiche Struktur haben, können Sie im Voraus starre Standardarbeitsanweisungen für alle Mitarbeiter erstellen und umsetzen.

Diese Art der vorausschauenden Projektplanung befähigte die Menschen sogar dazu, alle Teile einer Rakete, die 1969 zum Mond schweben sollte, aufzulisten und zusammenzubauen. Solche “Stücklisten” (abgekürzt BOM und auch bekannt als “SAP Stücklisten”) sind nach wie vor das solide Rückgrat industrieller Fertigungsprozesse und der sie steuernden ERP-Programme (Enterprise Resource Planning Programme wie SAP). Und sie werden als Standard-Nummerierungssysteme verwendet, welche die gesamte Dokumentation eines Flugzeugs in einer hoch standardisierten Art und Weise umfassen (vgl. ATA iSpec, S1000D).

Dieser erfolgreichen Starrheit steht jedoch eine zunehmend offene, dezentralisierte, globalisierte und vernetzte Welt gegenüber, die oft als VUCA, als flüchtig, unsicher, chaotisch und mehrdeutig beschrieben wird - ein Begriff, der zuerst im militärischen Kontext zur Sprache kam. Die Führungsspitze verliert ihre Macht für die Kontrolle und die Befehlskette, während mehr und mehr erratische Netzwerkeinflüsse nach lokaler und kontextbezogener Führung und Reaktion verlangen. Unser Umfeld entfaltet sich von einfachem über komplexes bis hin zu kompliziertem und sogar chaotischem Verhalten.

Dave Snowden demonstriert mit dem Cynefin-Rahmenwerk, dass wir es versäumen, die Realität einzuholen, wenn unser Begriff von Realität zu eng gefasst ist. Die Realität könnte durch rigorose Methoden wie Sandkrüppel durch unsere Finger laufen. Der Grund dafür ist nach Ashby's Gesetz, dass man mehr Intelligenz (bzw. Vielfalt) braucht, um etwas zu kontrollieren, als ein Objekt, Projekt oder System, das man kontrollieren will.

In diesem Fall führen Abschätzung, Planung und Berichterstattung, die uns bisher rechtzeitig auf den richtigen Weg geführt haben, stattdessen zu Bürokratie und Sackgassen. Verstärkte Bemühungen durch Erhöhung der Rigidität verschärfen das Problem, wie John Boyd offenbarte mit abenteuerlichen Verweisen auf Goedel, Heisenberg und den 2. Hauptsatz der Thermodynamik, dass wir diesem Teufelskreis nicht entkommen können, weil er der Natur bzw. dem Menschen inhärent ist.

Wir können die Wirkung dieser Erkenntnisse insbesondere in großen Unternehmen sehen, deren kundenseitige Schnittstellen nur linear ansteigen, wo die interne Masse und die Last der internen Organisation exponentiell wächst (um Peter Drucker zu paraphrasieren), was zum Scheitern von Management-Rigidität und zentralisierten heroischen Führungsansätzen führt. Wir brauchen ausgefeiltere Rahmen für die Entscheidungsfindung (wie Cynefin) und müssen zusammenarbeiten und effektiv handeln.

Die menschliche Seite

Bereits 1960 betonte Douglas McGregor die “Menschliche Seite des Unternehmertums”: Menschen haben Ambitionen und engagieren sich leistungsstark in ihrer Arbeit, auch wenn sie nicht ständig überprüft werden. Wenn Sie Ihr Team unter strenge Kontrolle und strenge Beobachtung stellen, ohne die Befugnis zu handeln, könnten Sie sogar jeglichen gesunden Menschenverstand und die Arbeitsmoral untergraben. Der Vater des Qualitätsmanagements, Edward William Deming, bewies 1982 mit seinem legendären read beads experiment, wie dies die menschliche Moral und Motivation herabsetzen kann.

Das berühmte, Peter Drucker zugeschriebene Zitat, _“Wenn man es nicht messen kann, kann man es nicht verbessern”, wurde durch die Entwicklung von Linux unter starken Druck gesetzt. Linux wurde erstmals 1991 veröffentlicht ohne Planung von oben nach unten, ohne atoniale Organisation und ohne strikte Regierungsführung. Dies bewies, dass eine strenge, rigide Kontrolle und Messung keine Ursache oder Voraussetzung für Verbesserung und Wachstum ist. Stattdessen können Dinge um ein gegebenes Ziel herum entstehen, selbst in verteilten Teams, in denen die Teilnehmer einander sogar fremd sind!

Man könnte es umschreiben:

Dass man es messen kann, sorgt nicht dafür, dass es wächst.

Die Linux-Entwicklung gelang auch alleine, das heisst ohne eine Rechts-, eine Forschungs- & Entwicklungsabteilung und ohne eine Marketingabteilung: Kann es sein, dass wir sogar spezialisierte Abteilungen loswerden können, die Aktivitäten und Aufgaben hin und her schieben und relevante Informationen in Silos versenken?

Das agile Manifest

Das Agile Manifesto, das 2001 veröffentlicht wurde, brachte es auf den Punkt:

Projekte um motivierte Einzelpersonen herum aufbauen! Gemischte Teams statt Experten-Silos! Kommunikation über Dokumentation! Intervall ausgelöstes Feedback vom Kunden durch funktionsfähige Ergebnisse, statt langer Lieferlisten und verspäteter Montage der Teile!

Im selben Jahr 2006 wurde Scrum als agiles Framework veröffentlicht, das ursprünglich für die Produktentwicklung entwickelt wurde, Scrum.inc wurde 2006 gegründet und bietet Ausbildungs- und Zertifizierungsmöglichkeiten.

Der Siegeszug von Scrum war atemberaubend: Zuerst in seiner ursprünglichen Software-Domäne, dann auf dem Weg zum Projektmanagement im Allgemeinen. Es gibt wahrscheinlich kein seriöses Softwareunternehmen auf der Welt, das Scrum nicht einsetzt, oft in Kombination mit Kanban -Konzepten, und kein anderes Unternehmen, das sich bemüht, agiler zu werden. Gemischte, interfunktionale Teams, die in einem kurzen Herzschlag eng mit dem Kunden zusammenarbeiten, sind der Kern von Scrum und seine Stärke.

Agil funktioniert!

Obwohl Jeff und J.J. Sutherland übertreiben, wenn sie Scrum als “Die Kunst, die Arbeit in der Hälfte der Zeit doppelt so schnell zu erledigen” beschreiben. Erwiesen ist aber, dass Scrum die Produktivität im Durchschnitt um 7 bis 12% erhöht.

Aus derselben Studie geht jedoch hervor, dass Versuche, dies auf das gesamte Unternehmen auszuweiten, nur zu Produktivitätssteigerungen von 3 bis 5% führten. Ein Ergebnis, das sich leicht auf das geschärfte Bewusstsein reduzieren ließe, dass die Umsetzung eines solchen Rahmens nur vorübergehend ist.

Die Ansätze zur Skalierung von Scrum liefern jedoch nicht die gleich überzeugende Wirkung wie Scrum selbst.

Scrum skalieren?

An ausgearbeiteten Konzepten zur agilen Skalierung wie “SAFe” mangelt es nicht.

Schon ein erster Blick auf die grafische konzeptionelle Übersicht - mit all den Ebenen, Hierarchien und Rückkopplungsschleifen - erinnert genau an den konventionellen Organisationsaufwand und die bekannte Bürokratie in großen Unternehmen.

Aus der Sicht des Organisationsdesigns könnte man einfach eine traditionelle Portfolio- und Programm-Management-Ebene installieren und eine ähnliche Struktur erhalten. Oder der Ansatz will minimalistischer sein, wie “LeSS”, kann aber nicht die Frage beantworten, ob es wirklich sinnvoll ist, Scrum ausschließlich in einer Organisation einzusetzen:

  • Ist Scrum wirklich der Hammer für alle Nägel, die wir in jedem organisatorischen Kontext und in jeder Geschäftssituation haben?
  • Macht es in allen Kontexten wirklich Sinn, das Ende eines Sprints abzuwarten, bevor ein Artefakt freigegeben wird?
  • Wäre es nicht vorteilhaft, beim Bau eines Hauses und beim Gießen des Fundaments eine bestimmte vordefinierte Reihenfolge einzuhalten?
  • Wäre es nicht beruhigend, harte architektonische oder die Einhaltung von Vorschriften regulierende Anforderungen im Vorfeld zu berücksichtigen, anstatt zu riskieren, sie zu verzögern, weil sie für den Kunden nicht so leicht sichtbar gemacht werden können wie die Oberflächen?
  • Wie würde es sich anfühlen, wenn das Team seinen eigenen Weg der Zusammenarbeit und Kooperation wählen und auf ein tägliches und störendes Stand-up-Meeting verzichten könnte?
  • Wäre es nicht schön, den gesamten Ablauf im Auge zu haben, anstatt von einem Sprint zum nächsten zu schweben und das bisher Erreichte nur im Rückblick zu überprüfen?

«Agil» durch Tools?

Viele Organisationen scheuen sich davor, Agilität ernsthaft einzuführen und setzen einfach coole Collaboration-Software ein, um auf der “agilen Welle” zu reiten – ohne die Prozesse und Interaktionen ernsthaft anzupassen.

Dadurch wurde das Produktportfolio von Unternehmen wie Atlassian (Hersteller von Jira, Confluence, Trello, Bitbucket usw.) angekurbelt und die Vorteile der Agilität indirekt in vielen Kontexten genutzt, die sie sonst nicht hätten entdecken können. Trotz dieser Vorteile biegen diese Werkzeuge die Arbeitsorganisation nur oberflächlich zurecht, so dass diese den gegebenen kontextuellen Anforderungen nur zufällig voll gerecht werden kann, wenn überhaupt.

Viele Unternehmen verwechselten Agilität auch mit der “Einführung dieser ausgefallenen Softwarepakete an jedem Arbeitsplatz” und stellten das Konzept auf den Kopf, während sie an etablierten Richtlinien festhielten. Dasselbe gilt, wenn Teams und Mitarbeiter gezwungen sind, ihre Kommunikationskanäle konsequent zu ändern und alternative Software-Werkzeuge einzusetzen, anstatt optimierte Arbeitsweisen mit den betroffenen Teammitgliedern zu etablieren.

Martin Fowler, ein Experte für agile Softwareentwicklung, hat dazu den Ausdruck «Agile in name only» (AINO) geprägt, eine andere treffende Bezeichnung ist «Lipstick agile».

Wie können wir nachhaltige Geschäftsflexibilität in Unternehmen einführen?

Wie Paul Graham anmerkt, wenn man ein kreativer Macher ist, der tief in seinen Konzepten und Details gräbt, welche längere Zeiträume in Anspruch nehmen, kann ein einzelnes Meeting den ganzen Tag beeinflussen, auch wenn es sich um ein agiles Stand-up handelt. Auf die gleiche Weise macht ein lästiges “agiles” Softwarepaket Ihr Team nicht unbedingt produktiv, auch wenn es oft in agilen Kontexten eingesetzt wird.

Wie können wir diese lästigen Einschränkungen der Agilität und des Scrum in Unternehmensumgebungen überwinden? Wie können wir mehrere Teams produktiv machen, jedes mit seinem eigenen Profil und seinen spezifischen Zielen und Kundenanforderungen? Wie können wir eine agile Organisation aufbauen, ohne in der agilen Bürokratie gefangen zu sein?

Diszipliniert agil ist eine mögliche und wirkungsvolle Antwort, die ich im nächsten Teil dieser Serie vorstellen werde.

Referenzen