Im Jahr 2001 formulierte das ursprüngliche Manifesto for Agile Software Development eine Gegenposition von Entwickler:innen gegen das Top-down-Management von Software-Projekten.

Die Grundsätze dieses Manifests sind schwer zu widerlegen – und erfrischend klar. Im Kern geht es darum, funktionierende Software so schnell wie möglich zu liefern, den Kunden als Teil des Teams einzubinden und auf Veränderungen zu reagieren, statt alles von vornherein durchzuplanen, abzuliefern und dann zuzuschauen, wie es schief geht.

Spulen wir vor ins Jahr 2017: „Agile” ist zunehmend etwas geworden, das das Management den Entwickler:innen aufzwingen will. Und es hat unterwegs reichlich Ballast angesammelt.

Wie die Schweine in Orwells Animal Farm beginnen Scrum-Anhänger:innen den methodenbesessenen Projektmanagement-Jüngern zu ähneln, gegen die sich das ursprüngliche Agile-Manifest richtete.

Scrum, eine spezifische Projektmanagement-Methodik, ist fast zum Synonym für Agile geworden. Wie es in entwicklergetriebenen Kulturen typisch ist, hat es auf dem Weg dorthin sämtliche Protokolle, Taktiken und Buzzwords aufgesammelt – wie ein Schneeball, der einen Hang hinunterrollt. Wenn Scrum nicht alle erhofften Vorteile liefert, lautet die übliche Erklärung: Du machst es falsch. Wer nicht jeden Aspekt von Scrum vollständig verinnerlicht hat, betreibt „Fake Agile” – und das Projekt ist zum Scheitern verurteilt. Ein lohnendes Gegenbeispiel liefert das ursprüngliche Agile-Manifest. Wie die Schweine in Orwells Animal Farm beginnen Scrum-Anhänger:innen den methodenbesessenen Projektmanagement-Jüngern zu ähneln, gegen die sich das Manifest einst richtete.

Scrum illustration

Das alles heißt nicht, dass Agile oder Scrum per se schlecht wären. Funktionierenden Code so früh wie möglich vorweisen; in regelmäßigen, zeitlich begrenzten Zyklen demos zeigen und iterieren; den Kunden ins Team einbinden und Änderungen über ein Feature-Backlog steuern – das sind alles Grundsätze, die wir bei Made Media leben. Aber im Kern reden wir hier vom Softwareentwicklungszyklus. Es gibt Aspekte von Website- und App-Design, die streng genommen keine Softwareentwicklung sind. Für Design auf der Makroebene lässt Scrum kaum Raum. Deshalb verbinden wir agile Entwicklungsprozesse mit übergeordnetem Pragmatismus: genug Vorarbeit im Design, um uns keine ergebnislosen Sackgassen einzuhandeln – und QA nicht vollständig an Unit-Tests zu delegieren, die Qualität ausschließlich durch die Linse des Codes betrachten.

Konkret zeigt sich das meistens so: Die Rolle der Projektmanager:in verlagert sich darauf, das Produktionsteam zu fragen, was gerade passiert – und dann das Gantt-Diagramm anzupassen, damit es besser zur Realität passt. Der Schwanz der Realität wedelt mit dem fiktiven Hund.

Agile wird häufig dem Wasserfall-Ansatz gegenübergestellt, bei dem alle Aufgaben auf einem riesigen Gantt-Diagramm vorausgeplant werden – das mit fortschreitender Arbeit immer mehr einem Werk der Fiktion ähnelt. Konkret zeigt sich das meistens so: Die Rolle der Projektmanager:in verlagert sich darauf, das Produktionsteam zu fragen, was gerade passiert – und dann das Gantt-Diagramm anzupassen, damit es besser zur Realität passt. Der Schwanz der Realität wedelt mit dem fiktiven Hund.

Rain illustration

