Agilität basiert auf agilen Werten

Meiner Meinung nach wird Agilität oder eine Methode nicht falsch verstanden. Vielmehr wird nur auf die Methode geschaut und diese umgesetzt. In der Hoffnung, Produkte schneller und besser zu entwickeln. Dabei entsteht nur etwas mechanisches, aber nichts substanziell Neues. Vor einiger Zeit lernte ich einen agilen Coach kennen, der eine Organisation zuallererst auf die agilen Werte besann und ihr dabei half, diese zu verstehen und sie zur Verbesserung ihrer Arbeit einzusetzen. Ich beobachtete während der täglichen Arbeit viele tiefgehende Erkenntnisse der Kollegen und die aktive Auseinandersetzung mit der eigenen Arbeit und den eigenen Werten dazu. Die Methodik haben die Kollegen in kleinen Schritten etabliert. Das begeisterte mich, da auch für mich der übliche Weg war, entweder Scrum oder Kanban einzuführen.

Zur Erinnerung, die Werte aus dem agilen Manifest sind:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Scrum fügte vier weitere Werte hinzu:

• Fokus
• Mut
• Offenheit
• Commitment
• Respekt

Ich will diese Werte hier nicht erklären, dazu empfehle ich diesen kurzen Artikel.

Diese Werte sind für mich ohne Zweifel auch heute noch gültig und hilfreich. Blicke ich jedoch auf moderne agile Produktentwicklung, so fehlt mir in den bisherigen Werten Eindeutigkeit bezüglich Nutzerzentrierung, Schaffung von Mehrwerten, Bereitschaft zum Lernen und Streben nach Exzellenz.

Moderne Werte mit Modern Agile

Joshua Kerievsky adressierte 2016 mit Modern Agile, dass sich die agile Welt seit der Niederschrift des agilen Manifests in 2001 weitergedreht hat. So stellte er vier sehr konkrete Werte auf, die aber auf den bestehenden basieren. Die Werte aus Modern Agile passen zu meiner Arbeit in der agilen Produktentwicklung und spiegeln wieder, wonach ich dabei strebe.

1. Make People Awesome

Produkte werden vom Produktteam umgesetzt. Gute Produkte werden von einem guten Team geschaffen. Produkte werden von den Nutzern eingesetzt. Erfolgreiche Produkte werden von zufriedenen Nutzern zu diesen gemacht. Produktteam und Nutzer: Es geht um Menschen, die wir für die erfolgreiche Produktentwicklung in den Mittelpunkt rücken. Prozesse und Werkzeuge haben dort weniger etwas zu suchen.

Konkret heißt das, dass wir Nutzer verstehen und deren Bedürfnisse adressieren müssen, um begeisternde Produkte zu entwickeln. Für die Produktentwicklung rücken wir Nutzer und nicht uns selbst ins Zentrum. Und es heißt ebenso, dass wir Teams verstehen, deren Bedürfnisse adressieren und wir unsere Ziele mit ihnen teilen, um ein begeistertes Team entwickeln zu lassen. Für den Erfolg rücken wir das Team und nicht uns selbst ins Zentrum.

Relevante Stakeholder binden wir aktiv ein und entwickeln Empathie für ihr Handeln und ihre Bedürfnisse. Kurz gesagt: Alle Menschen, die ein großes Interesse an unserem Produkt haben, werden nicht ausgegrenzt, sondern verstanden, eingebunden, inspiriert und informiert. Das ist eine der Grundlagen für erfolgreiche Produkte.

Hey Product Managers, Your Customers are Humans

2. Deliver Value Continuously

