Scrum – oder vom Abschaffen des klassischen Chefs

Wie im letzten Blog erwähnt sind die agilen Projektmanagement-Methoden momentan in aller Munde. Viele sehen in diesen Modellen eine zwingende Voraussetzung der digitalen Transformation. Doch wie laufen diese konkret ab? Heute schauen wir eine der Methoden stellvertretend an: Scrum. Dabei möchten ich darauf eingehen was der Grundgedanke von Scrum ist, warum es so häufig Anwendung findet und wie die sogenannten Sprints ablaufen?

Artefakte, Aktivitäten, Rollen, Backlog, Sprint und Product Increment… Wenn es um Scrum geht, wird man zwangsläufig auf diese Begriffe treffen. Zu Beginn klingt das alles ziemlich kompliziert – wenn man aber ein paar wenige Grundprinzipien verinnerlicht hat, ist eigentlich ganz einfach. Nachfolgend möchte ich heute Schritt für Schritt den Ablauf eines Sprints durchlaufen um Licht ins Dunkel zu bringen. Doch vorab eine kurze Einführung zu den Themen agiles Projektmanagement und Scrum.

 

Agiles Projektmanagement und Scrum

Die digitale Transformation bringt sicher viele neue Herausforderungen mit sich. Eine der Wichtigsten ist aber das schnelle Reagieren auf neue oder veränderte Kundenanforderungen. Wie im Blog „Schneller, flexibler, besser – wie agile Arbeitsformen die Unternehmen verändern“ bereits ausgeführt, basiert der Leitgedanke aller agilen Projektmanagement-Methoden auf dem Konzept hoher Flexibilität und Anpassung. Somit bieten sie Ideen und Werkzeuge zu oben gestellter Kernfrage der Digitalisierung. Statt ausführlicher Vorab-Planung, wie im klassischen Projektmanagement, wird hier iterativ, also Schritt für Schritt, vorgegangen. Im Fach-Jargon spricht man dabei von einem inkrementellen Vorgehen – wobei ein Inkrement das nächste (bereits nutzbare) Ergebnis darstellt. Das Projekt-Team organisiert sich zum grössten Teil selbst, während es den Projektmanager im traditionellen Sinne nicht mehr gibt.

 

Scrum ist ein weit verbreiteter Ansatz des agilen Projektmanagements und bezeichnet eine Vorgehensweise, die vor allem in Software-Entwicklungsprojekten angewendet wird. Immer häufiger findet der Ansatz aber auch ausserhalb der Software-Entwicklung statt und kann grundsätzlich bei allen Vorhaben mit Projekt-Charakter angewendet werden. Die Stärke liegt darin, dass es wenige Regeln gibt, die sich auf drei Artefakte (Lieferobjekte), drei zentrale Rollen und fünf Aktivitäten beschränken.

 

Die drei Rollen bei Scrum

Der Product-Owner:

In allen Projekten gibt es einen Auftraggeber, der die fachliche Sicht vertritt, Anforderungen stellt und die spätere Umsetzung seiner Wünsche im Hinblick auf Funktionalität, Benutzbarkeit (Usability), Performance und Qualität beurteilt. In Scrum ist das der Product Owner. Er trägt die Verantwortung dafür, dass die richtigen Anforderungen im Product Backlog stehen und dass sie in einer sinnvollen Reihenfolge abgearbeitet werden. Dadurch hat er massgeblichen Einfluss auf das Arbeitsergebnis. Aufgaben und Verantwortlichkeiten des Product Owners:

• • Pflege des Product Backlogs
  • vertritt fachliche Auftraggeberseite und Stakeholder
  • priorisiert Product Backlog Items so, dass der Business Value des Produkts maximal wird und die Möglichkeit früher Releases von Kernfunktionalität besteht
  • wohnt nach Möglichkeit den Daily Scrums bei, um sich (passiv) zu informieren
  • steht für Rückfragen des Teams bereit

