Warum die Süddeutsche Zeitung Scrum richtig einsetzt

Bild: Wikimedia Comons, Clemens Pfeiffer - CC BY 2.0

Noch vor einigen Jahren hätte ich so etwas "Neumodisches" wie Scrum bei einem Unternehmen wie dem Süddeutschen Verlag nicht erwartet. Ich habe ja meine beruflichen Erfahrungen in der Medienbranche gemacht, und freundlich gesagt - ich hatte häufig den Eindruck, dass die Tradition dort höher geschätzt wird als die Innovation. Für einige Zeitungshäuser stimmt das sicher immer noch, bei der Süddeutschen Zeitung bin ich aber mittlerweile anderer Meinung. Erstmals aufmerksam geworden bin ich vor zwei Jahren, als ich hörte, dass die SZ für ein Scrum-Projekt Testautomatisierer sucht. Seitdem blitzten die Buzzwords Süddeutsche und Scrum immer wieder gemeinsam in meiner Timeline auf und verbanden sich immer mehr zu einem Bild. Vorläufiger Höhepunkt: Ein Interview mit und ein Blogeintrag von sz.de-Chefredakteur Stefan Plöchinger veröffentlicht auf horizont.de und in seinem Tumblr-Blog. [Edit: der Blogbeitrag ist mittlerweile gelöscht]

Neben anderen vernünftigen Aussagen (z.B. der, dass digitaler Journalismus interdisziplinäre Teams aus Journalisten und Programmierern braucht) ist mir vor allem im Kopf hängen geblieben, dass hier eine Vorgabe von Scrum idealtypisch umgesetzt wird: nach jedem zwei-Wochen-Sprint soll Software livegehen um sofort sehen zu können, wie sie beim Kunden/Leser ankommt. Wohlgemerkt, es wird nicht der Anspruch erhoben, dass sie livegehen könnte, wenn man denn wollte, nein, sie wird tatsächlich auf das Internet und seine Bewohner losgelassen. Mit Plöchingers Worten aus dem Horizont-Interview:

Alle zwei Wochen [wollen wir] eine neue Version der Seite publizieren, damit wir alle zwei Wochen reagieren können, im Sinne von Scrum und agiler Produktentwicklung – wem diese Worte nichts sagen, der hat meiner Meinung nach ein Problem in der digitalen Welt.

Das ist besonders. Und zwar ganz unabhängig von dem Medien/Zeitungs-Thema. Es ist besonders, weil sich so kurze Release-Zyklen in Deutschland kaum finden lassen. Hier findet sich normalerweise immer noch die aus dem Wasserfall-/V-Modell stammende Idee von Großreleases alle paar Monate. Wenn davon abgewichen wird hat das weitreichende Auswirkungen: nach mehreren Sprints mit halbherzig ausgeführter Qualitätssicherung noch eine Integrationstest- und Bugfixing-Phase dranzuklatschen, das geht dann nicht mehr. Wenn man nach jedem Sprint neue Funktionen livegehen lässt muss die Qualität stimmen. Dann muss es möglich sein, innerhalb kürzester Zeit nicht nur Software-Tests der neuen Komponenten durchzuführen, sondern auch Regressionstests aller bereits bestehenden (nur so kann man sicher sein, dass diese nicht durch Seiteneffekte beschädigt wurden). An dieser Stelle schließt sich übrigens der Kreis zu der oben erwähnten Anstellung von Testautomatisierern. Darüber hinaus sind aber auch nahezu alle anderen Bereiche der (agilen) Software-Produktion betroffen: Zuschnitt der User Stories, Code-Qualität, Dokumentation, etc.

Ob das alles wirklich so klappt ist von aussen natürlich schwer zu sagen, es klingt aber sehr, sehr vielversprechend. Und ich muss gestehen: da wäre ich gerne dabei.