Agil arbeiten mit Scrum – datenwerks Lieblingsmethoden

Scrum – das ist nicht nur eine Formation im Rugby, sondern auch eine Software-Entwicklungsmethode. Welche Schritte und Meetings man dabei regelmäßig durchläuft und warum wir im datenwerk auf diese agile Methode zurückgreifen, zeigen wir auch in diesem Blogbeitrag.

Wie funktioniert Scrum?

Scrum bietet gegenüber klassischen Projektmanagement und Software-Entwicklungsmethoden den großen Vorteil, dass es agil ist. D.h. während der Entwicklung gibt es immer wieder Möglichkeiten, neue Wünsche aufzunehmen, umzupriorisieren oder doch etwas ganz anders zu machen. Veränderungen passieren – und darauf nimmt Scrum Rücksicht. Henrik Kniberg vergleicht daher Scrum-Projekte mit gelenkten Raketen. Sie können auf ein bewegliches Ziel reagieren, während klassische Projekte – er vergleicht sie mit Kanonenkugeln – hier versagen.

Um mit Scrum zu arbeiten, braucht es einige Grundlagen der agilen Software-Entwicklung, die wir bereits vorgestellt haben: Neben der Definition von User Stories, um ein gemeinsames Verständnis des Ziels zu haben, geht es darum, die Komplexität jeder einzelnen Aufgabe mit Story Points einschätzen zu können. Beide Schritte sind bereits Teil eines Scrum-Projekts.

Wie läuft ein Scrum-Projekt ab?

Scrum folgt einer klar vorgegebenen Meeting-Struktur. Diese Meetings wiederholen sich im Laufe eines Projekts regelmäßig. Je nach Komplexität und Größe des Auftrags werden die User Stories  in sogenannte Sprints eingeteilt. Diese Sprints sind 2- bis 4-wöchige Einheiten, in denen intensiv gemeinsam am Produkt gearbeitet wird. Selten ist ein Produkt in einem Sprint erledigt. Daher wiederholt sich der unten beschriebene Meeting-Ablauf so oft, bis alle Sprints abgearbeitet sind. Meist sind am Ende des letzten bezahlten Sprints noch User Stories offen, die im Laufe des Projekts  weniger wichtig und daher nicht umgesetzt wurden. Sie werden im Backlog für spätere Aufträge und Ideen aufgehoben. Fangen wir aber von vorne an:

Estimation Meeting

An diesem Meeting nehmen alle am Projekt beteiligten Personen teil. Das heißt, wir treffen hier den Product Owner, der/die die Vision vom fertigen Produkt hat und für die User Stories zuständig ist, sowie den Scrum Master, der/die als ProzessbegleiterIn einen reibungslosen Ablauf des Projekts gewährleistet, indem er/sie darauf achtet, dass alle Meetings und Regeln eingehalten werden und Probleme, auf die das Team stößt, aus dem Weg räumt. Außerdem nimmt das gesamte am Projekt beteiligte Entwicklungs-Team am Meeting teil.

In diesem Meeting wird Karten gespielt. Dabei werden die User Stories für die nächsten 1-2 Sprints abgeschätzt und bewertet.Scrum Pokerkarten

Sprint Planung 1

An diesem Meeting nehmen ebenfalls alle oben genannten Personen teil. Es ist der Startschuss für den Sprint, also jenen 2- bis 4-wöchigen Zeitraum, in dem alle Teammitglieder aus dem Entwicklungsteam Vollzeit an diesem Projekt arbeiten werden. Am Ende eines Sprints soll ein Produktteil fertig sein. Das heißt, dass z.B. eine Teilfunktion umgesetzt wurde. In der Fachsprache ist hier vom „potentially shippable product“ die Rede.

Das Meeting dient dem gemeinsamen Verständnis darüber, welche Abnahmekriterien pro User Story festgelegt werden. Es enthält außerdem eine Priorisierung der User Stories. Je wichtiger eine User Story bewertet wird, desto früher wird sie abgearbeitet. Gleichzeitig empfiehlt es sich hier, große/komplexe User Stories, die zu Stolpersteinen werden können, nach vorne zu reihen. Der Termin endet mit einem Commitment des Entwicklungs-Teams, wie viele User Stories für sie im vorgegeben Zeitrahmen (= dem nächsten Sprint) zu bewältigen sind.

