OKR, Teams, Kollaboration – wie wir unsere Produkte weiterentwickeln
Fokussierung statt Ausfransen. Vernünftige Debatten statt Chef-Diktate. Teamdenken statt Silo-Ziele. Die Prinzipien modernen Software-Developments versprechen mehr Motivation bei gleichzeitig mehr Effizienz und Effektivität. Richtig angewandt und kombiniert, sollen sie die Produktentwicklung in Unternehmen so nach vorne bringen, dass Nutzerinnen und Nutzer gerne wiederkommen, dass die Produkte also mehr Geld abwerfen – und die Mitarbeiterinnen und Mitarbeiter Spaß haben.
Richtig angewandt und kombiniert: Das ist die Herausforderung. Im vergangenen Jahr haben wir in der Produktentwicklung des SPIEGEL die Ansätze der agilen Bewegung, des Lean Managements und verwandte Methoden wie OKRs für uns geprüft, Teile verworfen, andere Teile als klug erkannt, sie nach Stärken und Schwächen für unsere Organisation und Kultur analysiert, mit den nicht unerfolgreichen Methoden der bisherigen Entwicklung kombiniert, immer die Frage im Kopf: Was können wir vor allem von Digitalunternehmen methodisch noch lernen? Können wir klassische Konflikte um Prioritäten, Ressourcen, besser: Strategieentscheidungen öfter entschärfen und in ein noch fokussierteres System überführen?
Egal, mit wem wir inner- und außerhalb unseres Hauses über das Thema sprachen, alle kannten den Problem-Klassiker: „Chef A will X, Chef B will Y, die unterbesetzte Technik macht mal – und liefert am Ende Z. (Natürlich zu spät.)“ Uns ging es darum, die Ursachen ebensolcher Situationen grundsätzlich aufzulösen: um Abwehrhaltungen und Zielkonflikten vorzubeugen, die sich in Unternehmen schnell mit Mauscheleien und Misstrauen paaren, dann zu einer Arbeitskultur mit wenig Selbstverantwortung und Motivation führen können und schließlich zu einer gewissen Entscheiderfokussierung, die die Probleme verschärft.
Medienunternehmen wie wir sind an einer Stelle speziell. Wir haben nicht ein sozusagen simples Produkt wie ein Auto oder eine Kaffeemaschine. Bei uns hat der Begriff Produkt zwei Seiten. Die eine Seite ist das, was wir intern „Gefäß“ nennen, ob es sich nun um ein gedrucktes Magazin, eine App oder eine Website handelt: der Rahmen, in dem Inhalte stattfinden. Die andere, für den Erfolg letztlich wichtigere Seite sind ebenjene Inhalte, also die Beiträge in einem gedruckten Magazin, in einer App, auf einer Website. Ein Produkt ist nur beides zusammen, und deshalb war uns von Anfang an klar: Eine 1:1-Übertragung noch so bewährter Methoden aus der Industrie wird kaum gelingen.
Wir müssen sie adaptieren, um die grundlegende Abgrenzung von Redaktion und Verlag zu wahren – und zugleich die Zusammenarbeit dort zu ermöglichen, wo Gefäß und Inhalt in neuer Form verbunden werden müssen. Also in Zeiten digitaler Disruption an recht vielen Stellen.
Seit Jahresbeginn arbeiten nun Dutzende Kollegen im engeren Kreis der Produktentwicklung des SPIEGEL nach einem neuen Kooperationsmodell, dessen zentrale Elemente Austausch und Transparenz sind. Wir wollen hier entsprechend öffentlich darüber reden, auch um einen weitergehenden Austausch über Produktentwicklung gerade in Medienhäusern anzustoßen. Wir selbst haben in unseren Diskussionen der vergangenen Monate vom freizügigen Austausch mit Eigentlich-Konkurrenten deutlich profitiert – und mit viel Input von außen vier grundlegende Neuerungen eingeführt.
OKR: Erst Priorisierung, dann Eigenverantwortlichkeit
Moderne Programmierteams arbeiten oft agil, oft in Scrum-Logik im Zwei-Wochen-Takt. Die Unternehmen um die Teams herum dagegen machen meistens Jahres- und Mittelfristplanungen. Je technologiefokussierter ein Unternehmen wird respektive je dynamischer der Markt, in dem es sich bewegt, umso krasser kann sich der Zwiespalt zwischen der Kurzfrist- und der Langfrist-Taktung auswachsen. Jahresplanungen mit Großprojekten lassen sich mit der agilen Logik von Software-Entwicklung dann schwerlich überein bringen, wenn man sich diesem Konflikt nicht bewusst stellt, also die verschiedenen Entwicklungsziel-, Kosten- und zeitlichen Perspektiven übereinanderzulegen versucht. In vielen Unternehmen gibt es hybride Ausprägungen von Entwicklungsthemen, mal mit mehr Projekt- und mal mit mehr Prozesscharakter, mal eher agil gesehen und mal eher klassisch. Das muss nicht dramatisch enden, wenn man sich nur überlegt, wie man diese Sichtweisen zusammenbringen kann.
Seit Jahresbeginn arbeiten wir deshalb mit Objectives and Key Results (OKR) – einer jahrzehntealten, dennoch erst allmählich verbreiteten Strategie-Priorisierungsmethode, die Unternehmens- und Entwicklungsziele von Teams und Mitarbeitern verbindet. Die Leitung des Unternehmens gibt jedes Quartal meistens zwei bis vier übergreifende Objectives für alle Entwicklungseinheiten heraus: Ziele, die in einem Satz qualitativ klarmachen, was wieso zu entwickeln ist. Jedes Objective wird dann mit eindeutigen Key Results hinterlegt, die messbar machen, ob das Ziel erfüllt wurde.
Wir zum Beispiel entwickeln gerade einen umfassenden, grundlegenden Relaunch; ein klassisches Großprojekt, das sich schon viel zu lange hinzieht, ohne dass jemand wirklich etwas dafür kann. In Quartal 1 haben wir das Ziel ausgegeben: Wir wollen endlich alle Themen wissen, die wir für unseren Relaunch konzipieren müssen. Das war das Objective, und das passende Key Result lautete simpel: 100% aller Tickets sind identifiziert und grob konzipiert. Zu Beginn von Quartal 2 war das weitgehend geschafft. (Weitgehend bedeutet: 70 bis 80% – was nicht schlimm ist, denn OKR-Zahlenziele sollen überambitioniert gesetzt werden; wir hatten damit gerechnet, dass 100% unrealistisch sind und es 70 bis 80% werden.) Wir verkündeten das neue OKR: 100% aller Tickets werden im Laufe der kommenden Monate möglichst gleichförmig ready-to-go gemacht.
Wie isst man einen Elefanten? Indem man ihn zerlegt. OKR helfen dabei, gerade wenn man sie auf Großprojekte anwendet. (Und sehr viel ist in Medienunternehmen ein Großprojekt.) Denn sie gliedern riesige Themen in logische, überschaubare Drei-Monats-Happen, schaffen also für alle Beteiligten leichter sicht- und messbare Entwicklungspakete. Unser Relaunch zum Beispiel ist auf ein bestimmtes Quartal im Jahr 2020 terminiert, weil wir dann alte Technologie ausschaffen wollen. Jedes Quartal bis dahin ist grob vorgedacht.
Aus der klassischen Projektlogik betrachtet, gibt es also Meilensteine – die aber in der OKR-Logik keine wirklich fixen Meilensteine sind, sondern gewisse Zielkorridore, die für Management und Entwicklungseinheiten eine ebenso gewisse Kalkulierbarkeit sicherstellen. Zugleich haben wir jedes Quartal die Möglichkeit, die Anforderungen und Ressourcen zu justieren, um die große Deadline tatsächlich mit einem abgesprochenen Produkt-Scope zu schaffen.
An eigentlichen Projektthemen wiederum kann mit agilen Methoden gearbeitet werden – oder aber anderen, klassischeren, wie immer es sinnvoll ist: weil die OKR bloß das längerfristige Ziel aufs kleinere laufende Quartal rückkoppeln und dort einen Rahmen geben, aber keine Feinplanung. Das liegt am Quartal als Zeiteinheit. Es vermittelt zwischen der längerfristigen Planung des Unternehmens und den dynamischeren Entwicklungszyklen.
Letztlich funktionieren OKR deshalb auch mit fast jeder Projekt- oder Prozesssteuerungsmethode. Das Modell ist tendenziell agnostisch gegenüber den genauen Abläufen im Hintergrund, ob Scrum, Kanban, Gantt-Logik oder etwas anderes, was immer das jeweilige Team bevorzugt. Das Modell kann durch gute Schnittstellen und transparente Absprachen selbst Abteilungen einbeziehen, die keine OKR nutzen.
Die eigentliche Leistung des Modells ist, dass sich Entwicklungseinheiten und Chefs alle drei Monate auf die strategischen Prioritäten verständigen. OKR schlagen eine geistige Brücke zwischen strategischer und operativer Ebene, zwischen Strategie und Tun, und das motiviert: Wo ein gemeinsames Ziel, da findet man eine gemeinsame Richtung. Und wenn das gemeinsame Ziel schwierig zu finden ist, findet die Diskussion darüber statt, bevor jemand zu arbeiten beginnt – nichts mehr mit Chef A gegen Chef B.
Die Objectives sind weniger Diktat der Leitung, als sie aus einem gemeinsamen Gespräch über die Herausforderungen des Unternehmens und des Marktes entstehen. Die Entwicklungseinheiten legen auch deshalb zu Beginn jedes Quartals fest, wie sie die übergreifenden OKR für sich lesen und zu welchen Leistungen sie sich imstande sehen. Dieses Commitment ist essentiell: Jede Entwicklungseinheit unterschreibt nur, was sie nach eigenem Ermessen liefern kann. Engpässe werden so früher offensichtlich, und auch Aufwandstreiber in den Plänen – die Entwicklungseinheiten und die Unternehmensleitung können mit weniger Druck als früher das Dreieck von Zeit, Kosten und Entwicklungsziel justieren.
Und dann? Wenn die OKR vereinbart sind und nichts explodiert, also nichts wirklich Dringendes reindrängt, dann ist die Chef-Ebene für drei Monate raus. Ihr Job: Sie coacht die Entwicklungseinheiten weiter durch den Prozess und räumt Hindernisse oder Entscheidungsprobleme aus dem Weg. Die operativen Kolleginnen und Kollegen arbeiten im Kern selbstständig an den Objectives und Key Results. Sie sind deshalb: selbstverantwortliche Teams, im Wortsinne. Zumindest im Ideal. Weshalb die Motivation, Ziele zu erfüllen, viel höher ist als bei Teams, die nur so heißen.
Teams: Interdisziplinär statt Silos
Wenn die richtigen Leute richtig miteinander reden, gehen die richtigen Entscheidungen richtig schnell von der Hand – das beste Strategiesystem hilft nicht, wenn nicht gemeinsam an der Umsetzung gearbeitet wird. In die Konstruktion der richtigen Produktteams und deren Entwicklung ging bei uns mit der meiste Aufwand. Wer muss im Zentrum eines Teams dauerhaft beteiligt werden? Wer muss wann hinzugenommen oder zumindest gefragt werden, damit nicht die (in Teilen durchaus berechtigte) Silo-Denke beteiligter Abteilungen überwiegt, sondern alle alle Zielkonflikte kennen und trotzdem nach einer gemeinsamen Lösung streben?
Zuerst haben wir unsere Produktlandschaft – von der Webseite bis zu gedruckten Supplements – in sechs Entwicklungsstränge und damit Teams unterteilt:
- Core – der Entwicklungskern unserer Web-Angebote.
- Funnel – die Themen rund um Leserloyalität, von Newslettern über App-Features oder Präsenzen auf Plattformen.
- Pay – die Arbeit an SPIEGEL+ und anderen Bezahlmodellen.
- General – alle weiteren Produkte, die meist in Print ihren Ausgang genommen haben, aber meist auch digitale Präsenzen haben, und alle Line- und Business-Extensions.
- Video – alle digitalen Bewegtbildangebote.
- Audio und Voice – selbsterklärend.
In jedem Team ist neben dem Produktmanager, der die Fäden aller Mitglieder zusammenhalten soll, immer gleichberechtigt ein Vertreter der Redaktion beteiligt, genauer: der Entwicklungsredaktion, die in der integrierten SPIEGEL-Redaktion exakt für diese Themen gegründet wurde. Außerdem ist ein Technikkollege dabei – sofern die technische Umsetzung intern und nicht über Dienstleister funktioniert – und Kolleginnen und Kollegen aus den Marktbereichen, also der Anzeigenabteilung oder dem Vertrieb.
Diese interdisziplinäre Aufstellung, in der jeder zwingend die Rolle des anderen akzeptiert und antizipiert, ist der Schlüssel für konstruktive Gespräche über die Grenzen des eigenen Bereichs hinweg. Natürlich dauert es Monate, bis sich ein Team wirklich findet, und im jetzigen zweiten Quartal ist Teambuilding explizit eines unserer übergreifenden OKR-Ziele, damit Zeit dafür ist. In internen Feedback-Runden ist die Zustimmung zum neuen Zuschnitt dennoch klar positiv.
Nicht unwesentlich für eine gemeinsame Verantwortungskultur ist, dass in Produktteams je nach Thema jeder mal die Verantwortung hat und kein Mitglied eine dauerhafte Führungsrolle bekommt – auch kein Produktmanager, wie es in der Software-Entwicklung oft üblich ist. Die Rolle des Produktmanagements ist vor allem die Koordination, das Vernetzen, das Sortieren, das Moderieren und Zusammenhalten der Themen. Wenn das Wirtschaftliche, das Publizistische, die Lösungsorientierung oder vor allem die Leserorientierung (der sich unser gesamter Prozess unterordnen soll) mal aus dem Fokus geraten, dann sind Produktmanager in der Pflicht. Das mag nach viel Ressourcen für Prozessorganisation klingen, ist aber nach unserer Erfahrung gut investiert: weil so sichergestellt ist, dass die richtigen Leute richtig miteinander reden, also die richtigen Entscheidungen…, siehe oben.
Am Rande – wer verstehen will, wie wirklich fast jedes Teambuilding funktioniert, der „Herr der Ringe“ erklärt es besser als viele Anleitungen:
Prozess: Klare Rollen, vernetzte Expertise
In den Produktteams findet die Konzeptarbeit statt – nicht aber die eigentliche Entwicklung oder Weiterentwicklung unserer Produkte. Denn wir haben den rein konzeptionellen Prozess von der gestalterischen und technischen Umsetzung getrennt. Jedes Thema oder Ticket durchläuft drei Phasen.
- Konzeption in den Produktteams: Im ersten Schritt jeder Produktentwicklung können zwar Design- und Technikkollegen oder auch Querschnittskollegen wie Analyse, Marktforschung, Marketing und SEO beteiligt werden (wenn sie für die Konzeption hochrelevant sind). Aber im Kern geht es erst mal um saubere fachliche Konzepte durch die Produktteams selbst. Das ist die Hauptaufgabe dieser Teams. Was ein gutes fachliches Konzept ist, dafür haben sie inzwischen selbstverantwortlich Standards entwickelt, Schulungen organisiert, den gesamten Konzeptprozess verfeinert.
- UX- und Designgestaltung: In der digitalen Produktentwicklung (die hier im Fokus steht) werden finalisierte Konzepte anschließend in Designs umgesetzt. Dies übernehmen UX-Experten des Produktmanagements, Grafiker der Redaktion und eine externe Agentur. Sie ownen auch das neue Designsystem, das wir mit dem Relaunch entwickeln und das die Entwurfsarbeit stark systematisieren soll, um hohe Qualität zu garantieren. Zugleich bilden die Kolleginnen und Kollegen die Brücke zu den Software-Entwicklern.
- Technische Umsetzung: Erst was final designt und konzeptionell abgenommen ist, geht zur Programmierung an unsere Entwickler in der Techlab, in der IT oder an Dienstleister, mit denen wir zusammenarbeiten. Designer und Entwickler dürfen von komplexen Konzepten aus den Produktteams nicht überrascht werden – sie bekommen deshalb vorab bei jedem Thema die Frage gestellt, ob sie beim Konzept frühzeitig mitsprechen wollen. Dieses Recht haben auch, wie schon skizziert, …
- … die Querschnittsteams: Sie sind optionale Partner der Produktteams, also zum Beispiel die SEO-Experten, die Marketing-Abteilung, vor allem aber auch die Fachleute für Leseranalysen, Daten und Marktforschung. Nicht jedes Konzept muss mit Studien begleitet werden, nicht jedes Design muss User-Research-getestet werden, und nicht jedes muss nach der Umsetzung noch langfristig evaluiert werden. Aber bei vielen rentiert es sich. Indem bei jeder Konzeption die Frage nach der richtigen Begleitung durch diese Kolleginnen und Kollegen gestellt wird, ist die Beschäftigung mit Leserorientierung und Nutzertesting zum einen garantiert – wirkt aber zum anderen vor allem dort, wo sie am meisten Ertrag bringt. Denn die Analysten und anderen Querschnittsteams können sich durch die quartalsweise Konzeptpriorisierung ebenfalls effektiver fokussieren.
Überflüssig zu erwähnen, dass nach einem Quartal noch nicht alles rund läuft. Die Teams haben es jetzt aber selbst in der Hand, das System innerhalb der Teams und zwischen ihnen zu verbessern.
Entwicklungskonferenz: Wöchentliche Transparenz
Die Vernetzung innerhalb der Produktteams und mit allen Beteiligten entlang des Entwicklungsprozesses ist essentiell für den Erfolg unseres Systems. Genauso essentiell ist aber, dass es – bis auf seltene Ausnahmen – keine geheimen Themen und Absprachen gibt. Transparenz ist ein Grundgebot, damit Überschneidungen zwischen Teams rasch erkannt und Konflikte wegorganisiert werden können, damit gemeinsame Herausforderungen, Leerläufe, Überlastungen oder Entscheidungsfragen rasch die richtigen Kolleginnen und Kollegen erreichen.
Produktentwicklung ist so komplex wie letztlich jeder Veränderungsprozess mit vielen Beteiligten, und transparente Kommunikation hilft gegen die verbundenen Risiken. Wir haben dafür zwei zentrale Orte: erstens digitale Kanban-Boards für jedes Produktteam, auf denen alle OKR und die grob formulierten Konzepttickets stehen; zweitens sehr analoge wöchentliche Entwicklungskonferenzen, in denen über Neuerungen auf diesen Kanban-Boards informiert wird.
Keine Details, keine inhaltlichen Diskussionen, kein Shaming und Blaming, nur wesentliche Updates und Informationen aus den Teams: So funktioniert diese Runde mit regelmäßig 30 bis 50 Teilnehmern. Die Konferenz steht jedem im Haus offen, und sie macht das gesamte System letztlich am schnellsten begreifbar.
Wie die anderen Neuerungen begreifen wir die Entwicklungskonferenz nicht als statisches Instrument. Seit dem ersten Treffen ist sie mehrfach verändert worden – so stellen inzwischen nicht mehr nur die Produktteams ihre Arbeit vor, auch andere Themen unseres Relaunch-Großprojekts werden über Kanban-Boards und die Konferenz transparent gemacht:
- Die Veränderungen im Channel-Zuschnitt und in der weiteren Konstruktion der Webseite werden über ein Umbau-Board dargestellt,
- und die Pläne für neue Workflows im Redaktionsalltag sowie Neuerungen in den zugehörigen Tools – von der Themenplanung über den Texteditor bis zur Archivierung – zeigt ein Board „Editorial Solutions“.
In beiden Fällen handelt es sich eher um separierte Einzelprojekte oder Prozessthemen, jeweils in oder zwischen Redaktionsabteilungen, Technik-Bereichen und Produktteams. In beiden Fällen ist eine saubere Übersicht für alle wichtig. Aber deshalb sofort dauerhafte Produktteams für die Themen zu bauen, wäre in beiden Fällen nicht die richtige Antwort – weil es zumindest bisher nicht um längerfristige Entwicklungspfade mit denselben Beteiligten geht. Wir sprechen deshalb von „Netzwerken“, in denen diese Themen teils klassisch, teils agil bearbeitet werden, und bilden die Netzwerk-Themen als solche in der Entwicklungskonferenz ab.
An solcher Flexibilität und dem Willen zum Experimentieren liegt es aus unserer Sicht, dass wir mit unserem neuen System gute Erfahrungen machen. Und natürlich an der Summe der Veränderungen – nicht an einer allein.
I n den vergangenen Jahren hat der SPIEGEL mit Scrum, Kanban, klassischen Projektmethoden und den verschiedensten Prozessansätzen gearbeitet. Mal haben sie besser, mal schlechter funktioniert, und alle hatten längere Einführungszeiten, bis erste Ergebnisse sichtbar wurden. Unser neues System erlaubt die meisten Ansätze weiter, bindet sie aber anders zusammen, organisiert Teams anders und hat so binnen weniger Wochen die Arbeitsweise Dutzender Kolleginnen und Kollegen im engeren Kreis neu justiert. Es griff auch in die Abläufe von weit mehr als hundert weiteren ein, ohne dass es plötzlich mehr Probleme gab als vorher, im Gegenteil. Inzwischen treten frühere Strukturierungs- und Fokussierungsprobleme in den Hintergrund; dort, wo es sie gibt, werden deutlich öfter in Teams Antworten gefunden; die Methoden aus der digitalen Welt funktionieren adaptiert im Prinzip sogar in Print-Kontexten, in denen sie bisher in Verlagen kaum angewendet werden. (Wir haben es trotzdem ausprobiert und können es empfehlen.)
Wie wir uns die ersten Erfolge nach einigen Monaten erklären? Wir haben OKR nicht mit ideologischer Überhöhung eingeführt, sondern pragmatisch auf unsere Bedürfnisse und unseren Entwicklungsstand angepasst, sie außerdem mit der Neustrukturierung von Teams und Prozessen verwoben – und das zu einem für uns idealen Zeitpunkt:
- Ein hochpriorisiertes Großprojekt wie ein Relaunch hilft, Produktteams neu zu formen und dann auf simple Ziele zu fokussieren. Ohne die Relevanz und Dringlichkeit würde im lange geübten Alltag wohl nicht in so vielen Abteilungen und Bereichen des Hauses dieselbe Energie in eine umfassende Prozess- und Ressourcenjustierung investiert.
- Veränderungen in kleinen Iterationen sind in der Softwareentwicklung oft sinnvoll – ansonsten manchmal nicht. Dass wir zu Jahresbeginn gleichzeitig interdisziplinäre Teams neugegründet, fast alle Prozesse verändert, ganze Abteilungen umgebaut und Projekte neu zusammengesetzt haben, war ein großer Schnitt und der richtige, um die Ernsthaftigkeit des neuen Ansatzes zu verdeutlichen.
Was wir anders machen würden, wenn wir das neue System noch mal einführen würden? Wir haben unsere Teams nur kurz auf das neue System vorbereitet, im Wesentlichen nur im Januar, und dann im Februar gleich losgelegt. Wir haben anfangs auch nicht viel Zeit aufs Teambuilding verwendet, und wir haben weder Standards noch Konzeptmethoden intensiv besprochen. Mangelnde Vorbereitung führte zu viel Überlastung in den ersten Monaten, aber, und das ist die womöglich beste Erkenntnis: Jedes Team hat seinen Weg gefunden, die Überlastung rechtzeitig zu adressieren, Standards zu erarbeiten, sich mit Methoden aufzuschlauen und präzise um Unterstützung oder weiterführende Entscheidungen zu bitten.
Das Leitungspanel des neuen Systems – der Chef der Entwicklungsredaktion, der Produktchef, der Techlab-Chef und die Prozesschefin im Produktmanagement – haben dadurch jetzt weniger die klassische Chefrolle, sondern eher die Funktion, die Teams zu unterstützen. Und zu organisieren, dass nach den kommenden Quartalen der Prozess richtig rund läuft.
Dass das wirklich klappt, ist wiederum Aufgabe aller zusammen.
