Die Einführung agiler Softwareentwicklung und von Scrum bei Heise, Teil 1

Das Entwicklerteam von heise online berichtet von ihrer agilen Transition der Entwicklungsprozesse und wie dabei das "heise-Scrum" entstand.

In Pocket speichern vorlesen Druckansicht 295 Kommentare lesen
Lesezeit: 6 Min.
Von
  • Stephen Fischer
Inhaltsverzeichnis

In den nächsten Folgen unseres heise-WebDev-Blogs soll es um unser agiles System gehen. In diesem ersten Teil des "Themenblocks Agile" stelle ich den Werdegang vom "heise-Scrum" vor – sozusagen unsere agile Transition.

Im Mai 2017 starteten wir mit einem mehrtägigen Scrum-Workshop in die agile Welt und waren damit in der Verlagsbranche zeitlich eher im hinteren Feld. Vorher waren unsere Teams aufgeteilt in Frontend-, Backend- und CMS-Teams. Dazu kamen Konzeption und Design. Die Teams wurden jeweils von Teamleitern geführt, die auch disziplinarisch Vorgesetzte waren.

Mehr Infos

Dieser Blogbeitrag ist Teil einer Serie

Hier sind die anderen Teile zu finden:

Teil 2 - Rollen und Werkzeuge

Teil 3 - Die Events

Die Prozesse waren auf projektorientiertes Arbeiten und Wasserfallvorgehen ausgelegt.

Die klassischen Probleme und Reibungspunkte dieser Arbeitsweise traten auch bei uns auf:

  • Entwickler bekamen die Pläne spät zu sehen, weil schon lange vorher Konzeption und Design mit den Auftraggebern zusammensaßen.
  • Entscheidungen zur Umsetzung konnten nicht mehr nachvollzogen, mussten aber oftmals durchgezogen werden, weil sie eben schon lange mühsam ausdiskutiert worden waren.
  • Unsere "Kunden" waren und sind zwar "in-house", trotzdem wurde erst mal sehr lange entwickelt, bis sie das Werk zu Gesicht bekamen, und der Satz "Das habe ich mir aber ganz anders vorgestellt!" wurde in unseren Reihen zum geflügelten Wort.
  • Die langlaufenden Projekte bündelten viel Arbeitskraft. Tagesgeschäft blieb liegen. Zwischendurch mal zwei Wochen an etwas anderem zu arbeiten war undenkbar. Das ließ viele Kolleginnen und Kollegen außerhalb der Webentwicklung mit selbst kleineren Aufträgen und Wünschen hilflos zurück. Die behalfen sich oftmals mit quervergebenen Aufgaben an "Lieblingsentwickler" mal eben per Telefon. Die verließen dann (oft heimlich) den Projekttunnel, um mal eben was für den verzweifelten Redaktionskollegen zu basteln oder zu reparieren.
  • Oftmals hatten wir sehr große und umfangreiche Systeme gebaut und in der täglichen Anwendung stellte sich heraus, dass deren Benutzung und Pflege zu viel Arbeitskraft bei unseren Auftraggebern band. Es entstand der eine oder andere "Elefantenfriedhof", in den viel Zeit und Herzblut geflossen war.
  • Große Arbeitspakete gingen in einem Schwung online und stellten damit Leser und Redakteure vor eine komplett veränderte Seite auf der man sich erst mal neu zurechtfinden musste.
  • Die Teamstruktur nach Themen sorgte für wenig interdisziplinären Austausch.
  • Der Projektfortschritt war selbst innerhalb der Webentwicklung für viele nicht gut einschätzbar. Von außerhalb war es unmöglich zu erahnen, auf welchem Stand das Projekt ist.

In der Rückbetrachtung klingt das schlimmer und ineffizienter, als es war. Das projektorientierte Arbeiten und die Fachteams hatten und haben auch durchaus ihre Reize. So ein Projekttunnel über ein halbes Jahr kann auch etwas sehr Schönes sein. Auch die gebündelten Rollouts von Software, in die Tausende Arbeitsstunden geflossen sind, waren Festtage, die mit einer gesunden Mischung aus Vorfreude und Spannung herbeigesehnt worden waren.

