IV. Agile Umsetzung, robuste Governance.

Im Jahr 2001 formulierte das ursprüngliche Manifesto for Agile Software Development eine Position der Entwickler gegen ein Top-Down-Softwaremanagement.

Den Grundsätzen dieses Manifests kann man nur schwer widersprechen, und sie sind auch erfrischend einfach. Es läuft darauf hinaus, Software so schnell wie möglich zum Laufen zu bringen, mit dem Kunden als Teil des Teams zu arbeiten und auf Veränderungen zu reagieren, anstatt zu versuchen, alles im Voraus zu planen, zu übergeben und darauf zu warten, dass es schrecklich schief geht.

Im Jahr 2017 ist "agil" jedoch zunehmend zu etwas geworden, das die Unternehmensleitung den Entwicklern aufzwingen will. Auf dem Weg dorthin hat der Begriff auch eine Menge Ballast mit sich gebracht.

Wie die Schweine in Orwells Farm der Tiere ähneln die Scrum-Anhänger den methodologiebesessenen Projektmanagement-Jüngern, gegen die sich das ursprüngliche agile Manifest richtete.

Scrum, eine spezielle Projektmanagement-Methode, ist fast zum Synonym für das Wort Agile geworden. Wie es für entwicklungsorientierte Kulturen typisch ist, hat sie alle Arten von Protokollen, Taktiken und Jargon aufgesammelt, wie ein Schneeball, der bergab rollt. Wenn Scrum nicht alle seine vermeintlichen Vorteile bietet, lautet die übliche Argumentation, dass man es nicht richtig macht; wenn man nicht jedes Element von Scrum von ganzem Herzen angenommen hat, dann macht man "unechtes Agile", und Ihr Projekt ist zum Scheitern verurteilt. Es lohnt sich, diese Ansicht mit dem ursprünglichen Agilen Manifest zu vergleichen. Wie die Schweine in Orwells Farm der Tiere ähneln die Scrum-Anhänger den methodologiebesessenen Projektmanagement-Jüngern, gegen die sich das ursprüngliche agile Manifest richtete.

Das soll nicht heißen, dass Agile oder gar Scrum etwas Schlechtes sind. Arbeitsfähiger Code zum frühestmöglichen Zeitpunkt, Demos und Iterationen innerhalb regelmäßiger, zeitlich festgelegter Zyklen, die Einbeziehung des Kunden in das Team und die Verwendung eines Feature Backlogs zur Verwaltung von Änderungen - all das sind Grundsätze, die wir bei Made Media befolgen. Aber wir sprechen hier wirklich über den Softwareentwicklungszyklus. Es gibt Elemente des Website- und App-Designs, die streng genommen nicht zur Softwareentwicklung gehören. In Scrum ist auf der Makroebene nicht wirklich viel Platz für Design. Wir kombinieren also agile Entwicklungsprozesse mit allgemeinem Projektpragmatismus, indem wir im Vorfeld gerade so viel entwerfen, dass wir uns nicht in unproduktive Kaninchenlöcher verirren, und die Qualitätssicherung nicht vollständig an Unit-Tests delegieren, die Qualität ausschließlich durch die Linse des Codes sehen.

Dies zeigt sich typischerweise, wenn die Rolle des Projektleiters darin besteht, das Produktionsteam zu fragen, was passiert, und dessen Gantt-Diagramm zu aktualisieren, damit es die Realität besser widerspiegelt. Der Schwanz der Realität wedelt mit dem fiktiven Hund.

Agile wird in der Regel mit der Wasserfalltechnik verglichen, bei der alle Aufgaben in einem riesigen Gantt-Diagramm vorgezeichnet werden, das im Laufe der tatsächlichen Arbeit immer mehr einer Fiktion ähnelt. Dies äußert sich in der Regel darin, dass der Projektmanager das Produktionsteam fragt, was gerade passiert, und dessen Gantt-Diagramm aktualisiert, um die Realität besser widerzuspiegeln. Der Schwanz der Realität wedelt mit dem fiktiven Hund.

