Seminar buchen

Schlagwort: Karlsruhe

Veröffentlicht am

Welche Fähigkeiten braucht ein Product Owner in Scrum?

Der Product Owner ist eine der drei Rollen in Scrum. Er verantwortet den Produkterfolg. Doch welche Fähigkeiten helfen dabei, diesen zu erreichen?

Überzeugungskraft

POSpeaking

Immer weniger Menschen möchten heutzutage an fraglichen, vielleicht gar sinnlosen Projekten arbeiten. Software entwickeln als Lohn-und-Brot Job? Egal, ob das Produkt jemand später einsetzt? Das Entwicklungsteam muss an die Vision des Product Owners glauben, um motiviert zu sein.

Dazu braucht es einen überzeugenden Product Owner. Und nicht nur das Team will glauben können, auch die Kunden und Anwender des Scrum-Teams. Beide muss der Product Owner davon überzeugen, dass er die richtigen Entscheidungen trifft zum Wohl des Produkterfolgs.

Was Sie als Product Owner zur Stärkung tun können:

  • ein Produkt suchen, hinter dem Sie wirklich stehen
  • ein Rhetoriktraining besuchen, um Ihre Botschaft zu verstärken
  • Visual Facilitation erlerne, also mit Bildern und Metaphern kommunizieren
  • die Zukunft des Produkts mit guten Geschichten lebhaft ausmalen

Fachwissen über die Domäne und Durchsetzungsfähigkeit

PuzzleDer Product Owner trifft nahezu täglich Produktentscheidungen: In welcher Reihenfolge werden die Anforderungen umgesetzt, welche kommen hinzu, welche werden gestrichen? Und in welcher Ausprägung wird eine Anforderung realisiert? Diese Entscheidungen benötigen ein Fachwissen in der Domäne des Produkts und die Fähigkeit, die Entscheidungen dann auch durchsetzen zu wollen.

Was Sie als Product Owner zur Stärkung tun können:

  • Fachzeitschriften und Bücher zur Domäne lesen
  • Fachkonferenzen besuchen und Kollegen interviewen
  • Sich öfter in einem klarem „Ja“ und „Nein“ üben, auch wenn es unbequem sein sollte

Empathie für den Kunden und Anwender

FeedbackUm die richtigen Entscheidungen zu treffen, braucht es aber nicht nur Fachwissen sondern auch ein gutes Gespür für den Kunden, die Anwender und den Markt.

Gerade technischen Product Ownern fällt es oft schwer, die Nutzerbrille aufzusetzen. Was will der Anwender wirklich? Was sind seine Bedürfnisse? Warum möchte er etwas?

Was Sie als Product Owner zur Stärkung tun können:

  • In User Stories den WARUM-Teil des Satzes vom Anwender erläutern lassen
  • Ein Werkzeug wie das Vision Board verwenden, um den Anwender besser zu verstehen
  • Den (potenziellen) Anwender bei seiner täglichen Arbeit beobachten
  • Beim Formulieren von Anforderungen auf technisches Jargon verzichten

Teamfähigkeit

TeamDer Product Owner ist Teil des Scrum Teams. Und der Erfolg dieses Teams steht und fällt mit dem Zusammenspiel aller Teammitglieder. Wie gut findet man gemeinsame Lösungen für Konflikte und Probleme statt sich hinter seiner Rollenbeschreibung und Verantwortlichkeiten zu verschanzen?

Was Sie als Product Owner zur Stärkung tun können:

  • Lassen Sie sich von Ihrem Entwicklungsteam bei der Erfüllung Ihrer Rolle helfen. Auch Teammitglieder können User Stories schreiben
  • Fragen Sie Ihr Entwicklungsteam, ob Sie an der Retrospektive teilnehmen dürfen
  • Betrachten Sie sich und das Team als „alle im selben Boot“ und suchen Sie aus dieser Haltung Lösungen

Diese Beitrag wurde inspiriert durch Fragen der Teilnehmer meines gemeinsamen CSPO-Trainings mit Peter Beck.

Veröffentlicht am

Ihre Ideen erfolgreich ins Unternehmen einbringen mit Fearless Journey

