en
de

How to become a Scrum Developer – Tag 1

14 November 2013
| |

Die Frage stellten sich 11 Zühlke Software Ingenieure und hofften, dies im Kurs Professional Scrum Developer beantwortet zu bekommen. Um es vorweg zu nehmen: Sie wurden nicht enttäuscht 🙂

Zu Beginn ist ein kurzes Intro angesagt, das sofort interaktiv startet. Unser Dozent Peter Gfader (der Mann mit den vielen Gesichtern, dazu später mehr) hat eine Sammlung von Scrum Stichworten und eine „leere“ Prozessgrafik vorbereitet.

Reihum wird jeder aufgefordert sein Vorwissen einzubringen und die entsprechenden Stichworte zu erklären und zuzuordnen. Bereits an dieser Stelle ergeben sich erste spannende Diskussionen. Man merkt: Das Engagement und die Motivation ist bei allen Teilnehmern auf einem hohen Niveau.

Professional Scrum Developer Kursfoto

Anhand eines Mini-Projekts lernen die Teilnehmer Scrum professionell anzuwenden.

Wir retten Windows Blue!

Der Kurs ist grundsätzlich auf einem zentralen Punkt von Scrum aufgebaut: Inspect and adapt! Der Ablauf der drei Tage gruppiert sich um ein (Mini)Projekt, das es zu entwickeln gilt. Die Ausgangslage: Das alte Team ist weg und nun müssen wir übernehmen. Ein Schock! Wer hat nicht schon schmerzliche Erfahrungen mit Hinterlassenschaften von Vorgängern gehabt… Glücklicherweise haben diese wohl bereits den „Clean-Code“ Kurs bei Zühlke besucht, daher können wir sehr schnell starten. Es gilt eine neue Shell für das neue Windows Blue zu entwickeln. Endlich können wir Microsoft mal zeigen, wie man es gleich richtig macht.

Einer kurzen Vorstellung des Projektes folgt die erste theoretische (Kurz-)Lektion zum Thema Schätzen. Aus der schier unendlichen Anzahl von Schätzmethoden wird für unser Projekt die Variante Planning-Poker gewählt.

Planning Poker

Mit Planning Poker wird der Zeitaufwand geschätzt.

Natürlich gibt es auch sofort die erste Gelegenheit, das neu erlangte Wissen anzuwenden: Das erste Backlog-Refinement steht an. Dabei schauen wir uns als Team die vorhandenen Backlogitems an, versuchen diese zu verstehen und geben dann eine relative Schätzung mit Fibonacci-Zahlen ab. Gepokert wird solange, bis ein Konsens über die Dauer erzielt wird. Hier kommt dann nun auch ein weiteres Gesicht von Peter zum Zuge: Der Product Owner.

Als zentrales Element im Scrum-Prozess steht er uns für alle Fragen rund um das Produkt zur Verfügung. Dank der guten Vorarbeit des POs sind die User Stories bereits gut aufgeteilt und werden auch schnell vom Team verstanden. Schwierigkeiten gibt es vor allem zu Beginn. Solange noch keine User Story geschätzt ist, müssen sich die Teams erst einig werden, wie gross ihre Storypoints sind. Nach der ersten Schätzung ist die „Kalibrierung“ abgeschlossen und die Teams kommen zügiger voran. Wir füllen also unser Sprint-Backlog mit den User Stories, die wir für machbar halten, leiten die dafür notwendigen Tasks ab und gehen anschliessend in die Mittagspause, um uns für den ersten Sprint zu stärken.

Let’s get started

Dann geht es los: Nach dem ersten kurzen Daily Scrum fangen wir mit Pair Programming an. Jedes Pair nimmt sich einen Task und hängt den Task von ‚ToDo‘ auf ‚In Progress‘. Nun erleben wir Scrum in Aktion, nur etwas kleiner. Wir sehen, wie gut wir mit unseren Schätzungen und dem Aufteilen der Tasks sind. Auch hier gilt: Inspect and adapt.

Die Zeit vergeht wie im Flug, der erste Sprint ist schon vorbei. Beim Review wird deutlich, dass sich das Team zu viel zugemutet hat, was zu einem Desaster führt. Bei der Demo funktioniert nichts, obwohl zuvor alles geklappt hat. Ein Anfängerfehler. Das Team verspricht, sich beim nächsten Mal besser auf das Review vorzubereiten.

Planen in der Wolke

Nun wird es wieder etwas theoretischer und wir lernen „TFS in the cloud“ als Application Lifecycle Management Lösung kennen. Die meisten von uns kennen TFS schon, daher sind hauptsächlich die Tools zum Planen und Visualisieren eines Sprints sowie das Anwenden neu. Im anschliessenden Backlog Refinement als letzten Teil des Tages haben wir die Gelegenheit, das mit unseren bisherigen Backlog-Items praktisch anzuwenden. Fazit: Coole Möglichkeiten, aber „echtes Papier am Board“ kann es nach unserer aller Meinung nach nicht das Wasser reichen. Für verteilte Entwicklung sieht das natürlich wieder anders aus.

Wie es am zweiten Tag weitergeht, erfahrt ihr im nächsten Beitrag.

Comments (5)

Hans-Peter Korn

14 November 2013 at 19:44

Genau das ist der entscheidende Punkt:
“Dank der guten Vorarbeit des POs sind die User Stories bereits gut aufgeteilt und werden auch schnell vom Team verstanden”
Und da Scrum genau DAS voraussetzt is Scrum KEINE Methode der Projektabwicklung ist sondern nur INNERHALB einer solchen, die mit Vorteil ein JEDUF und ein inkrementell-adaptives Vorgehen unterstützt (wie z.B. PRINCE2) unterstützt, anwendbar.

Sogar Ken Schwaber schrieb bereits 1995: [*]
“”
SCRUM is a management, enhancement and maintenance methodology for an existing
system or production prototype. It assumes existing design and code which is virtually
always the case in object-oriented development due to the presence of class libraries.
SCRUM will address totally new or re-engineered legacy systems development efforts at
a later date.
“”
Dieses Versprechen hat er bis heute nicht eingelöst.

[*] http://agilix.nl/resources/scrum_OOPSLA_95.pdf

    Daniel Tobler

    15 November 2013 at 16:15

    Hans-Peter, die Teilnehmer berichten nur über den ersten Tag. Die Vorarbeiten des PO’s für den zweiten Sprint sind massiv schlechter: fehlende Akzeptanzkriterien, Fehler, Lücken, schlechte oder keine Beschreibungen, … Das DevTeam muss die User Stories verfeinern, sich um Requirements, um 3C’s selbst kümmern. Product Backlog refinement ist eines der grossen Themen im Kurs.
    Danke für den Hinweis. Es ist tatsächlich so, dass Scrum hier oberflächlich bleibt und Scrum Teams genau darum in Probleme kommen. Ich wäre an deiner Meinung zu https://www.zuehlke.com/blog/do-you-regularly-refine-your-product-backlog/ interessiert.

[…] https://www.zuehlke.com/blog/how-to-become-a-scrum-developer-tag-1/: A German blog, but with many pictures from attendees of a recent PSD (.NET) […]

[…] Teil 1 verpasst? Hier geht’s zum Beitrag. […]

[…] geht’s zu Tag 1 und Tag […]

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.