Zum Hausbau mit Software: Scrum und Klassik integriert

Über Synchronisationspunkte lassen sich methodische Ansätze wie klassisches und agiles Projektmanagement integrieren: Meilensteine dienen als Übergabepunkte auch zwischen unterschiedlichen Ansätzen.

Was Scrum und klassisches Projektmanagement betrifft, bin ich hin- und hergerissen: auf der einen Seite zeigt Scrum in vielerlei Bereichen wirklich gute Ergebnisse, auf der anderen Seite wird mir der Unterschied zu klassischem Projektmanagement nicht so richtig verständlich. Wer hat gesagt, dass klassisches Projektmanagement gleichzusetzen ist mit einem Wasserfallmodell? Wer sagt außerdem, dass klassisches Projektmanagement etwas mit Kommandostrukturen zu tun hat? Sicher ist jedoch: klassisches Projektmanagement und Scrum lassen sich hervorragend kombinieren, etwa wenn man ein Haus bauen und eine eigene Steuerungssoftware dafür entwickeln will.

Synchronisationspunkte

Dieser Artikel ist ein erster Teil meiner Antwort auf die Einladung „Hausbau mit Software: Scrum und-oder klassisch?„. Vielen Dank für die Rückmeldungen! Auf den ersten Blick betrachtet, bietet es sich aus meiner Sicht an – was die Aufgabenstellung irgendwie bereits in sich birgt – den eigentlichen Hausbau mit klassischem Projektmanagement zu steuern und die Steuerungssoftware mittels Scrum zu entwickeln. Diese beiden methodischen Ansätze lassen sich nahtlos über definierte Synchronisationspunkte in Form von Meilensteinen integrieren.

In meinen bisherigen Diskussionen in echten Projekten hat es sich für mich gezeigt, dass es scheinbar leichter nachzuvollziehen ist, wenn die übergeordnete Struktur sich eher an einer klassischen Vorgehensweise orientiert. Unter anderem, da der Denkansatz der als „agil“ bezeichneten Methodik für so manchen Beteiligten im ersten Moment (noch) ungewohnt ist. Eine lineare Vorgehensweise ist doch (noch) eher üblich.

Gehen wir also davon aus, dass der Hausbau mittels Projektstrukturplan (PSP) und Zeitplan geplant wurde und gesteuert wird. Im Projektplan, besser: in der Abfolge der Arbeitspakete, wird es einen Punkt geben, ab dem die Anforderungen an die Software erstmals benannt werden können. Außerdem wird es einen Punkt geben, ab dem ein erster Prototyp der Steuerungssoftware sinnvoll eingesetzt werden kann und es wird einen Punkt geben, zu dem die endgültige Version der Software verfügbar sein sollte. Solche Punkte bieten sich als Synchronisationspunkte und damit als Übergabepunkte zwischen unterschiedlichen methodischen Modellen an.

Über Synchronisationspunkte lassen sich methodische Ansätze wie klassisches und agiles Projektmanagement integrieren: Meilensteine dienen als Übergabepunkte auch zwischen unterschiedlichen Ansätzen.
Über Synchronisationspunkte lassen sich methodische Ansätze wie klassisches und agiles Projektmanagement integrieren: Meilensteine dienen als Übergabepunkte auch zwischen unterschiedlichen Ansätzen.

Damit dieser Denkansatz gut funktioniert, darf ich nicht nur den eigentlichen Bau des Hauses als Projekt begreifen. Das Vorhaben und damit das Projekt aus Sicht des Projektmanagement beginnt mit der ersten Idee und beinhaltet auch die erste Definition von Anforderungen, die letztlich Grundlage für eine Vorgehen nach Wasserfall-Modell sind, wie auch für das Backlog in der agilen Welt. Auch Finanzierung und Genehmigungen gehören zum Projektumfang dazu.

Aus einer übergeordneten Zielvorstellung für das gesamte Vorhaben lässt sich die Produktvision der Steuerungssoftware sowie deren Integration in die Umwelt, also das Haus, ableiten. Eine gute, durchdachte Produktvision ist – nebenbei bemerkt – für mich einer der wichtigsten Schlüssel, dass agile Modelle in der Praxis funktionieren. In so manchem Praxisfall kommt mir dieser Teil zu kurz.

Aus Steuerungssicht wird dann noch wichtig, dass geänderte Anforderungen innerhalb der Softwareentwicklung in den klassischen Teil zurückgespielt werden müssen. Das gilt immer dann, wenn definierte Eingabe- oder Ausgabepunkte berührt werden, die etwa andere Leitungsverläufe erfordern. Spätestens jetzt kommt der Disziplin des Änderungsmanagement in der klassischen Welt die Bedeutung zu, die sie verdient hat. Und der Regelkommunikation zwischen Scrum-Team und Gesamtprojektleitung.

Wo genau liegt der Unterschied zwischen Scrum und klassischem Projektmanagement?