Ja, der Wasserfall-Ansatz hat seine Probleme. Aber wenn Agile-Befürworter:innen mit dem Finger auf Methoden wie PRINCE2 oder Zertifizierungen wie PMP zeigen, verkennen sie oft deren eigentlichen Zweck. PRINCE2 etwa hat ausgesprochen wenig über die eigentliche Projektdurchführung zu sagen. Seine Wurzeln liegen in der staatlichen Auftragsvergabe, wo die Durchführung in der Regel von einem externen Partner übernommen wird (wie uns!) – und als dessen Angelegenheit gilt. Der eigentliche Zweck von PRINCE2 ist nicht die Projektdurchführung, sondern die Produktion von ausreichend C.Y.A.-Dokumentation, um nachzuweisen, dass es nicht am Projektmanagement lag, wenn das Budget sich verdoppelt und das Ergebnis noch immer auf sich warten lässt.

Das heißt nicht, dass PRINCE2 grundsätzlich schlecht ist. Sein Ziel ist die Steuerung der Projekt-Governance – nicht der Projektdurchführung. Sicherzustellen, dass ein Projekt mit einem Business Case beauftragt wird. Richtlinien zu geben, wann Alarm geschlagen werden sollte, weil etwas aus dem Ruder läuft. Risiken vorauszusehen und festzuhalten. Diese Kontrollmechanismen sind wichtig, wenn man gegenüber seinem Budget Rechenschaft schuldet. Es geht um den Projekterfolg im Großen und Ganzen.

Webprojekte sind ein riskantes Geschäft. Scope lässt sich mit Worten so schwer fassen, dass man nie wirklich weiß, was man bekommt – oder was man will –, bis man es sieht. Deshalb bevorzugen wir Wireframes gegenüber Anforderungslisten. Aber niemand stellt dir einen Blankoscheck für dein Webprojekt aus, und du wirst deinem Vorstand oder deinen Auftraggeber:innen erklären müssen, was ihr Geld bringt. Also wird es zwangsläufig konkrete Zusagen zu Features, Budgets und Terminen im Voraus geben müssen. Entwicklergetriebene Methoden weichen diesem Punkt gerne aus. Warum wohl? Weil Entwickler:innen sich beim Code wohlfühlen – nicht beim Abgeben von Geschäftsversprechen.

Bei Made Media wissen wir, dass Projektbudgets oft Jahre gekostet haben und mit klaren Erwartungen an die Ergebnisse vergeben werden. Agile Entwicklungsmethoden entbinden uns nicht von unserer Verpflichtung, diese Erwartungen zu erfüllen. Mit Festpreisbudgets müssen wir Scrum mit ein paar kommerziellen Realitäten abmildern. Wir schätzen in Stunden, nicht in Pseudo-Abstraktionen wie Story Points. Auch wenn das manchmal die Entwickler:innen-Vibe bremst.

Bei Made Media verwenden wir deshalb eine Methodik, die viel von Scrum übernimmt und ein bisschen von DSDM und Kanban. Kund:innen sind herzlich eingeladen, an Sprint-Planungsmeetings teilzunehmen oder sogar an den täglichen Stand-ups, wenn sie möchten. Der wöchentliche Call mit Demo ist aber das Minimum. Bei Beauftragung, Governance, Reporting und Verantwortlichkeit orientieren wir uns stärker an PRINCE2. Und das ist kein Widerspruch.

Leseempfehlungen

  • Peopleware Demarco und Lister zeigen, dass die größten Probleme in der Softwareentwicklung menschlicher, nicht technischer Natur sind.
  • The Mythical Man-Month Pflichtlektüre für alle, die komplexe Projekte steuern.
  • Agile Manifesto Bessere Wege der Softwareentwicklung entdecken – durch Tun und gegenseitiges Unterstützen.
  • Scrum Ein iteratives und inkrementelles agiles Framework für die Produktentwicklung.
  • DSDM Dynamic Systems Development Method.
  • Kanban Ein Planungssystem für schlanke Produktion.
  • Eine Kritik an Scrum Mit erstklassigen Memes illustriert.

Nächsten Monat: Innovation mit Zweck