Brauchen wir in einer agilen Welt noch Projekte?

Kernthesen

• Auch in Zukunft werden wir Projekte benötigen.
• Es werden deutlich weniger sein als heute.
• Die bekannten Projektmanagementmethoden können hilfreich sein, wenn man sie als Framework und nicht als Kochbuch nutzt.

Was man so liest und hört

• Scrum ist eine agile Projektmanagementmethode.
• Die Digitalisierung erfordert keine Projekte, sondern Produkte.
• Scrum ist eine Projektmanagementmethode, die keinen Projektleiter braucht.
• Mit SAFe gibt es keine Projekte mehr.
• Agiles Projektmanagement mit Hermes 5 und Scrum.
• Entwickeln wir das Projekt mit Hermes oder mit Scrum?

Zur Klärung lohnt es Grundsatzfragen zu stellen. Z.B.

• Wofür sind Projekte notwendig?
• Was ist Scrum?

Scrum

Im Scrum Guide steht: "Scrum ist ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte." Damit ist das Wichtigste bereits gesagt. Die Details setze ich beim Leser voraus. Sonst kann man sie im Scrum Guide nachlesen.

Mit schnellem Feedbackloop an neue Erkenntnisse anpassen

Immer wenn es um eine komplexe Aufgabenstellung geht, bei der nicht ohne Weiteres vorher absehbar ist, wie die Anforderungen umgesetzt werden können, ist ein iterativ inkrementelles Vorgehen mit regelmässiger Überprüfung und Anpassung notwendig. Durch ständige Anpassung an neue Erkenntnisse aus der Produktentwicklung und aus Änderungen des Marktes entsteht ein schneller Feedbackloop.

Das Fehlen wichtiger Punkte ist keine Schwäche

Im neuen Scrum Guide steht: "Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind." Der Scrum Guide sagt entsprechend nichts zum Thema Projekte. Damit ist die Aussage, Scrum sei eine agile Projektmanagementmethode, recht gewagt.

Im Scrum Guide wird unter anderem zu folgenden Themen nichts gesagt:

• Sprintübergreifende Planung
• Teamübergreifende Koordination
• Wie wird das Backlog gefüllt?
• Wie wird es priorisiert?
• Testen
• Produktauslieferung
• Risikomanagement
• Finanzierung und Controlling
• Kommunikation mit Stakeholdern, insbesondere mit dem Auftraggeber

Viele dieser Themen werden in Projektmanagementmethoden adressiert.

Dieses Fehlen wichtiger Punkte ist keine Schwäche, sondern die vielleicht entscheidende Stärke, die Scrum erfolgreich macht. Einem neuen genialen Motor wird auch niemand vorwerfen, dass er keine Räder oder keinen Propeller hat. Er ist eben sowohl für Autos als auch für Flugzeuge einsetzbar. So ist es auch mit Scrum. Es kann aufgrund seiner bewussten Beschränkung flexibel in unterschiedlichen Umgebungen eingesetzt werden. Während andere Methoden auf Hunderten von Seiten detailliert beschrieben sind, passt Scrum auf 18 Seiten. Aber so wie man einen nackten Motor kaum auf die Strasse stellen wird, benötigt auch Scrum in der Praxis noch einiges drum herum, das je nach Umgebung variiert.

Ein Projekt ist ein einmaliges und begrenztes Vorhaben

Definition des Begriffs "Projekt" nach DIN 69901:
"Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation."
Es wird deutlich, dass es sich bei Scrum und Projektmanagement um zwei sehr unterschiedliche Domänen handelt, die nicht in Konkurrenz zueinander stehen, sondern sich eher ergänzen. Entsprechend ist grundsätzlich eine Kombination möglich und wir müssen keine Entweder-oder-Entscheidung fällen.

Langläufer als Projekt

Wenn ein Vorhaben über viele Monate oder Jahre läuft, einen hohen Aufwand verursacht und in wichtigen Fragen Risiken beinhaltet, sollte es als Projekt durchgeführt werden. Es wird eine organisatorische und finanzielle Hülle benötigt. Die Aktivitäten mehrerer Teams werden über einen längeren Zeitraum konsistent koordiniert und an den Zielen des Kunden ausgerichtet. Missbraucht man die Projektmethodik für anderes, wie z.B. Wartungsarbeiten entsteht «Waste».

Das Problem mit den Projektmanagementmethoden

