Scrum und Projektmanagement: Warum es beides braucht

Angefangen hatte alles 1995 an der OOPSLA, einer jährlich stattfindenden wissenschaftlichen Konferenz der Association for Computing Machinery (ACM). Hier präsentierte ein gewisser Ken Schwaber ein neuartiges Entwicklungsvorgehen unter dem Namen Scrum. Damals schrieb Schwaber: "Scrum befasst sich mit der Verwaltung, Weiterentwicklung und Pflege eines bestehenden Produkts, (...) nicht mit der Entwicklung neuer oder überarbeiteter Systeme."

Knapp 10 Jahre später veröffentlicht er ein Buch mit dem Titel "Project Management with Scrum". Im Vorwort findet sich folgende Metapher: "Angenommen, ich reise von Chicago nach Boston (...) in einem Auto, dann kann ich jede beliebige Route nehmen, wann immer ich will. Ich weiss nicht genau, wann ich dort ankommen werde, und ich habe wahrscheinlich nicht geplant, welche Route ich nehme oder wo ich übernachten werde. Unterwegs folge ich den Verkehrsregeln und Konventionen (...) In einem Auto bin ich ein unabhängiger Akteur und treffe Entscheidungen in meinem eigenen Interesse, im Rahmen der Regeln des Strassenverkehrs. Es ist für mich erstaunlich, dass Tausende und Abertausende von Menschen jeden Tag mit dem Auto unterwegs sind und ihre Ziele in einem Rahmen einfacher Verkehrsregeln erreichen, ohne zentralen Kontroll- oder Einsatzdienst." Daraus folgert Schwaber, dass eine empirische Prozesssteuerung, basierend auf Transparenz, Überprüfung und Anpassung (Scrum), eine hinreichende Voraussetzung ist, um Projekte erfolgreich zu führen.

Nur hat die Sache leider einen Haken

Eine Autofahrt von Chicago nach Boston ist eine Routine- bzw. Regeltätigkeit und kein Projekt! Um gängigen Projektdefinitionen zu genügen, muss ein Vorhaben einmalig, zeitlich und finanziell begrenzt, komplex und risikobehaftet sein und definierte Ergebnisse liefern, die einem Ziel dienen.

Um inhaltlich in der Nähe der Metapher mit der Autofahrt zu bleiben, können wir uns ein Velo-Trekking entlang der Seidenstrasse nach China anschauen.

Niemand von uns würde einfach mal aufs Velo steigen und Richtung Osten losfahren. Wir würden uns schlau machen über mögliche Routen, über die Visa-Vorschriften, über den Zustand der Verkehrswege und die Versorgungsmöglichkeiten. Wir würden versuchen, die Herausforderungen für Mensch und Material abzuschätzen, Risiken einzuschätzen, aber auch sehenswerte Zwischenziele ins Auge fassen und eine Vorstellung über die zeitliche Dimension unseres Unterfangens entwickeln.

Wir würden unsere Bikes für das Trekking ausrüsten und uns überlegen, wann es vom Klima und Wetter her günstig ist, loszufahren, damit wir nicht einen Tag nach Beginn der monatelangen Wintersperre am Karakorum stehen. Kurz, wir würden eine Grobplanung für unser Trekking machen.

Dann geht’s richtig los, wir schauen uns die ersten Etappen genauer an: Im März wollen wir von zuhause bis an den Bosporus, im April soll es bis in den Iran gehen und im Mai bis Kirgistan. Unterwegs schauen wir täglich, wie es vorwärtsgeht, welche Strassen verkehrsarm sind, wo sich eine Besichtigung anbietet und wo wir übernachten können. Wir haben also den Rahmenplan auf Sprintziele heruntergebrochen und können nun – ganz entsprechend dem Beispiel von Schwaber mit der Autofahrt – innerhalb der Etappe situativ entscheiden. Die empirische Prozess­steuerung schafft dabei maximale Flexibilität bei minimalem Overhead.

Es ist offensichtlich: Bei ernsthaften Projekten führt kein Weg an einer seriösen Vorbereitung vorbei. Nur dank dieser Vorleistung hat man in der Umsetzungsphase die Freiheit, den Tag nach Wetter, Lust und Laune zu gestalten und trotzdem zielgerichtet unterwegs zu sein.