Von Teamwork, Scrum und Burndown-Charts – Hochmotiviert das Sprintziel erreichen

Wer bytabo® auf Instagram folgt, hat sicher mitbekommen, dass unsere Entwickler letzten Freitag mal wieder einen Sprint erfolgreich abgeschlossen haben. Wir schwören mittlerweile auf Scrum als Projektmanagement-Prinzip, da das damit einhergehende agile Vorgehen eine wesentlich effektivere, effizientere und schnellere Entwicklung ermöglicht. Damit ihr mal einen Eindruck davon bekommt, wie so ein Sprint im Hause bytabo® aussieht, hier ein kleiner Bericht dazu.
Unser Scrum-Team sah folgendermaßen aus:
  • Den Product-Owner verkörperte Niklas.
  • Als Scrum Master wurde Christian ernannt, da er in den letzten Jahren schon sehr viele Erfahrungen, auch in anderen Unternehmen, mit Scrum gemacht hat und daher ein echter Scrum-Spezialist ist.
  • Das Entwickler-Team bestand bei diesem Projekt aus Pasquale, Taras und Johannes.
Agiles Projektmanagement

Das Sprint-Entwickler-Team: Taras, Pasquale und Johannes (v.l.n.r.).

Ein eigener Projekt-Raum für bessere Zusammenarbeit

Damit unsere drei Entwickler auch wirklich in Ruhe arbeiten konnten, wurde unser Space Room zum Projekt-Raum umfunktioniert. Auf diese Weise wurden sie nicht durch andere Projekte gestört und konnten sich voll und ganz auf ihre Aufgabe konzentrieren. Zudem erleichtert diese räumliche Nähe generell die Abstimmung untereinander sowie die Zusammenarbeit an sich.

Los geht’s mit dem Sprint-Planning

Zu Anfang jedes Sprints steht die Planning Phase. Im Planning 1 sind der Product Owner, der Scrum Master sowie das Entwickler-Team anwesend. Hierbei geht es darum, alle User Stories, die sich im Backlog befinden, zu besprechen und zu schätzen. User Stories, kurz US, bezeichnen kleine Aufgaben-Pakete, die zum einen die Aufgabe charakterisieren, aber auch Akzeptanzkriterien aufweisen, die es zu erfüllen gilt. US gehen allerdings mit ihrer Aufgabenstellung nicht zu sehr in die Tiefe, sondern bewegen sich an der Oberfläche.

Damit ihr euch das besser vorstellen könnt: Eine US könnte z.B. bei der Umsetzung einer App lauten „Ich kann die App öffnen und gelange dann auf einen Login-Screen.“.

Das Planning 1 dient dazu, alle offenen Fragen zu klären und den US Story-Points gemäß ihrem Aufwand zu geben. Nach einer Stunde ist alles vorbei, nur so lange darf geschätzt werden. Also besprachen Niklas, Christian und die Entwickler so viele User Stories wie möglich innerhalb dieser Stunde. Die US, die nicht mehr besprochen wurden, werden einfach im Planning der nächsten Sprints besprochen und bleiben im Backlog hinterlegt.

Ganz wichtig: Timeboxing

Timeboxing ist generell ein sehr essenzieller Bestandteil in all diesen Schritten, da nur so sicher gestellt werden kann, dass man sich nicht mit Punkten verzettelt oder zu lange über einen Topic spricht und die Zeit effizient nutzt. Somit ist jedes Meeting, welches im Sprint-Prozess stattfindet, auf eine Stunde getimeboxed und Christian muss als Scrum Master darauf achten, dass diese Vorgabe auch eingehalten wird.

