Agile Medien (trotz Handicap)

Vor kurzem tauchte ich für zwei Tage in den Redaktions-Alltag der Oberösterreichischen Nachrichten ein: einen Tag in der Lokal-Redaktion, einen Tag in der Wirtschaftsredaktion.

Was ich mir erwartete: besser verstehen, was ein Redakteur so macht, wie er recherchiert, was ihm wichtig ist, wie Artikel entstehen, wie die Zeitung entsteht.

Was ich erlebte: die OÖN sind uns agilen Software-Entwicklern in vielerlei Hinsicht SEHR ähnlich!!! Es fehlt nur eine wichtige Zutat, die wir ihnen voraus haben.

Ein paar Beispiele sollen das verdeutlichen:

  • Satisfy the Customer. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
    Wenn man da “software” durch “information” austauscht, passt es wohl haarscharf.
  • Embrace Change. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
    Wenn sich was Unerwartetes tut, wird die Zeitung umgestellt, bis hin zur Neugestaltung der Seite 1 – auch noch spät in der Nacht.
  • Frequent Delivery. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
    Tja, die OÖN ist viel agiler als alle Software-Entwickler zusammen, sie bringen jeden Tag eine Zeitung heraus.
  • Frequent Synchronization. Gleich in der Früh im Team (quasi ein Daily Scrum), dann auch gleich Team-übergreifend (quasi ein Scrum of Scrums), nach ein paar Stunden nochmals im Team und übergreifend, am Abend nochmals. So kurze Iterationen ergeben sich aus der täglichen Auslieferung.
  • Pair Programming bzw. Reviews. Jeder Artikel wird von einem zweiten korrekturgelesen.
  • Paper Prototyping / Sketching. Die zu befüllenden Seiten werden im Team skizziert (“aufgezogen”).
  • Design Patterns. Für die Vereinheitlichung des Layouts und zur Unterstützung der Blatt-Melodie verwenden sie wiederverwendbare (anpassbare) Seiten-Layouts.
  • Working Prototype. Ein Platzhalter – zuerst leer – wird sogleich mit plausiblem Text befüllt, damit etwas vorhanden ist, das in den Druck gehen könnte. Wenn Zeit bleibt, wird der Artikel noch verbessert bzw. ergänzt.
  • Continuous Delivery. Im Print-Bereich gibt’s eine Ausgabe pro Tag. Im Online-Bereich gehen ständig Artikel raus. Der Live-Ticker berichtet im Minuten-Rhythmus. Da sind die OÖN allen agilen Software-Entwicklern weit voraus.
  • Technical Excellence. Die Redakteure haben den unbedingten Willen zu gutem Stil, zu guter Recherche usw.

Was sie (soweit ich’s verstanden habe) nicht haben: das Sicherheitsnetz der automatisierten Tests.

Wir entwickeln Software testgetrieben, d.h. überlegen uns zuerst den Test, schreiben danach erst das Stück Code, das notwendig ist, um den Test gutgehen zu lassen.
Die Redakteure versetzen sich wohl bei jedem Artikel in den Leser hinein, aber sie haben keinen automatischen Mechanismus, der ihnen sagt, wann sie fertig sind.
Das einfachste Kriterium ist natürlich: ist der Artikel lang genug? Wenn alle Artikel lang genug sind, sind alle Seiten voll, ist die Zeitung voll. Nur sagt dieses Kriterium halt noch nichts über die Qualität aus.

Automatisierte Unit-Tests erlauben uns Software-Entwicklern, kleinere und auch größere Änderungen vorzunehmen (“Refactoring”). Sie bieten uns das Sicherheitsnetz, das uns nach der Umstellung sagt: “Es geht noch immer alles, was vorher gegangen ist.”
Änderungen und Umstellungen sind für einen Redakteur viel mühsamer und gefährlicher als für uns. Die Redaktionssysteme unterstützen Refactoring nicht – und es gibt keine automatisierten Tests, die dem Redakteur anzeigen, dass noch immer alles passt.

Ich möchte mir nach diesen 2 Tagen nicht anmaßen, die Arbeit eines Medienunternehmens verstanden zu haben, aber mein Resümee ist:

  • Die OÖN arbeiten in weiten Bereichen nach denselben agilen Prinzipien wie wir Software-Entwickler. In Bezug auf “Frequent Delivery” oder gar “Continuous Delivery” sind sie uns sogar weit voraus.
  • Wir Software-Entwickler haben allerdings den Luxus der automatisierten Unit-Tests. Wir können dadurch sorglos Änderungen und Umstellungen durchführen. Unsere Werkzeuge unterstützen testgetriebene Entwicklung und Refactoring natürlich schon viel besser.
  • Es ist erstaunlich, dass auch ohne so ein Sicherheitsnetz Zeitungen täglich erscheinen. Allerdings ist es verständlich, dass der Spätdienst ohne Sicherheitsnetz (naturgemäß) weniger beliebt ist – mit den hochriskanten Änderungen und Umstellungen bei Notfällen.
  • In Bezug auf “testgetriebene Entwicklung” und “Refactoring” könnte die Medienbranche noch einiges von uns agilen Software-Entwicklern lernen.

Es waren jedenfalls für mich zwei hochinteressante Tage bei den Oberösterreichischen Nachrichten, die mir geholfen haben, viel besser zu verstehen, wie Medienhäuser funktionieren.

Zur Nachlese über agile Praktiken: Marc Bless hat eine interessante Serie von Artikeln über Agile Practices geschrieben.

Vorheriger Beitrag
Boy, I’m really glad I influenced the world!
Nächster Beitrag
Neue CCC-Website

Related Posts

No results found

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren

Menü