Nicht zu vergessen: Über so lange Zeit mit der gleichen Redaktion an etwas zu feilen, es rechtzeitig fertig zu bekommen und in einem Schwung auszurollen hat uns alle zusammengeschweißt. Zur Belohnung sind wir dann nicht selten mit der Redaktion auf Verlagskosten essen gegangen.

In den Tagen danach hatte man immens gebündelte Benutzer-Rückmeldung im Forum. Die führten natürlich zu Nacharbeiten, aber trotzdem entstand so immer ein größerer Schlusspunkt mit Pauken, Trompeten, Fackeln und Mistgabeln. Mein erster Launch war 2011 ein Relaunch des Bereichs heise Netze (Wayback-Machine-Link) und wird mir immer in guter Erinnerung bleiben als der Tag, an dem ich etwas weniger grün hinter den Ohren wurde.

Die Fachteams wiederum sorgten für intensiven Austausch der Entwickler innerhalb ihrer Disziplin. Sie waren das Expertengremium schlechthin und Brutkammern für zukünftige Entwicklungen.

Trotzdem: Wir alle wussten um die Vorteile agiler Arbeitsweisen und trugen die Entscheidung mit. Die Einführung von Scrum war in vielen Unternehmen eine Revolution von unten nach oben, wenn man es hochtrabend ausdrücken will. Sachlicher gesagt war es bei uns zumindest ausdrücklicher Wunsch eines Großteils der Entwickler. Sicherlich wussten wir alle nicht zu 100 Prozent, worauf wir uns einlassen, und es gab auch leise Zweifel. Insgesamt hatte ich nach einigen Tagen Workshop aber den Eindruck, dass der Veränderung mit offenen Armen entgegengetreten wurde.

Die Geschäftsführung und der damalige CTO Michael Wilde trieben aber ebenso die Veränderung voran. Letzterer konnte den vollständigen Übergang zur Agilität leider nicht mehr miterleben. Dass dem Wunsch der Entwickler nach Agilität von Vorgesetzten und Geschäftsführung nachgekommen wird, ist nicht so selbstverständlich. Vollständig autonome und selbstorganisierte Teams, wenig Hierarchie und die Abneigung agiler Systeme gegen Deadlines, die nicht das Sprint-Ende meinen, sind sicherlich in vielen Unternehmen ein rotes Tuch für die Entscheider. Insofern freue ich mich, dass in unserem Fall die Umstellung auch außerhalb der Webentwicklung begrüßt wurde.

Nachdem wir in groben Zügen die agilen Paradigmen eingetrichtert bekommen und neue interdisziplinäre Teams formiert hatten, begann die Phase, in der wir versuchten, das Gelernte im Alltag anzuwenden. Ein Team wurde dabei weiterhin regelmäßig von einem Agile-Coach begleitet. Die anderen versuchten es, auf eigene Faust einfließen zu lassen. Ziel davon war es, mit dem begleiteten Team einen Multiplikator zu haben. Die Mitglieder sollten ihr Wissen dann an die anderen Teams weitergeben.

Dieses Experiment lief bis Ende 2017 und führte uns mal näher heran, mal weiter weg von echtem agilen Arbeiten. So oder so wurde das Kapitel Anfang 2018 geschlossen. Wir kamen zu einem zweiten Agile-Workshop zusammen und bildeten anschließend nochmal drei neue Teams, die auch bis heute bestehen.

Mit den Erfahrungen aus dem "Probebetrieb" konnten wir etwas konkreter an unseren Vorstellungen von Agilität arbeiten. Mit Georg Nold hatten wir einen neuen CTO mit Erfahrung in agiler Transition und dem Willen, den Weg weiterzugehen.

Was daraus entstanden ist und wie nah das denn jetzt am agilen Manifest steht, berichte ich im zweiten Teil dieses Blog-Artikels. (sfi)