Danach ging es ans Planning 2. Der Product Owner und Scrum Master waren hier nicht mehr anwesend, sollten aber generell für Rückfragen verfügbar bleiben. Pasquale, Taras und Kühli besprachen sich nun in Bezug auf Tasks sowie der Aufteilung der Aufgaben. Auch die Anzahl der US, die im Rahmen des zu planenden Sprints sicher umgesetzt werden könnten, wurden in diesem Schritt festgesetzt. Anhaltspunkte für den Aufwand sind die schon zuvor genannten Story-Points. Diese beschreiben den Aufwand und die Komplexität, können aber nicht direkt in Stunden umgerechnet werden. Mit der Zeit und mit weiteren Schätzungen bekommt man immer mehr ein Gefühl dafür, was ein Story-Point bedeutet. Zudem kann mit Hilfe der Einheit Story-Points auch sehr gut der Arbeitsfortschritt sowie die Geschwindigkeit der Entwicklung eingeordnet werden.

Sollten nach dem Planning 2 noch Fragen bei den Entwicklern bzgl. der User Stories aufkommen, kann das Refinement eingeschoben werden, das genau für solche Situationen bestimmt ist.

Nachdem man letztendlich dem Product Owner, also in unserem Fall Niklas, dann zugesichert hatte, welche US im folgenden Sprint sicher umgesetzt werden, ging es direkt an die Entwicklung. Kühli, Pasquale und Taras organisierten sich hier völlig selbstständig, verteilten also entsprechend der Technologien und des Wissensstands die Aufgaben, arbeiteten entweder im Team oder allein. Im Endeffekt lag das Taskmanagement nun vollkommen in der Hand des Dev-Teams. Christian griff als Scrum Master nur ein, wenn Probleme entstanden, sei es im Dev-Team selbst oder mit dem Product Owner. Hierbei war er allerdings nur als vermittelnde Instanz dazwischen geschaltet.

Jeden Tag gab es ein Sprint Daily, bei dem das Dev-Team über den vorherigen Tag sprach, welche Aufgaben erledigt wurden, welche am aktuellen Tag anstehen und wo es möglicherweise Probleme gab. Christian war als Scrum Master auch hier anwesend, einfach um auf dem neuesten Stand zu bleiben.

Sprint-Daily

Tägliche Updates zum aktuellen Stand der Entwicklung gibt es im Sprint-Daily.

Der hier beschriebene Sprint dauerte 2 Wochen. Am Ende des Ganzen stand die Sprint Review und die Sprint Retrospektive an. In der Review wurde dem Product Owner und dem Kunden selbst das Ergebnis des Sprints demonstriert. Das Dev-Team geht sämtliche User Stories des Sprints durch und präsentiert das Resultat.

Ein in unseren Augen zudem wichtiger Punkt, der unglaublich wertvoll für das weitere Projektvorgehen und die Zusammenarbeit an sich ist, ist die Retrospektive, kurz Retro. Hierbei wird der vergangene Sprint rekapituliert, über das was gut gelaufen ist, aber auch über Probleme bei der Zusammenarbeit gesprochen. Hier geht es darum, wirklich offen Sachen anzusprechen. Nur so können Schwachpunkte, Missverständnisse oder andere Probleme identifiziert und daraufhin behoben werden.

Feedback als ganz wichtiger Punkt im Scrum-Prozess.

Auf Basis dieses Feedbacks kann dann im neuen Sprint an den betroffenen Stellschrauben gedreht werden, um so den gesamten Prozess stetig zu verbessern.

Essenziell für den Scrum-Prozess: ein motiviertes Team

Nach der Retro geht’s dann im Endeffekt wieder von vorne los. Aber davor wird noch kurz auf das Geschaffte angestoßen. Man muss gutes Teamwork ja schließlich auch belohnen! Das machen wir in der Regel mit einem Feierabend-Bier, Sekt oder auch einem gemeinsamen Essen.

Wir merken immer wieder, wie motivierend dieses Vorgehen ist. Auch sogenannte Burndown-Charts, auf denen die bisher geschafften Story-Points mit einer Grafik dargestellt werden, spornen die Entwickler und das Team unglaublich an und zeigen auf, wie viel man schon geschafft hat.

Agiles Projektmanagement

Gutes Teamwork sorgt am Ende für einen erfolgreich absolvierten Sprint und zufriedene Kunden!

 

Ein Beitrag von Amelie Tihlarik. 

Leave a comment