(c) Paul WeberVeränderung ist immer eine Herausforderung. Jeder von uns kennt warscheinlich den Moment, wenn eine gute Idee offensichtlich die passende Lösung für eine Situation ist. „Wir müssten jetzt einfach nur X machen, dann würde Y für uns gar kein Problem mehr darstellen.“

Doch dieses Wissen anderen Menschen zu vermitteln, ist nicht immer leicht. Was für einen selbst so logisch und beinahe selbstverständlich richtig erscheint, ist oft für andere  überhaupt nicht nachvollziehbar. Es gibt andere Sichtweisen, andere Meinungen, andere Ideen. „Das kann so bei uns nicht funktionieren“ oder „es wäre besser, nochmals weitere Optionen zu untersuchen, bevor wir…“ haben Sie vielleicht auch schon einmal gehört?

Doch wie schaffen Sie es, Ihre Idee zum Wohl Ihrer Abteilung und Ihres Unternehmens einzuführen? Wäre es nicht schön, wir könnten die Herausforderung der Veränderung leichter angehen?

Fearless Journey - Jetzt auf DeutschGute Neuigkeiten: Es geht leichter.

Die kostenfreie Simulation „FearlessJourney“, welche nun schon seit 2011 weltweit im Einsatz ist, gibt es nun auch auf Deutsch. Als Training für einen selbst oder (noch viel besser) in der Gruppe entwickeln Sie damit einen Satz von Strategien, wie Sie Ihre Idee am Besten einführen können.

Die im Spiel enthaltenen praxiserprobten 48 Strategien basieren auf dem in der agilen Welt bekannten Buch „Fearless Change“, welches ich – nicht erst nachdem ich Linda Rising persönlich kennenlernen durfte – als Ergänzung zu dem Spiel auch Ihnen gerne empfehle.

Wenn Sie auch Ihre Ideen auf fruchtbaren Boden aussähen wollen, können Sie FearlessJourney (in Deutsch und weiteren Sprachen) jetzt hier herunterladen.

Veröffentlicht am

Facilitate it – Open Space noch besser

Am Wochenende fand in Karlsruhe die .NET Open Space Süd Unkonferenz statt. Nachdem es schon zahlreiche Feedbackbeiträge dazu gibt, werde ich nur einen konkreten Aspekt der Veranstaltung hier aufgreifen, der mir besonders am Herzen liegt.

Während der Session-Themenvorstellungen beschlich mich das Gefühl, dass es einige Hosts gab, die sich eher als Vortragende denn als Ausrichter einer Session sehen und auch mir selbst war kurze Zeit nicht klar, welchen Charakter die von mir angebotene Session haben soll. Zugegebener Maßen ist das Phänomen des Frontal-Vortragenden nicht immer verhinderbar und Wissensgefälle sind ja auch erwünscht.

Die Frage die ich mir stelle, ist jedoch, wie man eine Session so gestalten kann, dass sie trotz eines solchen Gefälles andere miteinbindet und dort abholt, wo sie im Moment stehen. Ein Zitat, welches mich seit längerem begleitet ist „Seek first to understand, then to be understood.“

Möchte ich also einer Gruppe ein Thema näher bringen, ist es für mich wichtig zu erkennen, wo die Gruppe steht, damit ich sie verstehen kann. In letzter Zeit habe ich einige Moderations- und Gruppenarbeitsseminare besucht und nun einen Werkzeugkoffer, der den Sessionowner weiterbringen kann: Methoden zur Einbindung von Teilnehmern, Kommunikationswerkzeuge und Umgang mit Material.

In der von mir angebotenen Session „Architektur in agilen Projekten“ konnten Teilnehmer eine Version solch einer moderierten Gruppenarbeit kennenlernen und das positive Feedback bestärkt mich, solche Versuche in Zukunft wieder durchzuführen. Meine eigene Haltung war eher die des Fragenstellers, der für die Gruppe Notizen macht (manche nennen es Visual Facilitation). Während der Session konnte ich feststellen, dass immer dann, wenn Diskussionen stagnierten, die Blicke zum Flipchart gingen und dann wieder dort angeknüpft werden konnte, wo der Austausch vorher begonnen hatte, was für einen guten Fluß während der Session sorgte.

