10 Dinge womit ein Product Owner sein Team in den Wahnsinn treiben kann

Veröffentlicht von

This post is also available in: English (Englisch)

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]

  • 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.

  • 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.