Die meisten Projektmanagementmethoden sind in den 1980iger und 1990iger Jahren als Antwort auf immer grössere und kompliziertere Vorhaben entstanden. Weil es lange Zeit modern war, hat man versucht, immer mehr in Form von Projekten zu realisieren. Mit dem Ziel für alle Situationen eine Lösung zu bieten und Fehler zuverlässig auszuschliessen, wurden die Methoden immer mehr verfeinert. Als Verkaufsargument gilt: «Man muss die Methode nur lernen und konsequent anwenden. Dann ist der Erfolg sicher». Auch wenn solche Erwartungen unrealistisch sind und immer wieder enttäuscht werden, halten sie sich doch hartnäckig. Schliesslich ist das für viele Beratungsunternehmen ein lukratives Geschäftsmodell. Leider gibt es mittlerweile auch im agilen Bereich ähnliche Bestrebungen wie z.B. mit dem SBOK ® Guide. Siehe dazu auch den Anfang des Eintrags im Prozessfenster-Blog.

Widerspruch: Schnelles Feedback und langlaufende Projekte

Der Wunsch nach einer schnellen Markteinführung einerseits und langlaufende Vorhaben andererseits sind ein Widerspruch. Tatsächlich sollten in einem komplexen und volatilen Umfeld Projekte soweit wie möglich vermieden werden, da Projekte immer eine längere Bindung und damit Risiko und reduzierte Flexibilität bedeuten.

Projekte vermeiden durch intelligente Architektur

• Modulare Produktarchitektur: Die Aufteilung in einzelne weitgehend unabhängige Services ist für Agilität förderlich bzw. grundlegend, auch wenn dies nicht immer einfach umsetzbar ist. Eine Armada von Schnellboten ist agiler als ein Supertanker. Es gilt zwischen der Effizienz (z.B. Kostenvorteil) einer grossen komplexen integrierten Lösung und der Effektivität (z.B. ein zur Nachfrage passendes Angebot) vieler modularer und flexibler Services abzuwägen. In einem zunehmend komplexen und volatilen Umfeld nimmt die Bedeutung der Effektivität immer mehr zu.
• Schnelle Verifikation: Um zeitnah ausliefern zu können, muss das Produkt schnell und kostengünstig verifiziert werden können z.B. durch automatisiertes Testen. Die Basis dafür ist eine modularisierte Struktur.

Auf diese Weise lassen sich neue Releases oder neue Produkte so schnell auf den Markt bringen, dass für ihre Erstellung kein Projekt notwendig wird. Die Vorteile, die ein derartiges Vorgehen hat, werden meist unterschätzt.

In grossen Organisationen sind auch organisatorische Gründe für Projekte zu beobachten. Anforderungen werden gewohnheitsmässig zu grösseren Paketen zusammengestellt und dann als ein Release eingeführt, auch wenn diese Anforderungen inhaltlich wenig Zusammenhang haben. Ein wichtiger Grund ist das Controlling, das ein Kostenbehältnis benötigt. Dafür bietet sich das Projekt an, selbst wenn das oft technisch und inhaltlich nicht sinnvoll ist. In solchen Fällen sollen unbedingt andere organisatorische und finanzielle Lösungen gesucht werden.

Um Projekte zu vermeiden, wird teilweise dem Sprint 1 ein Sprint 0 vorgeschaltet. Dieser dauert dann mehrere Monate und wird von anderen Personen bearbeitet als die restlichen Sprints. Damit hat er kaum etwas mit einem Sprint, wie er im Scrum Guide beschrieben ist, zu tun, erfüllt dafür aber alle Tatbestände einer Konzeptphase. Ein derartiges Vorgehen betrachte ich im Folgenden auch als Projekt.

Was, wenn das alles nicht möglich ist?

Leider ist die Welt nicht immer so ideal. Beispielsweise:

• Gewachsene Legacy-Systeme bestehen aus grossen hochkomplexen Systemen mit einer kaum überschaubaren Anzahl von Schnittstellen. Jede Änderung an einem derartigen System kann schwer absehbare Auswirkungen auf das gesamte System haben, wodurch jede Anpassung umfangreiche Tests notwendig macht. Aufgrund dieser Struktur lassen sich automatisierte Tests kaum realisieren. Schnelle Releases sind unmöglich. Jede Anpassung wird zu einem langwierigen und riskanten Vorhaben.
• Hat das Produkt einen wesentlichen Teil an Hardware, ist es schwierig jeden Sprint ein «potentially releasable» Produktinkrement zu liefern. Sind Hardwarekomponenten involviert, deren Produktion teuer oder langwierig ist, dauern die Vorhaben lang und werden risikoreich.
• Regulation: Produkte aus stark regulierten Märkten wie Medizintechnik oder Luft- und Raumfahrt dürfen erst nach umfangreichen und teuren Tests auf den Markt gebracht werden. Dies hat einen ähnlichen Effekt wie bei den hardwarelastigen Produkten.