Continuous Delivery ist eine großartige Sache. Produktteams können Software schnell produktiv stellen. Aus Nutzersicht ist die Aussage „Wir liefern alle zwei 2 Wochen eine neue Software“ irrelevant. Vielmehr sollte sie „Wir liefern alle 2 Wochen Mehrwerte“ lauten. Hiermit fokussiert sich ein Team viel mehr auf die Nutzer des Produkts und somit auf Mehrwerte. Und das erfordert in Teams und Organisationen ein Umdenken. Weg von der Feature-Factory. Hin zur tiefen Durchdringung und Qualifizierung von Nutzerproblemen, um den Wert von neuen Features danach zu gewichten. Ein Produktteam, das kontinuierlich Wert liefern will, muss sich intensiv mit Nutzer und deren Problemen auseinandersetzen. Zudem erfordert es, Erfolg messbar zu machen und diesen auch zu messen.

“The key to [defeating] waterfall is to realize that agilists value Outcomes over Features. The feature list is a valuable tool, but it’s a means not an end. What really matters is the overall outcome, which I think of as value to the customers.” Martin Fowler

3. Experiment And Learn Rapidly

Je länger eine Planung dauert, desto überflüssiger und falscher wird sie. Realität überholt Planung in Lichtgeschwindigkeit. Die Zeit die wir für zähe Diskussionen und komplexe Konzepte aufwenden, können wir doch lieber in eine schnell startende und iterative Umsetzung investieren. Und große Fragen und Unsicherheiten, lösen wir doch nicht durch theoretische Übungen. Wenn wir einfache Hypothesen aufstellen und diese schnell durch Experimente (z.B. mit Prototypen) beweisen oder widerlegen, haben wir etwas in der Hand (z.B. Nutzerfeedback, erlebte technische Unwägbarkeiten). Etwas ganz konkretes und erlebtes, anhand dessen wir lernen. Wir lernen, ob die Idee tragbar ist und in welche Richtung sie sich weiterentwickeln sollte.

Stehen ganz neue Themen an, empfehle ich eine schlanke aber intensive Methode wie den Design Sprint. Zur Bearbeitung kleinerer neuer Ideen empfehle ich A/B-Tests, Feature Toggles etc.. Für alles gilt: durch schnelles Experimentieren lernen Produktteam und Nutzer immer mehr über Probleme und deren Lösungen. Schritt für Schritt.

Hi Everyone:

Just a quick reminder that in-person debates are a terrible way to test the merits of ideas.

All they test is the verbal agility and rhetorical style of their participants.

Signed,
A Very Successful College Debator

— Carissa Byrne Hessick (@CBHessick) August 10, 2018

4. Make Safety A Prerequisite

Sicherheit ist eine Grundvoraussetzung, für Leistungsfähigkeit. Und somit für Kreativität, Mut, und Begeisterung. Ein Umfeld, das von Kontrolle und Misstrauen geprägt ist, bietet keine Sicherheit. Hier zählen Konformität und Einhaltung von Prozessen mehr als gute Ideen. Finden Menschen in so einer Umgebung gute Lösungen und kreative Ideen? Nein, denn das könnte zur Bestrafung führen. Daher gilt für uns, Sicherheit als eine der Voraussetzung für erfolgreiche Arbeit zu schaffen. Sicherheit schaffen wir durch Vertrauen und Verantwortungsverteilung. Dies ist die neue Aufgabe vom Agile Leadership.

Ganz wichtig: Erst durch die Sicherheit können die ersten drei Werte ihre Wirkung entfalten.

The post Modern Agile – Moderne Werte appeared first on Reza Nazarian.

Product Owner = Superman?

Das Lesen von Artikeln auf medium und die Teilnahme an Konferenzen wie MTP formen das Bild des Product Owners des allwissenden Supermans. Er muss einen riesigen Wissensschatz mitbringen, um das Wunderwerk zu vollbringen:

• Stories schreiben
• Backlog priorisieren
• Visionen erschaffen
• Roadmaps bauen
• Marktforschung betreiben
• Stakeholder verstehen und organisieren
• Kreativ-Workshops durchführen
• Innovation vorantreiben
• Produkte vertreiben
• User Experience ermöglichen
• Business Modelle ausdenken
• Finanzvorhersagen treffen

