Fokussieren eines Scrum Teams

Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.

In einem solchen Umfeld kommt es leicht vor, daß sich ein Team unterschiedlichen Anforderungen gegenübersieht, die dann vielleicht  auch noch zu Spezialisierungen bei den Teammitgliedern führen.

Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.

Mehr Anforderungen als Zeit

In einem früheren Beitrag habe ich über das Problem geschrieben, daß dann auftritt, wenn sich Ihr Team zu vielen Anforderungen gegenübersieht. Ich habe dort praxisorientierte Lösungen vorgeschlagen, um solche Situationen zu managen (siehe Weiterführende Informationen ganz unten). Die Situation, die heute im Fokus steht, ist vergleichbar damit. Nur ist es hier nicht unbedingt „das Zuviel“ an Anforderungen, sondern es ist die fehlende Konsolidierung, und eigentliche Priorisierung.

Wie erkennt man das Problem?

Doch zunächst einmal zur Frage, wie man das eigentliche Problem erkennt, und wie der Normalzustand aussehen sollte.

Im Normalzustand sollte meiner Meinung nach das Team über einen angemessen großen Produktbacklog verfügen, der sich zudem nicht allzu dynamisch entwickelt. Dies erlaubt dem Team auf der einen Seite, den Backlog ohne Aufregung wegzuarbeiten. Auf der anderen Seite hat jedermann einen Überblick über die Anforderungen, Qualifikationsanforderungen, oder Entwicklungsbedarfe. Der Umstand, daß der Backlog sich nicht ändert, zeigt, daß die Anforderungen geklärt sind, die diesem Backlog zugrundeliegen.

Nach meiner Erfahrung sollte man dann als Produktowner hellhörig werden, wenn man folgende Merkmale an seinem Backlog entdeckt:

  • Die Anforderungen ändern sich häufig, und es gibt viele Vordrängler: Wie oben gesagt; normalerweise würde man erwarten, daß ein Produktbacklog relativ stabil ist, und es daher möglich ist, auszusagen, welche Themen in den nächsten Monaten auf der Agenda stehen. Ist dem nicht so, und stehen mit jedem Sprint ganz neue Themen oben auf der Liste, ist zu vermuten, daß sich die Stakeholder in einem Panikmodus befinden, und versuchen, Ihren Anforderungen über die Priorität Gehör zu verschaffen. Dies kann daran liegen, daß die Stakeholder selbst noch nicht genau wissen, was sie benötigen, oder es kann daran liegen, daß das Team zu restriktiv vorgeht.
  • Die Anforderungen sind relativ klein: In diesem Fall, wollen die Stakeholder mal hier, mal da Erweiterungen haben, dies aber so, daß kein roter Faden erkennbar ist. Hier ist zu vermuten, daß die Anforderungen nicht geklärt sind, und das Gesamtbild fehlt.
  • Feedback von Team oder Stakeholdern zeigt, daß dem Team der Gesamtüberblick fehlt, etc

Was tun?

Meine Anregung in einem solchen negativen Fall ist es, zunächst einmal dafür zu sorgen, daß der Produktbacklog „strategisch“ geklärt wird.

  • Im einfachsten Rollinmodell nennen die verschiedenen Stakeholder ihre Anforderungen, die dann auch priorisiert abgearbeitet werden. Auf Teamebene gibt es soviele Backlogs, wie Stakeholder, und damit eine große Gelegenheit zur Verzettelung. Hier hilft es bereits, wenn man die Anforderungen konsolidiert, gruppiert, und zusammen mit den Stakeholdern die übergeordneten Prioritäten klärt.
  • Oft wollen Stakeholder ihre Themen durchsetzen, weil sie die Bedeutung des Wortes „Anforderung“ nicht richtig verstehen. Wenn man es zusammen mit den Stakeholdern schafft eine Anforderung als Idee zu verstehen, ist die Lösung nicht weit. Oft ist es nämlich sinnvoll, die Anforderungen so zu generalisieren, daß man erkennen kann, daß man als Stakeholder im Prinzip dasselbe Problem hat, wie ein Kollege, und daß allen damit geholfen wäre, wenn die Lösung auch genereller wäre.
  • Ganz häufig werden Anforderungen deshalb eingelastet, weil sich – aus falsch verstandener Kundenorientierung –  niemand getraut hat, die Barriere hoch zu hängen. Man sollte daher lieber jede Anforderung mehrfach hinterfragen, und auch mehrfach den Nutzen anzweifeln. Nur so stellt man sicher, daß die Anforderung auch wirklich durchdacht ist, und in ein Gesamtkonzept passt.
  • Viele Anforderungen laufen deshalb chaotisch ein, weil die Organisation des Stakeholders selbst nicht funktioniert. In einem solchen Fall steht das abnehmende Team unter starkem Anforderungsdruck, und versucht, Anforderungen weiterzureichen. Hier kann es helfen, wenn man dem Stakeholder dabei hilft, seine Kundenbearbeitung besser zu organisieren.

Dies waren nur einige Ideen, um mit dem typischen Problem der fehlenden Fokussierung umzugehen. Bei näherem Hinsehen, findet sich sicher noch weiteres Optimierungspotential – genug Grund, um hierauf einmal mit einer Fortsetzung zurückzukommen.

Weiterführende Informationen

… auf www.produkt-manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

Kontakt

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

    I

    This entry was posted on Dienstag, Oktober 4th, 2011 at 7:35 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with , , , , , . You can follow any responses to this entry through the RSS 2.0 feed.

    Andreas Rudolph - Fotoshop Andreas Rudolph - AS-Photo-Project.de

    Comments are closed.