In derartigen Fällen wird es auch in Zukunft Projekte geben. Damit müssen wir uns überlegen, wie wir Agilität und Projekte kombinieren.

Projekte mit Agilität kombinieren

Eine sinnvolle Kombination nutzt möglichst einfache Projektmanagementmethoden als Framework und Checkliste, nicht als Kochrezept, das Erfahrung und eigenes Nachdenken ersetzen soll.

Der offensichtlichste Unterschied zwischen klassischen und agilen Methoden liegt in der Konzeptarbeit. Im Wasserfallmodell wird idealerweise alle Konzeptarbeit erledigt, bevor die Realisierung beginnt. In agilen Methoden werden die Anforderungen idealerweise komplett parallel zur Realisierung analysiert. In der Praxis mischt sich das jedoch. Die meisten Projektmanagementmethoden sehen Detailkonzepte in der Realisierungsphase vor. Die genaue Grenze zwischen dem, was in der Konzeptphase zu klären ist und den Detailkonzepten der Realisierungsphase, ist je nach Projekt individuell festzulegen. In einem agilen Projekt sollte möglichst viel realisierungsbegleitend analysiert werden.

Sinnvollerweise wird die grobe Produktarchitektur vor dem Hauptteil der Realisierung geklärt. Diese bildet die Basis für folgende Punkte:

• Prüfung der Machbarkeit der gewählten Produktvariante
• Grobe Kostenschätzung
• Planung wichtiger Schnittstellen und Synchronisationspunkte zu anderen Vorhaben
• Erstellung eines initialen Product Backlogs
• Ggf. Abstimmung mit Unternehmensrichtlinien wie Architekturrichtlinien, Sicherheitsvorschriften, Fragen der Corporate Identity etc.

Wichtig ist, hier nicht dem Missverständnis zu verfallen, eine komplette und detaillierte Produktarchitektur entwickeln zu müssen. Sie soll den aufgeführten Zielen dienen. Alles was darüber hinausgeht, liegt auf Halde, veraltet und ist damit «Waste». Es behindert mehr, als dass es hilft.

Gegenüber einer im Wasserfallmodell weitgehend unstrukturierten Realisierungsphase, ist eine Umsetzung mit Scrum dank priorisiertem Backlog, Burndown Chart, Sprintplanung, -review und -retrospektive wesentlich besser plan- und steuerbar.

In der «Definition of Done» wird der Begriff der «potentiell auslieferbaren Funktionalität» notwendigerweise eingeschränkt sein. Schliesslich müssen wir ja die Realisierung im Rahmen eines Projekts machen, weil wir nicht einfach in kleinen Schritten ausliefern können. Dies darf aber auf keinen Fall eine Begründung sein, weitgehend auf frühes Testen zu verzichten. Es muss innerhalb der Sprints soweit wie irgend möglich getestet und mit dem Endanwender verifiziert werden. Nur so erhält man die Vorteile von Scrum wie z.B. schnelle Feedbackloops.

Wer die Rolle des Product Owners übernimmt, muss individuell in jedem Projekt geklärt werden.
In einfachen Fällen kann dies der Projektleiter oder der Auftraggeber sein. Meist ist es jedoch eine separate Stelle.
Je nach Produkt- und Marktanforderungen kann die so entwickelte Funktionalität in ein oder mehreren Releases im Rahmen des Projekts eingeführt werden.

Moderne Projektmanagementmethoden wie Hermes 5 unterstützen prinzipiell so ein Vorgehen, wenn sie nicht durch unsachgemässes Customizing und rigide Controllingvorschriften ruiniert werden.

Fazit

Mit einem guten Verständnis sowohl für Agilität als auch für Projektmanagement können die beiden Bereiche produktiv kombiniert werden. Damit lassen sich die Vorteile agilen Vorgehens auch in grossen und komplexen Umgebungen nutzen, die sonst für Agilität schwer zugänglich sind.