Also ja, Wasserfall hat seine Probleme. Aber wenn mit dem Finger auf eine Methode wie PRINCE2 oder Zertifizierungen wie PMP gezeigt wird, verkennen die Befürworter der agilen Methode oft den wahren Zweck dieser Methoden. PRINCE2 zum Beispiel hat eigentlich sehr wenig über die Projektabwicklung zu sagen. Seine Ursprünge liegen im öffentlichen Beschaffungswesen, wo die Lieferung höchstwahrscheinlich von einem Outsourcing-Partner (wie uns!) durchgeführt wird und als dessen Aufgabe angesehen wird. Der eigentliche Zweck von PRINCE2 besteht nicht darin, das Projekt abzuliefern, sondern genug C.Y.A. Dokumentation zu liefern, um zu beweisen, dass es nicht die Schuld des Projektmanagers ist, wenn sich das Budget verdoppelt und das Produkt immer noch nicht zu sehen ist.

Was nicht heißen soll, dass PRINCE2 an sich schlecht ist. Sein Zweck ist der Versuch, die Projektleitung zu kontrollieren, nicht die Projektdurchführung. Es soll sicherstellen, dass ein Projekt mit einem Business Case in Auftrag gegeben wird. Es soll Richtlinien dafür geben, wann man Alarm schlagen sollte, wenn nicht alles nach Plan läuft. Vorhersage und Protokollierung von Risiken. Diese Kontrollmechanismen sind wichtig, wenn Sie Ihren Budgets gegenüber verantwortlich sind. Es geht um den Gesamterfolg des Projekts.

Webprojekte sind eine riskante Angelegenheit . Der Umfang ist so schwer in Worte zu fassen, dass man nie wirklich sicher ist, was man bekommt oder was man überhaupt will, bis man es sieht. Das ist einer der Gründe, warum wir Wireframes den Anforderungslisten vorziehen. Aber niemand wird Ihnen einen Blankoscheck für Ihr Webprojekt ausstellen, und Sie müssen Ihrem Vorstand oder Ihrem Sponsor versichern, was Sie für sein Geld bekommen. Es ist also unvermeidlich, dass Sie sich im Vorfeld auf bestimmte Funktionen, Budgets und Fristen festlegen müssen. Dies ist etwas, das bei entwicklungsorientierten Methoden eher unterschlagen wird. Raten Sie mal, warum? Weil Entwickler sich beim Schreiben von Code wohlfühlen und keine geschäftlichen Versprechungen machen.

Wir bei Made Media sind uns bewusst, dass es oft Jahre dauert, bis ein Projektbudget zur Verfügung steht, und dass es mit bestimmten Erwartungen an die Ergebnisse verbunden ist. Agile Entwicklungsmethoden können uns nicht von unserer Verpflichtung entbinden, diese Erwartungen zu erfüllen. Da wir mit festen Budgets arbeiten, müssen wir Scrum mit einigen kommerziellen Realitäten in Einklang bringen. Wir schätzen in Stunden, nicht in Pseudoabstraktionen wie Story Points. Auch wenn das manchmal die Stimmung unter den Entwicklern trübt.

Daher verwenden wir bei Made Media eine Methodik, die sich stark an Scrum und ein wenig an DSDM und Kanban orientiert. Die Kunden sind herzlich eingeladen, an den Sprint-Planungstreffen oder sogar an den täglichen Stand-ups teilzunehmen, wenn sie dies wünschen. Aber ein wöchentlicher Anruf und eine Demo sind die Basis. In Bezug auf Projektbeauftragung, Steuerung, Berichterstattung und Rechenschaftspflicht orientieren wir uns eher an PRINCE2. Und das ist kein Widerspruch.

Pflichtlektüre

• Peopleware Demarco und Lister zeigen, dass die Hauptprobleme der Softwareentwicklung menschlicher und nicht technischer Natur sind. 
• The Mythical Man-Month - ein Einblick für jeden, der komplexe Projekte leitet.
• Agile Manifesto, das bessere Wege zur Entwicklung von
  Software aufzeigt, indem es diese selbst durchführt und anderen dabei hilft.
• Scrum ist ein iterativer und inkrementeller agiler Softwareentwicklungsrahmen für das Management der Produktentwicklung.
• DSDM Dynamische Systementwicklungsmethode.
• Kanban - ein Planungssystem für die schlanke Produktion.
• Eine Kritik an Scrum, illustriert mit erstklassigen Memes.

Nächster Monat: Innovation mit Sinn