Der Scrum-Master:

Agile Prozesse zeichnen sich durch eine hohe Dynamik aus. Damit der Prozess zielgerichtet verläuft und aus Dynamik nicht Chaos wird, gibt es den Scrum Master. Er ist sozusagen die Seele des Prozesses und sorgt dafür, dass die Regeln eingehalten werden. Der ScrumMaster ist Coach, Mentor, Moderator und VermittlerAufgaben und Verantwortlichkeiten des Scrum-Masters:

• • trägt Verantwortung für den Scrum-Prozess und dessen korrekte Implementation
  • ist ein Vermittler und Unterstützer (Facilitator)
  • strebt maximalen Nutzen und ständige Optimierung an
  • beseitigt Hindernisse
  • sorgt für Informationsfluss zwischen Product Owner und Team
  • moderiert Scrum-Meetings
  • hat die Aktualität der Scrum-Artefakte (Product Backlog, Sprint Backlog, Burndown Charts) im Blick
  • schützt das Team vor unberechtigten Eingriffen während des Sprints

Das Team:

Das Scrumteam sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne äussere Abhängigkeiten zu erreichen. Bei grösseren Projekten heisst das implizit, dass ein Team oftmals aus organisationsinternen und -externen Mitarbeitenden besteht. Innerhalb eines Sprints bleibt die Besetzung in der Regel konstant – über die verschiedenen Increments kann sich die Zusammensetzung aber ändern. Es ist das wichtigste Elemente bei Scrum, da es für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich ist. Das Team trägt es die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards und organisiert sich selbst. Es lässt sich von niemandem, (auch nicht vom Scrum Master) vorschreiben, wie es Backlogeinträge umzusetzen hat. Eine Optimale Grösse eines Scrum-Teams liegt zwischen 8-12 Mitarbeitenden.

 

Grundlegendes zum Sprint

Scrum zeichnet sich vor allem durch regelmässige und wiederholbare Arbeitsabläufe aus. Diese Zyklen werden Sprint genannt und sind zeitlich beschränkt. Ursprünglich wurden Sprints in der agilen Software-Entwicklung auf 30 Tage terminiert. Mittlerweile geht der Trend verstärkt in die Richtung von ein-, zwei- oder sechswöchigen Sprints. Dabei legt in der Regel die Komplexität der zu erbringenden Leistungen, die Dauer eines Sprints fest. Zum Beginn ist aber ein zwei wöchentliches Intervall ein guter Startpunkt und kann im Verlauf je nach Bedarf einfach angepasst werden.

Ziel eines jeden Sprints ist es, ein funktionsfähiges Zwischenprodukt, das auch Product-Increment genannt wird, zu entwickeln. Da die Zeit eines Sprints beschränkt ist, kann sich das Scrum Team jeweils nur auf die Weiterentwicklung der grundlegenden Funktionalität des Zwischenprodukts und auf kurzfristige Ziele konzentrieren. Dies motiviert auch den Product Owner, sich auf die wichtigsten Funktionen des Zwischenprodukts zu beschränken. Die einzelnen Sprints bauen immer aufeinander auf.

 

Der Ablauf eines klassischen Sprints

Vor dem Sprint

Der Startpunkt eines jeden Sprints ist das Sprint Planning Meeting. Dabei wird die nächste Increment, also der nächste Sprint, geplant. Im Sprint Planning Meeting wird entschieden, welche Anforderungen aus dem Product Backlog im Sprint bearbeitet werden sollen. Nachdem die Anforderungen ausgewählt wurden, werden sie im jeweiligen Sprint Backlog festgehalten und in Aufgaben, die innerhalb eines Tages erledigt werden können, unterteilt. Wichtig ist, dass der Product Owner allein über das „Was umgesetzt werden muss“ entscheidet. Das Scrum Team wiederrum bestimmt eigenständig, wie es diese Anforderungen umsetzten will.

