Liebes Scrum-Team, machen eure Produkte die Nutzer happy?

Jede Firma hat Kundenorientierung in ihrer Vision oder Missions-Statement, aber ist sie das wirklich? Wie weiss ich als Mitarbeiter eines Entwicklungsteams, ob das der Fall ist? Wie spüre ich das?

Diese Fragen wollen wir in diesem Beitrag durchleuchten. Starten wir mit einer einfachen Frage an das Team:

Wieviele Personen sind zwischen dem Benutzer und dem Development Team?

Typischerweise sieht man so was:

Häufig stehen Projektleiter, Business-Analysten, Requirements Engineers, Stellvertreter, Steering Komitees, Usability-Experten, Tester oder QA-Teams zwischen dem Team und dem Benutzer.

Den Benutzer verstehe ich als unsere wichtigsten Kunden, denn wenn dieser nicht glücklich ist, wird auch niemand für das Produkt zahlen (Sponsor) oder auch sonst kein Marktteilnehmer Interesse daran haben.

Was kann der Product Owner machen, um diese Situation zu verbessern?

Ich habe dafür 6 Tipps gesammelt:

1. Den Benutzer einladen

Anstatt sich auf die perfekten Anforderungen zu fokussieren und dort extrem viel Zeit zu investieren, würde ich empfehlen, den Benutzer näher zum Team zu bringen. Wollen wir einen Benutzer mal in die Sprint Review einladen? Oder in den Teamraum und zeigen, wie wir arbeiten und ihn um Feedback zum aktuellen Feature bitten?

Was kann ich tun, um mich als Product Owner noch mehr von diesem System zu lösen und dafür mehr auf die Produkt-Strategie fokussieren?

2. Teams zusammenführen anstatt zu aufzuteilen

Anstatt Teams in spezialisierte Silos aufzuteilen, wie zum Beispiel ein Testteam oder ein QA-Team, welche dann Arbeit weitergeben, um selber «produktiver» weiterentwickeln zu können, würde ich empfehlen, Teams zusammenzubringen. Zu oft habe ich schon «Bug-Ping-Pong» zwischen Teams gesehen und es nie als effizient erachtet.

Ich würde stark empfehlen, Teams zusammenzubringen, zu pairen oder zu mobben und zusammen Features (Product Backlog Items) abzuschliessen und fertig zu machen (Definition of Done).

(Lesen Sie dazu den Blog «5 Praktiken die bei der agilen Software-Entwicklung helfen»

3. Feedback-Momente einführen

Anstatt Product Backlog Items zu akzeptieren oder zu «rejecten», würde ich als Product Owner empfehlen, eine andere Art der Zusammenarbeit zu suchen. In diese Richtung gehen zum Beispiel «Feedback-Momente», die es ermöglichen den Benutzer direkt ins Team bringen und ihn Feedback geben lassen kann.  Feedback-Momente können das Team empowern, zu allem was sie brauchen und sie mit den Benutzer-Problemen konfrontieren anstatt vorgekaute Lösungen abzuliefern. Das hilft auch bei der Motivation.

Bild: Ein Product Owner rejected ein Feature

PS: Akzeptieren oder Rejecten impliziert auch eine Hierarchie, die wir in einem Scrum Team nicht haben möchten. Also nennt es doch Feedback-Momente.

4. Mehrnutzen feiern anstatt statistik-gesteuerte KPI’s

Anstatt Velocity, Auslastung und «Feature-Completeness» zu feiern, sollten wir Erfolg als Impact für den Benutzer definieren. Was wird in der Welt des Benutzers besser durch unser Produkt?

Wie kriegt das Team mehr Empathie für den Benutzer?

Mehr Ideen dazu in dem Twitter Stream von mir.

5. Grosse Features in kleinere Ziele und Happen runterbrechen

Anstatt grosse Features (Large Batches) über mehrere Sprints abzuarbeiten, würde ich empfehlen, in kleinen Schritten zu arbeiten. Wie können wir die grosse Produktvision in umsetzbare Sprint-Goals runterbrechen? In tägliche Ziele, die wir als Team feiern und messen können?

Es ist nicht intuitiv, in kleinen Batches zu arbeiten, aber der Fortschritt und die Diszipin bringen schneller Erfolge und lassen das Produkt schneller lieferbar werden.

6. Sprintziele delegieren

Anstatt alles selber zu machen, überlege ich mir, was ich als Product Owner delegieren kann. Kann ich das gesamte Sprintziel an eine Abteilung delegieren?

Gedanktenbeispiel: «Für die nächsten 2 Sprints arbeiten wir an Features für die interne Marketing-Abteilung. Bitte sprecht direkt mit dem Stefan von der Abteilung und haltet mich einfach auf dem Laufenden. Ich werd am Daily Scrum immer dabei sein.»

Das heisst, ich delegiere die Verantwortung über den Inhalt des Produkts an eine andere Person weiter und hole mir nur mehr Informationen für Entscheidungen, wenn ich sie brauche.

Könntest du ruhig bleiben als Product Owner und das Team für die nächsten zwei Sprints alleine laufen lassen?

Wieso nicht? Wie weit ist der Kunde entfernt vom Team?