Dass dies relevante Aufgaben eines POs sind, ist richtig. Dass ein PO sich aber perfekt (inkl. vieler Methoden und Tools) und aus dem Stand mit allem auskennen muss, nicht. Ich will mich nun einmal auf die Kernfähigkeiten eines POs zurückbesinnen.

Was sind die Kernfähigkeiten des Product Owners?

Trennen wir uns mal von jeglicher Methodik, Vorgehensweise und von Tools. Was bleibt dann eigentlich noch übrig, mit dem sich ein PO richtig gut auskennen muss?

• Das Wichtige vom Unwichtigen unterscheiden
• Die wirklichen Probleme und Bedürfnisse von Kunden erkennen und adressieren
• Komplexitäten durchdringen
• Empathisch gegenüber Team und Stakeholdern agieren
• Von einer klaren Linie überzeugt sein, Nein sagen können

Diese Fähigkeiten (die erlernbar sind) sind das Fundament eines jeden Product Owners. Er läuft sonst Gefahr, sich immer mehr und mehr zu verlaufen, bevor sein Fundament steht. Überspitzt dargestellt: Design-Thinking, MVP, OKR und Lean Startup helfen auf der einen Seite nicht, wenn sich der PO mit unwichtigen Features beschäftigt, am Kunden vorbei plant, das Produkt nicht versteht, sich von Team bzw. Stakeholdern gelöst hat und nur situativ reagiert. Die genannten Methoden erfordern aus meiner Sicht erst das genannte Fundament. Hier ist der PO kein besserer PO, wenn er besonders viel davon kennt, sondern wenn er verstanden hat, wofür er sie einsetzt, und wie sie ihn schneller und besser machen.

Muss ein Product Owner technische Kenntnisse haben?

Nein, aber sie helfen eigentlich immer! Treffen sich Team und PO auf der Architektur-Ebene, finden beide Seiten einen einfacheren Zugang zueinander. War der PO früher selber Entwickler, versteht er es, dass die Lösung zunächst einfacher Probleme mehrere Tage dauern können. Es fällt beiden Seiten leichter, über technische Schuld, Refactoring und Tech-Stories zu sprechen.

Kennt oder beschäftigt sich der PO nur mit der fachlichen Seite, sehe ich ein Risiko: Die Isolation vom Team / der Elfenbeinturm (ein übliches PO-Antipattern). Das muss nicht passieren, wenn beide Seiten über Empathie verfügen und die jeweils andere Seite respektieren. Doch ein isolierter PO kann in Discoveries, unzähligen Canvasses usw. abdriften. Er verliert dann immer die Bindung ans Team, weil ihn kaum noch jemand versteht. Einen schönen Artikel dazu gibt es hier.

Wieder auf den Boden der Tatsachen zurückfinden

Die Suche nach dem PO-Superman ist nicht sinnvoll. Man wird ihn nur schwer finden. Diese Notwendigkeit ist stark aus dem Rockstar-Image des Product Owners geboren. Methoden und Werkzeuge sind nur Mittel zum Zweck. Sie einzusetzen, um gefühlt dran zu bleiben, hilft nicht. Wenn man aber das konkrete Problem/die Komplexität verstanden hat und sie versucht zu durchdringen, ist es richtig, die passende Methode zur Lösung zu suchen.

Dann teilen wir die Rolle einfach?

