Januar 22, 2014

Mann mit schwarzem T-Shirt über dem Kopf

In Deiner Arbeit als Scrum Master bleibst Du selbst ständig auf der Strecke? 

Dann hole Dir hier die Anleitung für Deine persönliche Retrospektive. 

Der ein oder andere Product Owner wird schon darüber nachgedacht haben, wie er sich bei seinem Team revanchieren kann. Glücklicherweise hat auch der Product Owner unzählige Möglichkeiten, sein Team zu terrorisieren. Netterweise hat mir Heiko Weltin geholfen und ein paar Vorschläge dazu gemacht (und er freut sich bestimmt über den ein oder anderen neue Follower ):

  1. Erstelle ein Product Backlog ohne jegliche Priorisierung. Nur wenn alle Anforderungen implementiert sind, kann man das Produkt auf den Markt bringen.
  2. Erstelle Stories immer nur mit einer Überschrift und ohne jeglichen Informationsgehalt. Du kannst ja schließlich nicht alles vorkauen.
  3. Verwende nur zwei Priorisierungen: „Dringend“ und „Machen wir irgendwann mal“.  Alles andere ist zu aufwendig.
  4. Spreche mit dem Kunden ab welches Feature als nächstes fertig sein soll, und verspreche ihm, dass es in einer Woche fertig ist, ohne vorher mit den Entwicklern zu reden. Du kannst das ganz gut selbst abschätzen.
  5. Füge jeder Story mindestens einen Task hinzu der verhindert, dass die Story innerhalb eines Sprints auf „Done“ gesetzt werden kann. Die Definition of Ready (DoR) hat dich noch nie so wirklich interessiert.
  6. Erstelle Stories deren Tasks andere Stories duplizieren und hänge sie mit ans Board, damit es nicht so „leer“ aussieht. Dein Chef soll schließlich sehen, wie produktiv Du (Dein Team) ist.
  7. Definiere nur so viele Storys, dass maximal der halbe Sprint geplant werden kann. Die restliche Zeit können die Entwickler damit verbringen die übrigen Storys zu klären. Als Produkt Owner hast du schließlich Wichtigeres zu tun.
  8. Triff dich maximal einmal pro Woche mit den Entwicklern und dann nur für maximal eine halbe Stunde um alle offenen Fragen zu klären. Mehr Zeit willst Du wirklich nicht mit diesen Jammergestalten verbringen.
  9. Wenn dein Telefon während einem Teammeeting klingelt, gehe sofort ran und ignoriere das Team. Gehe nicht aus dem Raum, sonst könnten die anderen ja ohne dich weiter diskutieren.
  10. Komme grundsätzlich eine Stunde nach dem Standup Meeting, an dem du selbstverständlich nicht teilnimmst, zu den Entwicklern und frage sie wie weit sie sind. Es ist leichte einzelne Personen unter Druck zu setzen, als eine ganze Gruppe.

Nochmal Danke an Heiko für diese tolle Liste! Aber Euch fällt bestimmt auch noch ein, wie man diese Liste erweitern könnte. Ich freue mich auf Eure Kommentare.

Möchtest Du informiert werden, wenn ich eine neue Liste erstellt habe? Dann abonniere meinen Newsletter:

[mc4wp_form]

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. 11. Ganz wichtig sind neue Stories im Sprint um zu beweisen, wie agil (also flexibel) das Team (also man selbst als Product Owner) auf Anforderungen von Kunde und vor allem vom Management reagieren kann.
    12. Bestehe auf möglichst lange Iterationen von mindestens vier Wochen, weil in größeren Zyklen einfach viel mehr geschafft werden kann.
    13. Achte bei der Abnahme der Stories, die nur aus Überschriften bestanden, peinlichst darauf, dass deine nicht definierten Akzeptanzkriterien erfüllt sind und weise die Abnahme von Stories mindestens einmal pro Story zurück. Das Team muss lernen, mit Ablehnung und Frustration umzugehen.
    14. Maximal ein Release pro Jahr planen, denn Releases sind aufwändig und die Zeit für Automatisierung ist in der Umsetzung von Features viel besser angelegt.
    15. Stelle keine Zeit für qualitätssichernde Maßnahmen zur Verfügung, denn die brauchen nur Teams, die schlecht arbeiten. Die Zeit wird für neue Features benötigt.
    16. Wenn der Kunde oder das Upper Management ruft, dann spring genau so, wie gefordert. Das Team ist groß genug und arbeitet ja agil, um immer auf neue Anforderungen reagieren zu können.
    17. Ganz wichtig sind ein fest definierter und zu groß bemessener Umfang zu einem natürlich festgelegten Termin, idealerweise innerhalb einer Umsetzungsiteration. Gute Praxis aus den letzten Jahren mit Wasserfall-Erfahrungen braucht man ja nicht wegschmeißen.
    18. Werden Ziele nicht erreicht, dann beschwere dich lauthals direkt beim Management über die Unfähigkeit des Teams, um möglichen Druck direkt an die einzigen Verursacher der Probleme weiterzugeben und so für Lerneffekten zu sorgen.

  2. 19. Vergiss User-Stories, Epics und diese neumodische Zeug. Aufgaben! Die Leute sollen Aufgaben abarbeiten.
    20. Kommunikation funktioniert am Besten über Ecken. Kommuniziere über E-Mail, Vorgesetzte oder ein Ticketsystem. Mit Entwicklern kann man sich ohnehin nicht unterhalten. Das ist niveaulos. Die sollen programmieren.
    21. Vor neuen Aufgaben sind Fehlerhinweise sehr wichtig. Die Fehlerbeschreibung am Besten so kurz wie möglich halten.
    22. Denk daran Fehler über das Ticketsystem zu melden! Am besten rot markiert, hoch priorisiert.
    23. Schau dir bloß nicht das Produkt im ganzen an. Wichtig ist das die Programmierer von ihrem Code erzählen.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche
 Retrospektive