Stellen Sie sich vor, Sie haben gerade die Leitung eines Projekts "gewonnen" und machen sich daran, mit der Planung zu beginnen. Die entscheidende Frage: Wie viel Aufwand steckt hinter der Umsetzung der Anforderungen? Schwer zu sagen, wenn die Anforderungen im Lastenheft ziemlich vage sind und sich trotz Nachfragen nicht präzisieren lassen. Offensichtlich kann auch der Kunde noch nicht so genau formulieren, was er will. Trotzdem hat Ihr Auftraggeber bereits unmissverständliche Vorstellungen über den Endtermin.

Wie viele Personen brauchen Sie, um den Auftrag in diesem Zeitrahmen umzusetzen? Was wird es also kosten? Auch das ist schwer zu beantworten, wenn noch gar nicht klar ist, wie die Anforderungen eigentlich umgesetzt werden sollen. Eine detaillierte Auftragsklärung, wie Sie es aus Ihren Projektmanagement-Schulungen kennen, scheint nicht möglich zu sein. Was tun?

Wenn Sie eine Chance haben wollen, den Zeitrahmen einzuhalten, müssen Sie so bald wie möglich anfangen. Sie haben bereits einiges über agile Vorgehensweisen im Bereich der Software-Entwicklung gehört, die für derart unklare, unsichere Situationen das Mittel der Wahl zu sein scheinen. Erfolgsstories machen die Runde, aber auch Geschichten vom kläglichen Scheitern. Sie haben gehört, dass es nicht nur um bestimmte Praktiken geht, sondern vielmehr auch um Werte und Prinzipien, gar um ein Mindset. Könnte ein agiler Ansatz Ihnen helfen?

Passt Agilität auch zu Nicht-Software-Projekten?

Agilität und Scrum sind in aller Munde, vor allem bei Software-Entwicklungen. Agilität ist jedoch auch auf völlig andere Projekte anwendbar. Ob Ihnen als Projektleiter der agile Ansatz helfen kann, wie Sie den Transfer der Prinzipien und Praktiken meistern und wie Sie die ersten Schritte gehen – das möchte ich in diesem Artikel mit einigen praktischen Beispielen darstellen.

Das Manifest für agile Software-Entwicklung als Wegbereiter

Wenn Sie sich mit Agilität beschäftigen, werden Sie sehr schnell auf das Manifest für agile Software-Entwicklung stoßen. Schon der Name zeigt den Ursprung in der Software-Entwicklung. Es zeigte sich bereits Ende des 20. Jahrhunderts, dass traditionelle Vorgehensweisen, die auf Vorhersagbarkeit und Planbarkeit beruhen, aufgrund ständig zunehmender Komplexität an ihre Grenzen stoßen. So entstanden Methoden wie Scrum und eXtreme Programming als "Gegenbewegung" zu gängigen Wasserfall-Prozessen.

Diese Erkenntnis ist längst nicht mehr auf Software-Entwicklung beschränkt, sodass Agilität als Weg zur Lösungsfindung in die unterschiedlichsten Gebiete eingezogen ist (z.B. Produktentwicklung mit Hardware und Mechanik, Marketing, Gesundheitswesen, Personalwesen, …). Die Werte und Prinzipien des Manifests lassen sich unabhängig von der Anwendungsdomäne verallgemeinern. Wenn Sie "Software" durch "Produkt", "Service" oder "Ergebnis" ersetzen, wird aus "Wir schätzen funktionierende Software mehr als umfassende Dokumentation" die Formulierung: "Wir schätzen ein wertvolles Ergebnis mehr als begleitende Bürokratie".

Scrum wird oft als Projektmanagement-Methode dargestellt, was genaugenommen nicht korrekt ist. Im Scrum Guide finden Sie: "Scrum ist ein Framework für die Entwicklung, Auslieferung und Erhaltung komplexer Produkte". Eine Produktentwicklung wird immer weitergeführt, so lange das Produkt wirtschaftlich sinnvoll ist – in Scrum in einer Folge von Iterationen (Sprints), die jeweils ein Produktinkrement hervorbringen. Ein Projekt dagegen ist ein zeitlich begrenztes, einmaliges Vorhaben, um ein bestimmtes Ziel zu erreichen. Der Transfer von der Scrum-kompatiblen Produkt-Denkweise auf ein Projekt bereitet oft einige Schwierigkeiten. Lohnt es sich überhaupt, sich auf unbekanntes Terrain zu begeben? Ergibt agiles Vorgehen für Sie überhaupt Sinn? Gehen wir dazu zurück zu unserer Ausgangssituation.

Agil = planlos?

Sie wollen einen Plan für Ihr Projekt erstellen und haben festgestellt, dass eine detaillierte Schätzung aufgrund zu großer Unsicherheiten nicht möglich ist. Kann Ihnen Agilität aus diesem Dilemma helfen? Heißt Agilität, völlig planlos aufs Geratewohl einfach loszuarbeiten?

Das ist tatsächlich ein weitverbreitetes Vorurteil. Das Gegenteil ist der Fall: Es wird fortlaufend geplant. Im Unterschied zu klassischer Planung ist die Granularität jedoch abhängig vom Zeithorizont und von der zu erwartenden Unsicherheit. Im Klartext: Eine feingranulare Planung auf Basis von Arbeitspaketen in der Größenordnung von Stunden oder Tagen führe ich nur für den unmittelbar bevorstehenden Zeitraum von z.B. zwei Wochen durch. Die mittel- und langfristigen Zeithorizonte (Phasen, Releases, Roadmaps, …) werden gröber beplant, da ich ja davon ausgehe, dass sich hier sowieso einiges ändern wird (Bild 1).