Ich hoffe, einige dieser Techniken pragmatisch beim nächsten Open Space  an Hosts in einer eigenen Session weitergeben zu können, um die Ergebnisse der Gruppenarbeiten weiter zu verbessern.

Auch das Erwartungsmanagement halte ich für wichtig: Ein Sessionhost sollte klar signalisieren, welchen Austausch er sich wünscht, ob er wissen hat oder sich eher als Fragesteller sieht. Ein Open Space lässt durchaus zu, sich mit einer Gruppe zusammenzufinden, wenn man selber keine Ahnung von einem Thema hat.

Ich bin davon überzeugt, dass ein Open Space genauso von einem Prozesswächter profitiert, wie der Scrum-Prozess von einem ScrumMaster. Vorbildlich hingen die Regeln eines Open Space am Wochenende überall im Gebäude. Die Ermutigung dazu, diese auch zu befolgen, hätte manch einem vielleicht ein noch besseres Erlebnis beschert. Für die einen ist es ein alter Hut, für die anderen ist das Format einfach neu gewesen und die kurze Erläuterung der Regeln hilft dem Spirit einer solchen Veranstaltung.

Bis zum nächsten Open Space in Karlsruhe möchte ich mich mit Menschen austauschen, die Open Spaces als Facilitator oder Moderator begleitet haben, um beim nächsten NOS  dieses Wissen miteinbringen zu können. Wenn jemand hier weitere Erfahrungen gesammelt hatte, freue ich mich über einen Kommentar / Tweet.

Bitte versteht meine Anmerkungen als konstruktive Kritik im Sinne der kontinuierlichen Verbesserung. Mir hat der Open Space sehr gut gefallen und ich freue mich, auf das nächste Jahr.

Und eines wünsche ich mir noch: Flipcharts und ein bis zwei Moderationskoffer, das Handwerkszeug für Gruppen. Bleibt nur noch die Frage: Welche Firma spendet einen?

Veröffentlicht am

Walk my talk

Was erwartest Du von einem Berater? Er soll Erfahrung haben in dem Thema, dass für Dich wichtig ist und wenn er diese nicht hat, die Fähigkeit verwenden, sein vorhandenes Wissen in kurzer Zeit mit für Dich relevanten Informationen zu verknüpfen, um Dich dann auf Deinem Weg sinnvoll zu begleiten.

Schön ist es, wenn er auch das selber tut, was er anderen als Lösungsvorschlag anbietet. Wie sagen das die Amerikaner so schön? „Walk your talk.“ Das zeigt Überzeugung, denn wenn man den gleichen Maßstab an sich selbst anlegt und die selben mehr oder weniger abenteuerlich-innovative Ideen lebt, lernt man noch mehr darüber und ist ein Vorbild für andere.

Als Scrum Coach ist es mir wichtig, meinen Kunden gegenüber die Transparenz vorzuleben, die er in seinen Teams erwarten darf. Wie geht das? Ein leichtgewichtiger agiler Prozess zur Selbstorganisation bietet sich an: Es gibt ein Coaching Backlog, gemeinsame Reviews und Retrospektiven über den Arbeitsprozess und natürlich ein Taskboard, an dem ich meine eigene Arbeit organisiere. Jeder ist eingeladen, in meinem Büro vorbeizuschauen und sich sein Bild zu machen, mich anzusprechen bei Fragen. So versuche ich das umzusetzen, was ich anderen empfehle. Ein Schrank und die von uns agilen Menschen so oft verwendeten „Stickies“ sind ausreichend hierfür.

Transparenz ist ein wichtiger Grundstein für Vertrauen und davon darf unsere Arbeitswelt gerne noch mehr erleben – in Kollegen, Vorgesetzte und auch Externe.

Und wie siehst Du das Thema Transparenz?

Veröffentlicht am

Story Points verständlich erklärt

Bei meiner Recherche im Internet und der gängigen Literatur habe ich gute Beispiele zur Vermittlung des Konzepts von Story Points gesucht.

Bis auf Mike Cohns Erläuterung in seinem Buch „Agile Estimation & Planning“ habe ich wenig leicht verständliches gefunden. Auf die Gefahr hin, dass ich vielleicht einfach eine gute Quelle verpasst habe und das Rad nun neu erfinde, möchte ich meinen Beitrag zu dem Thema zu leisten, um Story Points nochmal auf den Punkt zu bringen:

Storypoints sind eine Einheit, die die Größe einer User Story beschreiben.

Wie ist nun diese Größe definiert? Diese Frage ist nicht pauschal zu beantworten. Es fließen viele Faktoren ein, die von den Individuen abhängen, die diese „Größe“ definieren.

Ein Team könnte eine Größe zum Beispiel so definieren:

* Die Größe einer Story ergibt sich aus ihrer Komplexität. Die Komplexität hängt davon ab, ob und wieoft welche Schichten unseres Architekturmodells durchstoßen werden…

Ein anderes Team vielleicht so:

* Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen…

Wie auch immer ein Team diese Größe definiert, eines ist wichtig dabei: Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der „Struktur“ der User Story. Oder gleich um ein ganzes Bündel von diesen Eigenschaften.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.

Ein erfahrenes Team schafft einfach mehr bzw. größere Stories in der selben Zeit als ein unerfahrenes Team, das beeinflusst die Größe nicht.

Was bedeutet das nun für Schätzungen:

Die Diskussionen darüber, wer eine Story umsetzt, sind nichtig. Ob erfahrener oder unerfahrener Entwickler: Es spielt keine Rolle für die Schätzung einer Story. Das unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert werden und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden, dann hat man die Größe.

Wie kann man nun mit Story Points einen Releaseplan erstellen?

Der Zeitfaktor kommt in Scrum dann durch die Teamgeschwindigkeit in das System. Diese so genannte Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration, also:

V = ø (SUM(Story Points der erfolgreich abgeschlossenen Stories im Sprint))

Wenn ich jetzt für alle Product Backlog Items Story Point Werte schätze, sie in der Reihenfolge durch eine Form von Priorisierung sortiere und weiß, wieviele Storypoints mein Team je Iteration umsetzt (Velocity), kann ich die Aussage treffen, in welcher Iteration ich ein Feature liefern kann.

Während der Arbeit entstehen also gemessene Zeitwerte, die ich dann auf die Größe appliziere. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man überlegt, wie schwer es ist, so etwas komplexes wie die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen. Es gibt ziemlich dicke Bücher über nur dieses Thema und eher weniger als mehr Projekte, die gute Schätzungen vorweisen können.

Kleinteilige Diskussionen vermeiden

Ein anderer Aspekt ist der, dass durch die Betrachtung der Charakteristika einer Story vermieden wird, zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente hineinzugehen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitenanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.

Einfacher in der Praxis

In der Praxis ist das Thema „Story Points“ interessanterweise einfacher, als es tatsächlich zu erklären ist.

Nimmt man eine Referenzstory und einigt sich darauf, dass diese eine mittlere Größe hat, gibt das Team der Story zum Beispiel die Größe „5“. Andere Stories werden dann mit dieser verglichen und als gleich groß, kleiner oder größer eingestuft. Die Agilisten nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Die seltsame Skala dient unter anderem dazu, auszudrücken, dass um so komplexer die Story ist (also umso größer), die Genauigkeit der Schätzung in die Binsen geht.

De facto sollte man mit sehr großen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für dieses Story – aber das ist ein anderes Thema.

Update vom 14.09.2018: Mit meinen Kollegen von DasScrumTeam habe ich ein kostenfreies Online-Video-Coaching produziert, das User Stories sehr anschaulich vermittelt.

Veröffentlicht am

Technische User Stories gehören nicht ins Product Backlog

Die agile Gemeinde hat dieses Thema schon öfter diskutiert – mit sehr unterschiedlichen Ansichten. Daher möchte ich diesen Beitrag nutzen, um meine Meinung darzustellen und sie zu begründen. Meine Erfahrung aus der Rolle des Entwicklers fließen in mein Verständnis ebenso ein, wie die wirtschaftliche Betrachtung der Softwareentwicklung.

Das Product Backlog ist ein Ort, an dem der Product Owner eine Bestellung an sein Team aufgeben kann. Häufig finden hier User Stories Verwendung.