Um Kontinuität und ein konzentriertes Arbeiten sicher zu stellen, können nach dem gemeinsamen Bestimmen des Arbeitsumfang eines Sprints (im Sprint Planning Meeting) keine weiteren Aufgaben mehr hinzufügen werden. Gewichtige Äussere Gründe wie z.B. den Projektstopp bilden hier natürlich die Ausnahme.

Während dem Sprint

Eine weitere wichtige Aktivität während eines Sprints ist das tägliche Scrum Meeting (Daily Scrum). Das Scrum Meeting findet jeden Tag zur selben Zeit und am selben Ort statt. Das Meeting wird oft im Stehen durchgeführt, um es nicht unnötig in die Länge zu ziehen. Grundsätzlich sollte der Daily Scrum nicht länger als 15 Minuten dauern. Der Daily Scrum ist eine Teambesprechung unter der Regie des Scrum Masters. Während der Product Owner eine wichtige Rolle in allen anderen Meetings (Aktivitäten) spielt, ist seine Anwesenheit im Daily Scrum nicht zwingend notwendig – dient diesem aber als Informationsquelle über laufende Aktivitäten.

Im Daily Scrum gibt jedes Teammitglied ein persönliches Feedback auf dieselben drei Fragen:

• Was habe ich gestern, also seit dem letzten Scrum Meeting, erledigt?
• Was werde ich bis morgen, also bis zum nächsten Scrum Meeting, bearbeiten?
• Welche Hindernisse stehen meinem Fortschritt im Weg?

Dabei geht es vor allem darum festzustellen, wie weit das Scrum Team mit der Bearbeitung der Anforderungen des Sprint Backlogs ist. Auftretende Schwierigkeiten werden so transparent und können zeitnah angegangen bzw. gelöst werden. Dabei profitieren die einzelnen Teammitglieder von den Erfahrungen anderer.

Nach dem Sprint

Nachdem ein Sprint abgeschlossen wurde, findet das sogenannte Sprint Review Meeting statt. Im Sprint Review Meeting wird das Zwischenprodukt dem Produkt Owner und ggf. weiteren interessierten Stakeholdern vorgestellt. Anschliessend wird der Product Owner überprüfen, welche Anforderungen des Sprint Backlogs erfüllt wurden. Anforderungen, die nicht erfüllt wurden, werden wieder in den Product Backlog aufgenommen. Zum Abschluss können anwesende Stakeholder ihr Feedback zum Zwischenprodukt einbringen. Daraus entstehen ggf. neue Anforderungen, die der Product Owner in den Product Backlog aufnimmt und priorisiert.

Zusätzlich findet zum Abschluss eines jeden Sprints ein Sprint Retrospective Meeting im Scrum Team statt. In dieser Besprechung steht nicht, wie im Sprint Review, das Produkt im Vordergrund, sondern die Arbeitsweise des Entwicklungsteams. Im Sprint Retrospective Meeting wird deshalb besprochen, was im Sprint gut geklappt hat, was nicht und wie es im nächsten Sprint besser gemacht werden kann. Dadurch soll die Arbeitsweise des Entwicklungsteams kontinuierlich von Sprint zu Sprint verbessert werden.

 

Und das ganze wieder von Vorne

Nachdem ein Sprint mit dem Sprint Review Meeting und dem Sprint Retrospective Meeting, abgeschlossen wurde, steht bereits der nächste Sprint an. Es werden so viele Iterationen nach dem oben beschriebenen Schema durchgeführt, bis das Endprodukt steht. Schematisch kann Scrum wie folgt dargestellt werden:

 

 

 

 

In eigener Sache: Interessieren Sie sich für Digitalisierung und digitale Transformation? Zögern Sie nicht, regelmässig auf unserer B2S University nach spannenden Informationen zu suchen oder schauen Sie bei einem unserer „Digital Afterworks“ vorbei.