Es muss schnell gehen, heute machen wir kein Scrum

Zu meiner großen Freude führen immer mehr Unternehmen Scrum ein und beginnen diesen Produktentwicklungszyklus auch wirklich zu leben. Besonders gelobt werden die Planbarkeit und der Umgang mit dem Commitment. Und dennoch: Immer wieder schleicht sich ein altbekanntes Phänomen ein, das absolut im Widerspruch zu Scrum steht und auch konträr zu den eben erwähnten positiven Aussagen ist.

Folgende Situation: Eine vergessene Ausschreibung trudelt auf dem Tisch eines Mitarbeiters ein. Plötzlich müssen Kundenwünsche „schnell“ oder „mal kurz“ vom Entwicklungsteam umgesetzt werden. Untermalt von der Aussage: [quote author = "Ein Gehetzter"]"Leute, es muss schnell gehen, heute machen wir kein Scrum!"[/quote] Und dann setzt man sich (im besten Fall) noch einmal zusammen und bespricht im Schnellverfahren, was zu tun ist. Dann hauen alle in die Tasten und die Abstimmung, die in Scrum eigentlich mehr Raum hat und sonst so gelobt wird und zum gewünschten Erfolg führt, wird ausgesetzt, weil sie angeblich zu lange dauert. Was bedeutet das? Dass Scrum nur toll ist, wenn man lange Planungsphasen hat? Wenn es aber schnell gehen muss, gibt es keine Zeit für eine richtige Abstimmung?

Was will Scrum?

Scrum möchte weg vom schnellen Dazwischenschieben von Aufgaben, hin zu einem strategischen Agieren und Planen. Dazu ist ein Product Owner nötig, der alle Termine im Blick hat und auch einmal Nein zu unerwarteten Kundenanforderungen sagen kann. Und hier spreche ich nicht vom Stillstand beim Kunden - dass es hier eine Ausnahmesituation braucht, ist selbstredend. Hier sind wir schnell bei den Verantwortlichkeiten und Aufgaben des PO: Er oder sie muss die Kundentermine im Blick behalten, sie priorisiert in das Backlog bringen und die Kundenanforderungen dann von den Entwicklern abarbeiten lassen. Keine leichte Aufgabe, denn meist ist es ja nicht nur ein Kunde, dessen Wünsche und Bedürfnisse gestillt werden müssen. Einen guten Product Owner zeichnet ein gutes Organisationstalent aus. Und nicht nur das: Er hält den Kontakt zum Kunden, um rechtzeitig Anforderungen einzusammeln und den Entwicklern periodisiert zur Verfügung zu stellen.Gelingt das dem Product Owner gut, dann ist es eine Arbeitserleichterung für die Entwickler. Sie müssen dann nicht mehr im letzten Moment auf den Plan gerufen werden, um das Feuer am Dach zu löschen.Gilda Feller, Scrum Consultant bei bor!sgloger

Agile Prinzipien
Kundenfokus
Agile Toolbox
Scrum
Product Owner
Rollen
Scrum-Begriffe
Team
bgloger-redakteur
March 26, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen