Author Archive

Überforderte Product Owner

Eine der wesentlichen Tugenden des agilen Vorgehens ist die Nachhaltigkeit. Alle Teammitglieder sollen auf eine Art und Weise arbeiten in der sie das Tempo prinzipiell beliebig lange durchhalten können. Das unterscheidet das agile Vorgehen sehr wesentlich von den meisten anderen Vorgehensweisen.

Doch die Erfahrung zeigt, besonders dass eine Person oftmals an der Belastungsgrenze arbeitet wenn sie ihre Aufgabe ernst nimmt – der PO. Hier wurde im Scrum-Framework eine Rolle geschaffen, die sehr viele wichtige und komplexe Aufgaben auf sich vereint.

Aus meiner Sicht hat ein Product Owner (mindestens) folgende Aufgaben:

  • Er (oder sie) hat jederzeit eine klare Vision des Produktes und seines Einsatzzwecks.
  • Das Backlog ist gepflegt. Das heißt insbesondere:
    • Es existiert eine klare Priorisierung der Stories (bzw. Epics)
    • Stories für den nächsten Sprint sind so weit ausdetailliert wie das Team es für den Beginn der Arbeiten benötigt
    • Stories für die zwei folgenden Sprints sind in wesentlichen Zügen durchdacht
  • Die Stories im Backlog werden regelmäßig mit dem Team durchgesprochen und ihr Aufwand geschätzt
  • Das Management ist über den aktuellen Stand der Entwicklung und die Pläne für die Zukunft informiert
  • Die Anforderungen aller Stakeholder für das Produkt sind in das Backlog eingeflossen
  • Bei Rückfragen des Teams zu inhaltlichen Details der Stories steht der Product Owner jederzeit zur Verfügung

Wie an dieser Aufzählung schon deutlich wird, ist der Product Owner kaum zu beneiden. Alle diese Aufgaben sind wichtig damit das Team (oder, noch schlimmer, mehrere Teams) effizient arbeiten können. In dieser Rolle laufen alle Fäden zusammen.

Kann eine einzelne Person diese Erwartungen überhaupt erfüllen? Kaum. Auf jeden Fall aber gebührt diese Rolle dem besten Mitarbeiter oder der besten Mitarbeiterin. Es ist keine Rolle die jemand Unerfahrenes ausfüllen kann.

Doch die Erfahrung zeigt, dass genau das viel zu oft passiert, und die Rolle des PO mit der bekannten Rolle des PMO (Project Management Office) verwechselt wird. Immerhin hat PMO ja sogar noch einen Buchstaben mehr als PO. Die Stories werden also mehr verwaltet als gestaltet, bei Rückfragen des Teams muss erst Rücksprache mit Anforderern gehalten werden, und richtungsweisende Entscheidungen bezüglich der Produktfeatures werden über Lenkungskreise ausdiskutiert. Am Ende zeigt sich dann, dass Scrum nicht funktioniert – was so mancher ja schon immer geahnt hat.

Daher ist es wichtig, die Rolle des PO zu verstehen, und den besten Mitarbeiter/die beste Mitarbeiterin mit dieser Rolle zu betrauen. Dann sind vielleicht auch das Vertrauen und die Aufmerksamkeit des Managements sicher gestellt.

Wenn man etwas zusagt …

Ein wesentlicher Begriff im Scrum ist der des Commitment, also einer Verpflichtungserklärung. Hiermit verpflichtet sich das Team, die zu Beginn eines Entwicklungszyklus – des Sprints – angenommenen Tätigkeiten auch tatsächlich bis zum Ende des Zyklus vollständig und in der zugesagten Qualität abzuschließen. Doch in welcher Form und mit welchen Konsequenzen kann und soll eine solche Verpflichtungserklärung abgegeben werden?

Und warum ist es überhaupt wichtig ein Commitment abzugeben? Kann man nicht einfach dem Artikel 2 des Rheinischen Grundgesetzes folgen: “Et kütt wie et kütt”?

Nein!

Letztendlich wird mit Beginn eines Sprint ein Pakt zwischen dem PO und dem Team geschlossen: Der PO verspricht dem Team den Umfang und die Priorität der Anforderungen für die Zeit des Sprint fix zu halten (und dies auch gegenüber dem Management zu vertreten), dafür bekommt er von dem Team die Zusage, dass die geplanten Inhalte auch tatsächlich geliefert werden. Nur wenn beide Seiten dieses Paktes eingehalten werden, dann können sich die die Beteiligten auf ihre Aufgaben konzentrieren. Hält der PO das Versprechen nicht und ändert die Anforderungen während des Sprint, dann wird das Team nur Stückwerk geringer Qualität abliefern können. Hält das Team das Versprechen nicht, dann verliert der PO das Vertrauen in die Planbarkeit des Verfahrens und wird zunehmend ins Mikromanagement verfallen.

Aus diesem Grund ist ein Commitment zu Beginn eines Sprints sehr wichtig, und sollte vom Team entsprechend ernst genommen werden. Das Team sollte ein Commitment nur dann abgeben wenn es sich sicher ist, dass die Realisierung der Anforderungen in der gegebenen Zeit auch realistisch ist. Gleichzeitig sollte das Team aber vom Wunsch getrieben werden möglichst viel umzusetzen (“viel Feature, viel Ehr’”) – im Zweifel wird ein guter PO aber auch versuchen das Mögliche aus dem Team herauszukitzeln.

Weil das Vertrauensverhältnis zwischen Team und PO so wichtig ist, halte ich die vor einiger Zeit im Scrum Guide von Ken Schwaber und Jeff Sutherland vorgenommene Anpassung des Begriffs Commitment in den sehr viel relativeren Begriff Forecast für kritisch. Ein unverbindliches “na ja, wir werden mal sehen was sich so machen lässt” führt zur Erosion des Willens im Team, das gesteckte Ziel auch wirklich zu erreichen. Das klassische Commitment macht die Entscheidung des Teams, die Herausforderungen des vor ihm liegenden Sprints anzunehmen, zu einer bewussten Willenserklärung.

Aber ist ein Commitment nicht genau so wenig oder viel Wert wie ein Forecast, da die Konsequenzen einer “Verfehlung” die gleichen sind? Und was sind überhaupt die Konsequenzen.

In einem idealen Team ist die wesentliche Konsequenz tatsächlich die Enttäuschung des PO und des Teams selbst über das nicht erreichte Ziel. Insbesondere sollte dem Team klar sein, dass es den PO in eine unangenehme Situation gebracht hat. Dieser muss nämlich dem Management eine Verschiebung des betroffenen Features mitteilen. Und auf lange Sicht ist die tragische Konsequenz der geschilderte Vertrauensverlust zwischen Team und PO sowie der daraus folgende Herauswurf aus dem Paradies der ungestörten Entwicklung.

Wenn das Team aber kein ideales Team ist? Nun, dann ist es die Aufgabe des ScrumMaster, mittel- bis langfristig aus dem Team ein ideales zu formen, das Stolz auf die eigene Leistungsfähigkeit ist und ein starkes Ehrgefühl entwickelt.

Gefährlich ist es allerdings, das Commitment in eine Metrik zu wandeln (“wir zählen, wie oft das Commitment nicht eingehalten wurde”) und im Extremfall disziplinarische Konsequenzen zu fordern. Das Team wird in diesem Fall schnell dazu übergehen die Gründe für das Versagen nicht bei sich selbst, sondern in den – ohne Frage immer vorhandenen – externen Einflussfaktoren zu suchen, möglichst wenig in einem Sprint zuzusagen, und darüber hinaus bei der Qualität zu schummeln um die gesetzten Ziele zu erreichen.

Und damit ist letztendlich niemandem gedient.

Wohin mit unfertigen Stories?

Es passiert den besten Scrum-Teams: am Ende eines Sprint konnte eine Story nicht vollständig im Sinne der Definition of Done abgeschlossen werden und es ergibt sich die Frage, wie mit der halb fertigen Lösung anfangen umgegangen werden soll.

Die kurze Antwort darauf ist sehr einfach: die Story gilt als nicht umgesetzt (in Scrum gibt es kein “halb fertig”), wird also auch nicht Bestandteil eines Release-Pakets, und wandert zurück in das Backlog. Dort wird sie behandelt wie jede andere Story auch, sie verliert in gewisser Weise also ihre Historie.

Dies hat jedoch eine Reihe von Implikationen, die für viele zunächst einmal sehr ungewohnt sind. Die betroffenen Teams bringen zumeist die folgenden Punkte an:

  • Die Story kann nicht einfach zurück in das Backlog, sie zu 95% abgeschlossen. Wir haben uns die die Punkte doch verdient. Zumindest aber die Punkte für die abgeschlossenen Arbeiten.
  • Wenn die Punkte der Story nicht in die Velocity eingehen sieht es so aus, als hätten wir in diesem Sprint einen Teil der Zeit nicht gearbeitet. Das wirft ein schlechtes Licht auf uns.
  • Da wir im nächsten Sprint die verbliebene Arbeit der Story schätzen, gehen uns Punkte in der Velocity verloren. Daher müssen wir sie jetzt schon einrechnen.