Nach Mike Cohn haben User Stories die 3 C’s als Kriterien:

  • Card: Eine Story sollte auf eine Karteikarte passen.
  • Conversation: Eine Story ist keine vollständige Anforderung oder dergleichen. Es ist ein Versprechen über eine Konversation, die während der Planungssitzung und beim Estimation Meeting noch geführt werden soll.
  • Confirmation: Die Definition, wann eine Story erfüllt ist, sollte auf der Rückseite stehen in Form eines User-Acceptance-Tests, damit das Team weiß, welcher Maßstab im Review Meeting angelegt wird.

Würde ein Product Owner bei seinem Team bestellen, dass eine Komponente von Version 1.2 auf Version 1.3 aktualisiert werden soll? Möchte er diese Konversation mit seinem Team führen? Die Frage ist, ob dadurch ein Mehrwert für ihn aus Geschäftssicht entsteht: Braucht er ein Feature der Komponente, dass nur im neuen Release enthalten ist? Sind Fehler behoben, die den Anwender betreffen?

Jetzt wird der erfahrene Entwickler vermutlich auf die technische Schuld hinweisen. Vollkommen zurecht: Wer in größeren Projekten arbeitet, der kennt die Themen der Komponentenaktualisierung, umfangreicher Refactorings und Austausch ganzer Bausteine.

An dieser Stelle gibt es zwei Optionen:

a) Der Product Owner bestellt ein Feature, dass die Aktualisierung bzw. Bearbeitung der technischen Schuld tatsächlich auch beinhaltet. In diesem Fall werden entsprechende Tasks zu der User Story erstellt und wie gewöhnlich bearbeitet.

b) Der Product Owner interessiert sich eigentlich nicht für die notwendigen Tätigkeiten aber jeder gute Entwickler weiß, dass diese Veränderungen gebraucht werden, um das Fortbestehen und die Wartbarkeit der Anwendung zu sichern.

Das Team sollte im Sprint Planning dann entscheiden, wieviel Aufwand es erwartet in Bezug auf die technischen Veränderungen und dementsprechend das Commitment anpassen, dass es dem Product Owner gibt. In den Velocity / Burndown Graphen ist eine Anmerkung des Product Owners sinnvoll, warum eine vermutlich eingeschränkte Velocity nach der Iteration erreicht wird.

Dies ist eine kritische Stelle der Interaktion zwischen dem Team und dem Product Owner, denn dieser muß dem Team vertrauen, dass das Team wirklich nur die notwendigen Arbeiten in einem Rahmen durchführt, der es nachwievor ermöglicht, echten Geschäftswert zu schaffen. Nutzt das Team diese Entscheidungsgewalt als „technischen Freibrief“ aus, sollte der ScrumMaster diesen Konflikt thematisieren und lösen.

Nur ein verantwortlicher Umgang mit Ressourcen und ein Zusammenspiel aus Technik und Business sichern langfristig den Erfolg.

Machtkämpfe zwischen Produktverantwortlichen und Entwicklern oder Architekten haben hier keinen Platz.

Die Abarbeitung der technischen Tasks wird wie gewohnt im Sprint Burndown dargestellt. Hier herrscht also Transparenz für den Product Owner. Die kritische Frage, warum gewisse Tätigkeiten umbedingt erfolgen müssen, darf gestellt werden und sollte vom Team beantwortet werden ohne dabei eine Rechenschaft abzulegen. Das Team entscheidet selber, wie es produziert.

Hier kann es hilfreich sein, wenn der ScrumMaster beiden Seiten hilft, die Belange des jeweils anderen zu verstehen, für Transparenz zu sorgen und einen tragfähigen Kompromiss zu entwickeln. Ein farbliches Hervorheben von Tasks der „technical debt“ könnte eine Option sein, das Verhältnis für alle Transparent zu halten. Kippt das Verhältnis in die falsche Richtung, sollte es thematisiert werden.

Technische Stories gehören also nicht ins Product Backlog. Technische Tasks gehören hingegen zur Arbeit des Teams. Die Balance zu halten, liegt in der Verantwortung aller Beteiligter.