Die Diskussion über Scrum und klassisches Projektmanagement wird, so erlebe ich es, nicht selten dogmatisch und ideologisch geführt. An diesem Punkt endet dann mein Verständnis für die Diskussion. Sämtliche Projektmanagement-Ansätze sind Hilfsmittel, um Ziele zu erreichen. Wie bei einer Werkzeugkiste wähle ich für ein Vorhaben die Werkzeuge aus, die mir sinnvoll und hilfreich erscheinen. Die anderen belasse ich in der Kiste. Wobei es für ein und dieselbe Aufgabe manchmal verschiedene Werkzeuge gibt, mit der sich die Aufgabenstellung lösen lassen würde.

Nach intensiver Auseinandersetzung mit den verschiedenen methodischen Denkansätzen bleiben für mich manche Diskussionspunkte unbeantwortet. Etwa die Frage, woher die Annahme kommt, dass klassisches Projektmanagement mit dem Wasserfall-Modell gleichzusetzen ist? Dieser Gedanke wird in vielen Büchern als Automatismus aufgegriffen, das mag sein. Die Methode des Projektmanagement sagt in ihrer Grundform jedoch erst einmal nichts darüber aus, dass ein lineares Vorgehen gewählt werden muss. Schon seit vielen Jahren, noch vor Scrum, gibt es etwa das Weiterentwickelte Spiralmodell als Alternative.

Wer darüber nachdenkt, wie er ein Vorhaben angehen will, kommt meist schnell zu dem Schluss, dass es eine Gesamtsicht geben muss, die das gesamte Vorhaben in den Fokus rückt und eine schlüssige Gesamtheit der Ergebnisse sicherstellen sollte, und eine operative Sicht, die Aufgaben verteilt und Ressourcen sicherstellt. In Kombination mit der Logik der Qualitätssicherung, dass Qualität möglichst früh sichergestellt werden sollte, um ausufernde Qualitätsrisiken und -kosten zu vermeiden, wird auch in der klassischen Denkweise dazu kommen, auf konkrete, greifbare Zwischenergebnisse hin zu arbeiten. Dann verschwimmt der Unterschied zwischen agilem und klassischem Ansatz.

Ähnliches gilt für die weit verbreitete Vorstellung, dass ein Projektplan etwas Starres ist, an dem man unbedingt festhalten sollte. Die grundlegende Logik des Projektmanagement schreibt dem Projektplan eine andere Funktion zu: er zeigt einen Weg auf, wie es gelingen könnte, die Projektziele zu erreichen. Er basiert auf Schätzungen und Annahmen. Die Realität wird sich unter keinen Umständen an diese Schätzungen und Annahmen halten. Aus der Differenz zwischen Realität und Plan lassen sich Schlüsse ziehen, wie die Projektleitung reagieren kann und muss, um eine Zielerreichung im Bereich des Wahrscheinlichen zu halten. Sinn und Zweck eines Plans ist nicht die Einhaltung des Plans. Ein Plan ist lediglich eines der erwähnten Hilfsmittel, um die Projektziele zu erreichen. Die Änderung ist der Normalzustand und gutes Projektmanagement macht eine Reaktion auf Änderungen und Abweichungen einfach möglich.

In gleicher Manier gilt dies für die Anforderungen an das zu liefernde Produkt: der Anforderungskatalog, der zu Beginn erstellt wird, spiegelt den Kenntnisstand zu Beginn eines Projektes wider. Ein Projektteam wird im Projektverlauf klüger. Es macht Sinn, dieses Klüger-Werden in die weitere Projektarbeit zu integrieren. In Scrum geschieht dies über neue Anforderungen im Backlog und deren Priorisierung, im klassischen Projektmanagement über die systematische Bearbeitung von Änderungsanforderungen. Hier bleibt ebenfalls die Frage offen, wo geschrieben steht, dass einmal definierte Anforderungen für die Ewigkeit Gültigkeit behalten müssen? Auch hier macht gutes Projektmanagement die Änderung und Implementierung von geänderten Anforderungen leicht möglich.

Bleibt noch darüber zu diskutieren, dass das Entwicklerteam bei Scrum die eigene Arbeit selbst definiert und aufteilt. Allein aus Akzeptanzgründen empfiehlt es sich, bei jedem Projekt diejenigen, die Arbeiten erledigen sollen, in die Planung einzubeziehen. Ganz abgesehen davon, dass deren Expertenwissen nötig ist, um einen sinnvollen und schlüssigen Projektplan erstellen zu können. Als Projektleiter anzunehmen, alles mindestens genau so gut zu verstehen, wie das gesamte Projektteam, halte ich – mit Verlaub – für anmaßend.

Wie stehen Sie dazu? Ich meine, „Projektplanung ist Denken„, gemeinsames, systematisches Denken unter Zuhilfenahme bewährter Techniken des Aufschreibens und Visualisierens. Nicht mehr, nicht weniger.

Ihr
Holger Zimmermann
Projektmensch

(Visited 2.345 times, 1 visits today)

Ein Kommentar bei „Zum Hausbau mit Software: Scrum und Klassik integriert“

  1. […] gelegentlich als “klassisches Projektmanagement” bezeichnet wird (hierzu mehr in “Zum Hausbau mit Software: Scrum und Klassik integriert“). Allen gemein ist es, dass sie von der Anwendung leben, vom praktischen […]

Kommentar verfassen