Aber ich möchte wieder zur langen Liste von Aufgaben zurückkehren. Das breite Spektrum lässt sich mit den genannten Kernfähigkeiten inhaltlich gut adressieren, es bleibt aber viel Arbeit. Ist das Produktteam groß, die Stakeholder-Landschaft komplex oder die Anzahl der Produkte groß, so muss sich der PO mit der Skalierung seiner eigenen Rolle beschäftigen. Dazu hat Roman Pichler drei sinnvolle Optionen beschrieben. Kurz gesagt managed der PO ein PO-Team (z.B. mit einem Business Analysten und einem UX-Experten) oder das Produkt wird zerteilt. Meiner Meinung nach sind das die richtigen Optionen. Beim PO-Team ist liegt die Verantwortung immer noch beim PO und nicht verteilt. Die Zerteilung von Produkten ist nicht einfach, schafft aber auch klare Strukturen. Ein sehr ungünstiges Modell ist die Zerteilung der PO-Rolle in ein Zwei- („PO-Technisch“ und „PO-Fachlich“), Drei- („PO-Technisch“, „PO-Fachlich“, „PO-Management“) oder gar Viergestirn („PO-Technisch“, „PO-Fachlich“, „PO-Organisatorisch“, „PO-Feelgood-Management“). Zum Einen entsteht diese Zerteilung meist am Reißbrett und hat ihren Ursprung in alten Abteilungsstrukturen (Produktmanagement, Software-Development, Projektleitung). Zum Anderen fördert eine solche Konstellation komplexe und unklare Wege in Kommunikation, Entscheidung und Verantwortung.

The post Was muss ein Product Owner können? appeared first on Reza Nazarian.

• Stakeholder außerhalb des Teams denken weiterhin in Aufwandsschätzungen, Projektbudgets, Gantt-Charts und Ressourcen („1 Entwickler braucht 4 Tage, 2 brauchen 2“). Story Points und Team-Velocity werden mit hoher Komplexität auf die alten Artefakte umgerechnet.
• Das Entwicklungsteam entscheidet sich für die Verwendung von idealen Manntagen. Es hat aber keinen sinnvollen Umgang mit externen Abhängigkeiten und Risiken gefunden. Ein Teil des Teams schätzt risikoreiche Stories höher als der andere Teil der nur in ideale Manntage schätzt.
• Der Fokus des Schätzens liegt auf der Zahl an der Story. Ob nach Abarbeitung der Story die Schätzung gut oder schlecht war, ist zweitrangig. Das Team lernt nicht daran.

Ist diese Zahl wirklich so wichtig?

Die Idee des Schätzens im agilen Kontext ist, dass das Team an seinen Schätzungen lernt. Es baut ein gemeinsames Verständnis zu Anforderungen, Zielen und Machbarkeit auf. Doch ist die geschätzte Zahl an einer Story wirklich so wichtig für das Entwicklungsteam? Ich meine, dass das Schätzen nur Mittel zum Zweck ist. Sobald ein Team gut darin ist, Stories zu durchdringen, zu verstehen und sie anhand von Komplexitäten zu zerteilen oder zusammenzuführen, ist die eigentliche Zahl überflüssig. Denn wenn das Team ein verlässliches Gefühl dafür entwickelt, welche Stories zusammen in einen Sprint passen, hilft die Zahl nicht mehr. In der Praxis hieße das, dass wir so etwas wie ein Backlog-Refinement weiterhin nutzen, um Stories vorzustellen, zu hinterfragen und anders zu strukturieren. Die Schätzrunde fällt aber weg.

Von der Altlast zum Lernen

Der Fokus der agilen Transition eines Teams liegt daher zunächst darauf, dass die Schätzungen eines Teams nur dem Team dienen sollen. Das bedeutet, dass das Team nicht deswegen schätzt, um externe alte Prozesse zu bedienen (die Erreichung dieses Ziels ist in vielen Organisation eine große Aufgabe). Sehr hilfreich ist auch die Einführung der Komplexität für Story Points. In idealen Manntagen geschätzte Stories lassen sich sicherlich gut in alte Strukturen hinein berichten. Übliche Risiken und externe Abhängigkeiten fließen aber gar nicht in die Schätzung mit idealen Manntagen ein. Diese sind also nur bedingt hilfreich.

Als Nächstes lernt das Team anhand der Schätzung, Sprints optimal auszulasten und ob an der Schätzung etwas verbessert werden muss. Wenn das länger sicher funktioniert kann auf die eigentliche Schätzzahl verzichtet werden.

The post Schätzung – Die Spitze des Eisbergs appeared first on Reza Nazarian.