Praxisbeitrag

Projektentwicklung mit Scrum: Geht das alles auch ein bisschen schneller?

Die Realisierung von Projekten in Unternehmen braucht ihre Zeit. Wer diesen Prozess beschleunigen kann, spart Ressourcen und letztlich Geld. In der IT-Branche ist eine Methode entstanden, die auch Verlagen helfen kann.

Scrum heißt auf Englisch so viel wie Gedränge, ist aber ein kürzeres Wort – womit man schon beim Thema ist. Denn das Wort Scrum ist auf jeden Fall noch viel kürzer als das Begriffsmonster „Agiles Projektmanagement“, steht aber genau dafür: Für eine Methode, Entwicklungsprozesse zu beschleunigen. Diese Methode stammt aus der IT-Branche, wird aber auch in Industrieunternehmen seit Jahren erfolgreich praktiziert – und kann auch Verlagen helfen, Projekte schneller zum Abschluss zu bringen.

Vorüberlegung: Worum es geht

Um den Ansatz der Scrum-Methode zu verstehen, muss man sich zunächst in Erinnerung rufen, dass ein Entwicklungsprozess aus einer Reihe von Teilprozessen besteht, die oft auf komplizierte Weise mit einander verknüpft sind, d.h. einander voraussetzen oder auslösen. Theoretisch ist einfach erklärt, wie man diese Kette von Prozessen beschleunigt: Indem man sie nicht nacheinander, sondern gleichzeitig ablaufen lässt. In der Praxis aber machen viele Unternehmen schon bei der Anschaffung von Filtertüten für die Büro-Kaffeeküche die schmerzhafte Erfahrung, dass das leichter gesagt ist als getan.

Angesichts solcher Erfahrungen beruht die Scrum-Methode auf einer im Grunde einfachen Annahme: Wenn man will, dass es schnell geht, muss man die geschriebenen und ungeschriebenen Regeln, die sich über Jahre in einem Unternehmen herausgebildet haben, beherzt ignorieren und nach neuen Regeln spielen bzw. spielen lassen. Denn tatsächlich beschreibt man die Scrum-Methode am besten wie eine Spielanleitung.

Die Rollen

Im Scrum-Prozess gibt es 3 Akteure:

  • Team: „Im Mittelpunkt von Scrum steht das autonome, crossfunktionale Entwicklungsteam, das ohne Projektleiter auskommt“, erläutert der Scrum-Coach Stefan Roock vom IT-Dienstleister It-Agile. Heißt konkret: Jede vom Projekt tangierte Abteilung sollte einen Vertreter im Team haben. Ideale Größenordnung: 3 bis 9 Mitglieder.
  • Scrum Master: Diese Rolle ist nicht zu verwechseln mit einem Projektleiter im klassischen Sinne, denn der Scrum Master gehört selbst gar nicht zum Team. Seine Aufgabe ist, es in organisatorischen Fragen zu unterstützen und über seine Auto­nomie zu wachen, ihm also – salopp aus­gedrückt – den Rücken frei zu halten.
  • Product Owner: Bei aller Autonomie soll das Entwicklungsteam natürlich nicht ziellos vor sich hinwursteln. Deswegen gibt der (ebenfalls außenstehende) Product Owner die Richtung vor. „Ihm kommt die Aufgabe zu, Anforderungen zu definieren, zu priorisieren und gegebenenfalls auszutauschen“, erklärt Roock.
Die Regeln

