Scrum im Verlagswesen

Was ist Scrum?

Scrum ist ein ursprünglich aus der Software-Entwicklung stammendes Rahmenwerk zur Entwicklung komplexer Produkte unter den Bedingungen großer Offenheit/Unklarheit hinsichtlich der sich erst im Prozess selbst herausschälenden genauen Produktanforderungen. Der Erfolg von Scrum im Software-Design – gleichermaßen bei Startups wie z.B. Spotify oder Airbnb, aber auch bei Konzernen wie SAP oder Otto Group – hat immer mehr Unternehmen dazu bewogen, Scrum auch in ganz anderen Bereichen einzusetzen. Hier bietet sich das Verlagswesen in besonderer Weise an, weil es sowohl hinsichtlich der zu entwickelnden Medien als auch bezüglich der beteiligten Expertisen und der Arbeit in Teams immer stärker mit der Software-Programmierung konvergiert.

Der Ansatz von Scrum ist im Kern simpel: Durch die eindeutige Festlegung von drei unterschiedlichen Rollen sowie die Aufstellung weniger elementarer Regeln der Zusammenarbeit wird ein Maximum an Flexibilität des Prozesses garantiert. Die Aufteilung des üblicherweise sequentiellen Entwicklungsprozesses in kurze Iterationen von max. einem Monat Länge (sog. „Sprints“) erlaubt es, zum einen zu jedem Zeitpunkt ein vorzeigbares, wenngleich noch nicht finales „Produkt“ zeigen und testen zu können sowie zum anderen jederzeit Feedback und neue Ideen in den Prozess einfließen zu lassen. Dabei basiert Scrum auf der Erkenntnis, dass der klassische Entwicklungsprozess („Wasserfall“) mit seinen aufeinander folgenden Phasen, üblicherweise mit einer langen Konzeptionsphase beginnend, kaum die Möglichkeit zur flexiblen Anpassung im weiteren Verlauf bietet. Bei dieser Arbeit entlang des „Wasserfalls“ neigt das Team dazu, sich schärfende und weiterentwickelnde Kundenwünsche nur als Störung anzusehen und so weit wie möglich auszublenden, um den definierten Zeit- und Budgetplan nicht zu gefährden. Häufig kranken Produkte genau hieran, während erfolgreiche Produkte teilweise noch im Entwicklungsprozess durch die Offenheit für Feedback und neue Erkenntnisse ganz andere als ursprünglich angestrebte Richtungen genommen haben. Vor allem in den Bereichen Haptik und Usability erzielen Scrum-Projekte so i.d.R. deutlich bessere Ergebnisse.

“Mit seinem iterativen, offenen Ansatz reduziert Scrum nicht zuletzt auch das Risiko.”

Mit seinem iterativen, offenen Ansatz reduziert Scrum nicht zuletzt auch das Risiko, investierte Zeit und Mittel an Stakeholder-Interessen oder Kundenwünschen vorbei zu entwickeln, wie dies beim klassischen „Wasserfall“-Prozess leicht geschehen kann, da i.d.R. erst spät im Prozess ein Produkt oder Prototyp vorliegt.

Die Arbeit gemäß Scrum lässt sich im Wesentlichen wie folgt zusammenfassen:

• Dem Entwicklungsteam wird eine klare Aufgabe bzw. Vision gestellt.
•  Alle gewünschten Produkteigenschaften werden in einem Dokument/Datenbank („Product Backlog“) in Form von „user stories“ zusammengestellt. Das „Product Backlog“ ist dabei ein lebendes Dokument, das sich stetig verändert bzw. weiterentwickelt.
• Der Prozess wird in einzelne „Sprints“ von max. einem Monat aufgeteilt, deren Ergebnis immer ein potentiell auslieferbares Produkt ist. Zu diesem Produkt können damit immer wieder Anregungen und Feedback eingeholt werden, sowohl innerhalb des Unternehmens, als auch seitens des Auftraggebers oder potentieller Kunden.
• Das Entwicklungsteam priorisiert die Arbeit gemäß dem Marktwert der einzelnen Produkteigenschaften, so dass „wertvolle“ und relevante Features immer zuerst realisiert werden.
• Das Entwicklungsteam organisiert seine Arbeit komplett eigenständig und realisiert in einem „Sprint“ eine zuvor ausgewählte Anzahl von Produkteigenschaften.
• Der Entwicklungsprozess und der Status des zu entwickelnden Produkts sind jederzeit für die gesamte Organisation vollständig transparent.
• Am Ende eines jeden „Springs“ reflektiert das Team sowohl inhaltlich die realisierten Produkteigenschaften als auch methodisch die Arbeitsweise im Team.