In diesen typischen Aussagen zeigen sich aber eine Reihe von Missverständnissen über Scrum. Daher sollte man sich einige Punkte vor Auge halten.

  • Die Velocity ist kein Time-Tracking-Instrument, sie dient nicht der externen Leistungskontrolle der Teams. Sie soll insbesondere dem Product Owner eine Indikation geben, welche Features bei den aktuellen Rahmenbedingungen realistischer Weise in den nächsten Sprints fertiggestellt werden können.
(Zu den Themen “Metriken in Scrum” und “Planung im Backlog” sind eigene Artikel geplant)
  • Im Scrum kommt es nicht darauf an wie viel Arbeit geleistet wurde, sondern welcher aktuelle Wert geschaffen wurde. Ziel der Teams ist es, möglichst viele Features in einem Sprint produktionsreif zu bekommen.
  • Mit jedem Sprintwechsel ist der Product Owner frei, die Priorität der Stories im Product-Backlog neu zu bewerten. Es kann also passieren, dass ein Feature das nur knapp nicht in Produktion gegangen ist dies auch niemals tun wird.

Wie also soll man mit nicht abgeschlossenen Stories nun umgehen?

Nicht abgeschlossene Stories werden vom Product Owner nicht abgenommen und wandern zurück in das Backlog. Ihre Story Points gehen nicht in die Velocity des abgeschlossenen Sprints ein. Die Story behält ihre Story Points, es wird nicht nur der Restaufwand neu geschätzt (es kann aber nötig werden, den Gesamtaufwand der Story auf Grund der Erfahrungen aus dem abgelaufenen Sprint neu zu schätzen).

Um die so entstehenden Fluktuationen in der Velocity richtig einzuordnen, wird zur Abschätzung der in den nächsten Sprints realisierbaren Features die durchschnittliche Velocity der letzten Sprints betrachtet – mindestens 3–4 Sprints sollten gemittelt werden.

Redesign Webseite

Alte Webseite

Auch wenn die erfolgreiche Umsetzung von Kundenprojekten jederzeit wichtiger ist als die Weiterentwicklung des eigenen Internetauftrittes, so kommt irgendwann der Augenblick, in dem ein komplettes Redesign der Webseite unausweichlich wird. Dieser Zeitpunkt ist für unseren bisherigen Auftritt gekommen. Neben der normalen redaktionellen Pflege haben wir die Überarbeitung unseres Auftrittes entsprechend unseren Anforderungen vorangetrieben. Auch die Strukturierung der Inhalte wurde an unsere jetzige Ausrichtung und Strategie angepasst.

Darüber hinaus wird eine dynamische Anpassung an verschiedene Ausgabegeräte immer wichtiger. Ein Kriterium, das einen komplett neuen Ansatz notwendig gemacht hat.

Und hier ist nun das Ergebnis der Bemühungen: Neben einem frischeren Design haben wir auch technische Verbesserungen eingeführt. Das erlaubt uns, zukünftig unter anderem über einen Blog-Bereich vermehrt Einblicke in unsere Arbeit geben zu können. Wir freuen uns auf das Feedback.

Kostenlose iOS-App

WasserstandAppUm die aktuellen Technologien nicht nur theoretisch sondern auch ganz praktisch für unsere Projekte zu verstehen, setzen wir regelmäßig Demonstratoren dieser Technologien um. Auch iOS und das Apple-Ökosystem sind für uns von großem Interesse. Und hier ist aus einem Demonstrator eine kleine Applikation entstanden, die wir kostenlos zur Verfügung stellen.

Natürlich wurde und wird diese App vollständig nach agilen Prinzipien entwickelt. Damit dient sie unter anderem dazu, auch neue Ansätze im agilen Vorgehen im Kleinen zu erproben. Dies entspricht unserer Philosophie, unseren Kunden keine Lösungen zu empfehlen, zu denen wir keine eigenen Erfahrungen beisteuern können.

Die Wasserstands-App (AppStore-Link) zeigt die Wasserstände der deutschen Bundeswasserstrassen an. Insbesondere für unsere Kunden in der Nähe des Rheins eine nicht zu unterschätzende Information.

Nach oben