Scrum-Blogserie-Agilitaet-Header-Blog-QOne-Steffi-Budzyn-Lead-Product-Managerin-2

„Was Scrum nicht kann!“

Im zweiten Teil unserer dreiteiligen Blogserie „Was Scrum nicht kann“ erklärt euch unsere Lead Product Managerin Steffi Budzyn, wie die Einführung von Agilität bei Q.One gelaufen ist. Wir geben euch einen Einblick, wie ein Sprint-Meeting abläuft und erzählen euch, worum die Development Kollegen dabei „pokern“. Außerdem klären wir die Frage, was das alles mit Elefanten, Mäusen und Papageien zu tun hat. 😊

Teil 2 – agile Arbeitsmethoden in der Praxis. So machen wir das.

Warum habt ihr die Methode bei Q.One eingeführt?

Wir haben nicht konkret „Scrum“ eingeführt, sondern viel mehr begonnen die Basis für agiles Arbeiten zu schaffen. Ziel ist es schneller auf Kundenbedürfnisse reagieren zu können. So wollen wir diesen noch besser gerecht werden und die Qualität unserer Produkte steigern. Gleichzeitig wollen wir natürlich die Funktionen/Elemente umsetzen, die dem Kunden den meisten Wert bieten. Und da unterstützt agiles Arbeiten. Vor allem hilft es uns dabei, uns selbst stetig zu verbessern und uns auf das Wesentliche zu konzentrieren. In Bezug auf unser eigenes Produkt den CloudBasket, sind wir selbst unser Kunde und behandeln uns nach denselben Prinzipien.

Waren alle Beteiligten sofort bereit mitzumachen oder gab es Bedenken?

Bedenken gibt es in irgendeiner Art und Weise immer, aber niemand hat sich komplett verschlossen und gesperrt. Wir haben uns Schritt für Schritt als Team gefunden und haben so nach und nach unsere Zusammenarbeit geschärft und unsere Art mit Aufgaben, Problemen und Herausforderungen umzugehen gefunden.

Wie läuft ein Sprintmeeting bei Q.One ab?

Alle zwei Wochen findet bei uns der Sprint-Wechsel statt. Das Sprint Planning ist dabei in zwei Teile aufgeteilt. Im ersten Abschnitt erklärt der Fachlichkeitsfachexperte, so werden wir Produktmanager gerne vom Team genannt 😉, was getan werden soll bzw. was sein gewünschtes Sprintziel ist. Dazu geht er die benötigten Tickets aus dem Backlog durch und beantwortet bei Bedarf Fragen dazu. Sind noch Tickets dabei, die nicht geschätzt sind, so wird das hier nachgeholt. Dies erfolgt bei uns mit dem Planning Poker und den sogenannten Story Points. Gemeinsam mit dem Entwicklungsteam werden mit Blick auf die zur Verfügung stehenden Ressourcen für die nächsten zwei Wochen, die Tickets für den Sprint bestimmt. Das Team gibt dann ganz klar sein Versprechen ab, diesen Umfang in den nächsten zwei Wochen zu schaffen oder aber legt sein Veto ein, wenn der Umfang zu groß ist und justiert noch mal nach.

Wie geht es dann weiter?

Anschließend startet der zweite Abschnitt. Hier zerpflückt das Team die einzelnen Tickets und bricht sie in einzelne Unteraufgaben runter. Dabei diskutiert das Team fleißig und legt fest, wie sie die Anforderungen umsetzen will. Zum Abschluss hat das Team eine gemeinsame Strategie, wie es im Sprint zusammenarbeiten will, um das Sprintziel zu erreichen. Wenn das klar ist, wird der neue Sprint gestartet und die Arbeit am Sprintziel beginnt.

Planning Poker? Was ist das?

Im Planning Poker (oder Scrum Poker) geht es darum gemeinsam im Team die umzusetzenden Aufgaben zu schätzen. Allerdings arbeitet man nicht mit absoluten Einheiten, sondern es geht darum die Aufgaben in ihrer Komplexität zu vergleichen. Diese Komplexität wird in sogenannten Story Points ausgedrückt. Vielleicht ein kleines Beispiel: Man soll drei Tiere (Maus, Elefant, Papagei) in Origami falten. Das Team soll nun schätzen, welches der drei Tiere am einfachsten und welches am schwierigsten zu basteln ist. Nach einem Austausch über das Verständnis der jeweiligen Aufgabe und einem Wissenstransfer, gelangt das Team zu einer gemeinsamen Bewertung. Ein Ausgang könnte etwa sein, dass die Maus mit 3 Story Points und der Papagei mit 8 bewertet wurde. Der Elefant wird in der Mitte gesehen und bekommt eine 5. Zu beachten ist, dass die Einschätzung nicht in jedem Team gleich ist. Jedes Team ist individuell und ein Story Point hat pro Team eine andere Wertigkeit.

Seid ihr euch bezüglich der Story Points immer einig?

Nicht immer sofort. Aber selten klaffen riesen Lücken zwischen dem niedrigsten und höchsten Wert. Besonders bei unterschiedlichen Interpretationen einer von uns unscharf formulierten Aufgabe. Da spricht sich das Team nach der ersten Runde noch mal kurz ab, räumt Unklarheiten aus dem Weg und schafft ein einheitliches Verständnis. Anschließend findet sich dann schnell ein Konsens.

Du hast den ersten Teil noch gar nicht gelesen? Dort hat Lead Product Managerin Steffi erzählt, dass Scrum allein keine gute Software programmiert. Danke, liebe Steffi! Wir freuen uns schon darauf zu erfahren, was mit Scrum noch alles möglich sein kann.

Ähnliche Artikel: 15 Q.uestions an Maikel – das etwas andere Mitarbeitergespräch | Meetup@Q.One – die IT-Torte geht in die nächste Runde | 15 Q.uestions an Danny – das etwas andere Mitarbeitergespräch


Steffi Budzyn
Steffi Budzyn
Footballfan, Teamplayerin und Lead Product Managerin

Share on

Zurück