Neben dem autonom arbeitenden Entwicklungsteam sieht Scrum zwei weitere Rollen vor:

• Der Product Owner vertritt alle Interessengruppen außerhalb des Projektteams. Seine Aufgabe ist es, eine klare Vision vorzugeben und – mit dem Entwicklungsteam – zu spezifizieren, welche Produkteigenschaften realisiert werden müssen, um geschäftlichen Erfolg zu haben. In diesem Sinne ist der Product Owner für die Erzielung eines maximalen Produktwertes verantwortlich.
• Der Scrum Master unterstützt das Team bei der Einführung und Anwendung von Scrum und wirkt als „Facilitator“ im Prozess.

Charakteristisch für Scrum sind darüber hinaus eine Reihe von klar strukturierten, zeitlich begrenzten Meetings, u.a. der „Daily Scrum“ oder „Daily Standup“ von max. 15 Minuten zu Beginn eines jeden Tages, bei dem sich die Teammitglieder über die jeweils am Tage anstehenden Aufgaben sowie Probleme verständigen.

Bewertung

Die Stärken von Scrum liegen v.a. in der jederzeitigen Offenheit des Prozesses für die Weiterentwicklung der Vorstellungen zum Produkt sowie der hiermit einher gehenden Reduktion des Risikos, in einem langen Entwicklungsprozess Zeit/Ressourcen zu verlieren, indem an den tatsächlichen Kundenbedürfnissen vorbei gearbeitet wird. Scrum erweist sich darüber hinaus auch als i.d.R. schneller als klassische „Wasserfall“-Prozesse, u.a. auch weil durch die klare Rollenfestschreibung und die eindeutigen Regeln viele Missverständnisse sowie zeit- und ressourcen-aufwändige Abstimmungsprozesse vermieden werden. Damit verkürzt sich die für viele Anwendungen kritische Zeit bis zum Markteintritt („time-to-market“).

Die extrem hohe Autonomie des Teams, das die eigene Arbeit im Sinne einer konstant hohen, aber extreme Spitzen vermeidenden Arbeitsbelastung organisiert, erhöht zudem die Mitarbeiterzufriedenheit. Darüber hinaus fördert Scrum auch allgemein die Innovations- und Lernfähigkeit sowie die „Beta-Kultur“ von Unternehmen; der Ansatz ist überdies anschlussfähig für andere agile Vorgehensweisen und Tools, z.B. Design Thinking oder Business Model Canvas.

Scrum setzt Aufgabenstellungen voraus, die im Team zu lösen sind und sich für eine iterative Herangehensweise eignen. Scrum erfährt seine Grenzen, wo Produkte im Wesentlichen nur von einem Mitarbeiter/Autor erstellt werden oder sich nicht in sinnvolle Iterationen aufteilen lassen. Darüber hinaus setzt Scrum unabdingbar die Bereitschaft aller Beteiligten, nicht zuletzt des Managements, voraus, sich an die Scrum-Regeln und Rollen zu halten.

“Scrum funktioniert ganz oder gar nicht.”

Gerade die bestechende Stringenz der Scrum-Regeln und –Rollen wird jedoch zur Schwäche, wenn das Rahmenwerk nur teilweise oder oberflächlich angenommen wird. In diesem Sinne funktioniert Scrum „ganz oder gar nicht“. Gegenüber Startups stellt es gerade etablierte Unternehmen von Herausforderungen, diesen Paradigmenwechsel hinsichtlich des Rollenverständnisses zu vollziehen.

Fazit

“In dem Maße, in dem Verlage immer stärker Entwickler und Betreiber digitaler Content-Plattformen werden, wird sich Scrum auch im Verlagswesen durchsetzen.”

Sofern die Bereitschaft aller Beteiligten vorhanden ist, überkommene Rollen und Arbeitsweisen in Frage zu stellen, ist Scrum die Herangehensweise der Wahl, um komplexe Aufgabenstellungen mit großer Offenheit hinsichtlich der genauen Ausgestaltung von Produkteigenschaften in effizienter, risikoverantwortlicher Weise im Team anzugehen. In dem Maße, in dem Verlage immer stärker Entwickler und Betreiber digitaler Content-Plattformen werden, wird sich Scrum auch im Verlagswesen durchsetzen. Für etablierte Verlage ist die versuchsweise Einführung von Scrum in einzelnen, stark eigenständig arbeitenden Produktentwicklungsteams sinnvoll, um die Eignung des Ansatzes für das Gesamtunternehmen zu validieren.

Dieser Artikel entstand als Gastbeitrag für den Newsletter der auf das Verlagswesen spezialisierten Unternehmensberatung Heinold, Spiller & Partner.