Sprint Planung 2

Dieser Termin schließt unmittelbar an Sprint Planung 1 an und kann mit oder ohne Product Owner durchgeführt werden. Die anderen Teammitglieder entwickeln hier ein technisches Design für die ersten höchst priorisierten User Stories in diesem Sprint.

Daily Scrum Meeting

Sobald der Sprint läuft, gibt es ein tägliches 15-minütiges Meeting. Der Product Owner kann hier optional teilnehmen, die anderen Teammitglieder werden dazu verpflichtet. Es findet vor dem Task Board statt. Auf diesem sind alle User Stories in priorisierter Reihenfolge gelistet. Sie werden in dieser Reihenfolge abgearbeitet, wobei die einfache Regel zu befolgen ist, dass pro Person nur eine User Story gleichzeitig bearbeitet werden darf.

Im Daily Scrum beantwortet jedes Mitglied aus dem Entwicklungs-Team folgende drei Fragen:

  1. Was habe ich gestern getan?
  2. Was werde ich heute tun?
  3. Bin ich bei einer Aufgabe blockiert?

Damit erhält der Scrum Master einen Überblick darüber, ob der Ablauf reibungslos gewährleistet ist, ob er/sie Probleme aus dem Weg räumen muss und ob der geplante Sprint so durchgeführt werden kann, wie der im Sprint Planungs-Meeting besprochen wurde.Burndown Chart im Scrum Projekt

Am Ende des Meetings verzeichnet der Scrum Master den Fortschritt im Burndown Chart. Es gibt einen visuellen Überblick darüber, wie viele User Stories bis zum Sprintende noch zu erledigen sind und wie viele bereits abgearbeitet wurden.

Sprint Review

Am Ende jedes Sprints kommt es zur Präsentation der Sprintergebnisse. An diesem Meeting nimmt das gesamte Team sowie alle Interessierten teil. D.h. hier sind auch die KundInnen unmittelbar in den Scrum Prozess involviert. Dabei werden die Sprintergebnisse nicht etwa in Powerpoint hergezeigt, sondern es wird unmittelbar mit der neu entwickelten Software gearbeitet und das potentially shippable product vorgestellt.

Sprint Retrospektive

Nach jedem Sprint ergibt sich mit diesem Meeting die Chance, den Prozess zu verbessern. Es ist daher für alle Teammitglieder außer dem Product Owner verpflichtend.

Wo gibt’s Stolpersteine in Scrum-Projekten?

Scrum-Projekte werden durch viele banale Dinge im Alltag erschwert. Im datenwerk haben wir z.B. folgende Erfahrungen gemacht:

  • Es gibt mehr Projekte als Teams. D.h. die EntwicklerInnen können nicht Vollzeit nur an einem Projekt arbeiten, sondern müssen ihre Arbeitszeit aufteilen.
  • Nicht alle MitarbeiterInnen arbeiten Vollzeit. Sie sind daher nicht bei jedem Daily Scrum dabei.
  • Die Anforderung, dass alle Teammitglieder an einer Vielzahl an Meetings teilnehmen müssen, führt zu riesigen Besprechungen und lähmt.
  • Die KundInnen können in diesem täglichen Rhythmus, wenn es z.B. um das Ausräumen von Problemen geht, nicht immer mithalten.

Scrum-Projekte sind durchwegs erfolgreicher

All diese Faktoren verwässern ein Scrum-Projekt und verkomplizieren den Prozess. Nichtsdestotrotz zeigt die Erfahrung bei datenwerk, dass Scrum-Projekte durchwegs erfolgreicher sind als klassische Wasserfallprojekte. Erfolgreicher heißt in diesem Fall nicht nur, dass sie finanziell besser steuerbar sind, sondern auch, dass die Erwartungen und Wünsche der KundInnen schneller und besser erfüllt werden können.

 

Da sind noch Fragen offen geblieben? Wir helfen dir gerne weiter – schreibe uns eine Email an office@datenwerk.at !

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Webseite verwendet Cookies. Mit der Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Mehr Informationen zu Cookies.
Ich habe den Hinweis gelesen.
x