Das Kernelement des Entwicklungsprozesses à la Scrum sind die Sprints. „Das sind ungestörte Entwicklungszyklen von wenigen Wochen, in denen Änderungen an den Anforderungen nicht zugelassen sind“, erklärt Roock. Das läuft konkret so ab:

  • Der Product Owner erklärt dem Team die Anforderungen. Ziel des Sprints ist ein möglichst fertiges Produkt. Nach dem Briefing aber hält sich der Product Owner für die Dauer des Sprints raus.
  • Wie lange die Sprints dauern sollen, wird je nach Gegebenheiten, Anforderungen und Größe des Projekts festgelegt. In der Regel sind es 1 bis 4 Wochen. Wichtig: Die festgelegte Zeit wird nicht verlängert.
  • Die Vorgaben hinsichtlich des Produkts, das entwickelt bzw. des Ziels, das erreicht werden soll, werden im Product Backlog festgehalten, der zwischen mehreren Sprints überarbeitet und ergänzt wird.
  • Zur Feinjustierung wird vor dem Start jedes Sprints ein Sprint Backlog aufgesetzt. Darin sind die Schritte aufgezeichnet, die während der Arbeitsphase voraussichtlich nötig sein werden.
  • Für die Mitglieder des Entwicklungsteams gibt es ein Feedback in Form des Daily Scrum. Auch für dieses tägliche Treffen des Scrum Masters mit dem Entwicklungsteam gibt es feste Regeln: Das Daily Scrum wird im Stehen abgehalten und dauert höchstens 15 Minuten. In dieser Zeit beantwortet jedes Teammitglied die 3 Fragen: a) Was habe ich seit dem letzten Daily Scrum erledigt? b) Was hat mich dabei behindert? c) Was werde ich bis zum nächsten Daily Scrum tun?
  • Das „kleine Feedback“ während des Sprints wird bewusst knapp gehalten, denn das „große Feedback“ findet nach dem Sprint statt: In einem Sprint Review wird das Ergebnis (Product Increment) vorgestellt, und zwar ergebnisoffen. In einer Sprint Retrospektive wird gesondert der Arbeitsprozess analysiert.
Einwand: Nur was für die Großen?

Ein Scrum-Prozess, der nach diesen Regeln abläuft, greift tief in die gewohnten Abläufe eines Unternehmens ein. Eine konsequente Umsetzung können und wollen sich kleinere Firmen oft nicht leisten.

Muss auch nicht sein. Viele Unternehmen bedienen sich pragmatisch aus dem Scrum-Baukasten. Für solche Fälle empfiehlt Scrum-Coach Roock allerdings:

  • Wenn die Teammitglieder parallel an anderer Stelle weiterarbeiten, sollten sie zumindest zum Start des Projekts für einige Tage „aus dem Tagesgeschäft herausgezogen werden“, damit Teamgeist entsteht.
  • Wenn die Teammitglieder nur einen Teil ihrer täglichen Arbeitszeit auf die Entwicklungsarbeit verwenden können, sollten sie das alle zur gleichen Zeit tun.

Wichtiger als das sklavische Einhalten der Regeln ist für Scrum eine neue Fehler- und Unternehmenskultur: Vorgesetzte müssen lernen, zeitweise die Kontrolle abzugeben. Und sie müssen akzeptieren, dass das Ergebnis eines Sprint Reviews auch sein kann, dass das ganze Vorhaben sich nicht lohnt.

David Wengenroth

wengenroth@buchreport.de

Scrum-Wörterbuch

  • Daily Scrum Tägliches Treffen, bei dem sich die Mitglieder des Entwicklungsteams über Fortschritte und Hindernisse austauschen
  • Entwicklungsteam Autonome, crossfunktional besetzte Gruppe, die für das Erreichen der Sprintziele verantwortlich ist.
  • Product Backlog Liste der Anforderungen an den gesamten Entwicklungsprozess, geordnet nach Priorität
  • Product Increment (Teil-)Produkt bzw. Ergebnis, das nach Ende eines Sprints präsentiert wird Product Owner Team-Externer, der vor und zwischen den Sprints die Anforderungen an das Team definiert und ggf. ändert
  • Scrum Master Team-Externer, der das Team organisatorisch unterstützt und eine störungsfreie Arbeit gewährleistet
  • Sprint Ungestörter Entwicklungszyklus von 1 bis 4 Wochen
  • Sprint Backlog Liste der Aktivitäten, die nötig sind, um die Anforderungen aus dem Product Backlog im aktuellen Sprint umzusetzen
  • Sprint Planning Meeting Gemeinsame Sitzung von Team und Product Owner vor dem Start des Sprints, bei dem Ziele und Anforderungen besprochen werden
  • Sprint Retrospektive Meeting nach Abschluss eines Sprints, in dem die Arbeitsweise im zurückliegenden Sprint analysiert und mögliche Verbesserungen für die nächsten Sprints besprochen werden
  • Sprint Review Meeting nach Ende des Sprints mit Kunden/Nutzern o.ä., bei dem das Ergebnis präsentiert und Feedback eingeholt wird

Quelle: buchreport