Sprint_harder

Quelle: pixabay

Im ersten Teil dieser Serie habe ich meine persönliche Favoritenliste der „hard parts“ von Scrum vorgestellt und wie Sie diese gekonnt umschiffen können.

Auch im zweiten Teil möchte ich Ihnen einen bunten Strauß an Bad Practices und Workarounds anbieten – aus der Praxis, für die Praxis. Scheitern garantiert.

Viel Spaß!

Das Product Backlog

Laut Scrum Guide ist das Product Backlog nie vollständig und enthält anfangs nur die am besten verstandenen Anforderungen.

Gerade in innovativen Projekten, in denen weder Anforderungen noch Technologie vorab bekannt sind, kann das zu großer Verunsicherung führen: Woher wissen wir dann, dass wir “in time, budget and scope” fertig werden, damit unser Vorgesetzter den Bonus aus seiner Zielvereinbarung erhält?

Der Workaround ist denkbar einfach: Sorgen Sie für eine ausreichend lange Projektinitialisierungsphase, mindestens mehrere Monate! Sollten Sie Widerständen aus dem “agilen Camp” begegnen, verwenden Sie dafür den Begriff “Sprint 0”. Ihnen steht nun ein Marathon an vergnüglichen Meetings mit Stakeholdern bevor, bis die Anforderungen detailliert dokumentiert und final abgestimmt sind.

Noch eine pfiffige Idee obendrein: Schreiben Sie diese Anforderungen unter Verwendung des User Story Templates. Das gibt dem Product Backlog einen “agilen Touch”.

Und denken Sie immer daran: So lange noch nichts implementiert ist, ist es am wahrscheinlichsten, dass alle Wünsche von Stakeholdern berücksichtigt werden können!

Der Scrum Master als “Servant Leader”

Laut Scrum Guide ist der Scrum Master ein “Servant Leader” des Scrum Teams.

Wenn Sie in einem Unternehmen arbeiten, das Scrum einführt, sollten Sie sich diese neuen Bediensteten also zu Nutze machen – schließlich kosten sie ja auch was. Hier nur ein paar Beispiele dafür, wozu Scrum Master in der Praxis verwendet werden:

  • Scrum Master als Bote: statt unangenehme Botschaften an das Scrum Team selbst zu übermitteln, verwenden Sie doch den Scrum Master als Boten. Sie glauben gar nicht, wie viele Konflikte dadurch vermieden werden können!
  • Scrum Master als Reporter: das agile Manifest sagt zwar, dass die Software das wichtigste Fortschrittsmaß ist. Aber nicht jeder möchte sich mit den Produkten beschäftigen, die das eigene Unternehmen herstellt, wenn man auch Zahlen und Graphen analysieren kann! Dafür braucht es einen Reporter auf Team-Ebene, und niemand kann das besser als der Scrum Master.
  • Scrum Master als Projektleiter: Gerade Scrum Master, die früher als Projektleiter gearbeitet haben, sind oft gerne bereit, ihre Erfahrung einzubringen. Um Scrum-Projekte effektiv und effizient “durchzusteuern” können Sie z.B. das Daily Standup in ein Status Meeting umwandeln. Besonders elegant kombiniert mit der Möglichkeit, den Entwicklern ihre Aufgaben zuzuweisen – so gestaltet sich der Übergang vom klassischen Projektmanagement zu Scrum reibungslos.

Commercial Break: Wollen Sie Scrum in seiner Urform kennenlernen oder haben Sie weiteren Klärungsbedarf, was die agile Entwicklung angeht? Dann besuchen Sie eines unserer Trainings (http://www.hood-group.com/agile/training/).

Series Navigation<< Scrum – the hard parts