Agile

• Agile Softwareentwicklung
• Teamarbeit
• Spaß an der Arbeit
• Schnellere Ergebnisse
• Sprints

Die Antwort, die wir eigentlich im Sinn haben, ist für viele überraschend:
Das Done Product Increment

Warum ist das wichtig?

Ohne ein Produkt, welches wir entwickeln wollen, ist Scrum unnötig. Wir brauchen kein Team, keine Regeln, keine Zusammenarbeit. Dieses Produkt ist aber nicht das große endgültige Ziel, sondern es wird schrittweise in Sprints
von maximal 4 Wochen Länge entwickelt. Am Ende eines jeden Sprints erwarten wir ein Inkrement des Produkts, welches einen Mehrwert darstellt und produktiv eingesetzt werden kann – es muss also „Done“ sein.
Leider legen unserer Erfahrung nach zu wenige
Scrum Teams wirklich wert auf diese Idee von Done. Häufig wird das Product Increment am Ende eines Sprints nicht ausgeliefert und das Entwicklungsteam hat deshalb keine echte Motivation, ein Done Increment zu liefern. Das Resultat
sind qualitativ nicht ausreichende Ergebnisse, an denen für den Produktivbetrieb noch einiges nachgearbeitet werden muss. Das schränkt den Product Owner in seiner Entscheidungsfähigkeit ein. Er kann oft nicht beurteilen, was tatsächlich noch zu
tun ist, um ein Release der Software wirklich durchzuführen.

Der Weg zu Done

Ein Done Increment entwickelt sich nicht einfach so. Es gehören einige Dinge dazu, die es einem Entwicklungsteam in Scrum erleichtern, Systeme und Anwendungen zu entwickeln, die wirklich „releasable“ sind. Wir zeigen einen
möglichen Weg auf, bei dem ein Entwicklungsteam dem Done Increment Stück für Stück näherkommt.

Selbstverantwortung übernehmen

Der erste Schritt ist, die Verantwortung für das Done Increment nicht bei Anderen zu suchen, sondern sie selbst zu übernehmen. Unsere Anwender, Kunden und die Organisation, in der wir arbeiten, bieten uns keine
perfekte Umgebung. Wir müssen unter den bestehenden Rahmenbedingungen dafür sorgen, auslieferbare Software zu entwickeln. Dafür erarbeiten wir Kriterien, die diese Auslieferbarkeit gewährleisten: die Definition of Done.

Ein cross-funktionales Team sein

Eine grundlegende Anforderung an ein Scrum Entwicklungsteam ist: es soll cross-funktional sein. Das heißt, das Entwicklungsteam muss in der Lage sein, ein Done Increment herzustellen. Das funktioniert oft in
drei Schritten:

1. Daran glauben, dass Cross-Funktionalität möglich ist
2. Strategien entwickeln, um Wissen im Team zu verteilen
3. Echte Zusammenarbeit als Team

Scrum lernen und verstehen

Dieser Punkt klingt zunächst trivial. Die 11 Regeln, die Scrum ausmachen, sind einfach und wirken offensichtlich. Wichtig ist aber, hinter diesen Regeln die Prinzipien zu entdecken. Scrum basiert auf der empirischen Prozesssteuerung:
Transparenz, Überprüfung und Anpassung. Dabei werden konkrete Erfahrungen genutzt, um das eigene Vorgehen konsequent und kontinuierlich zu verbessern. Alle Regeln in Scrum sind danach ausgerichtet.
Daneben sind die Werte Offenheit,
Respekt, Fokus, Commitment und Mut nötig, um nachhaltig mit Scrum erfolgreich sein zu können.

Done definieren

Ein Entwicklungsteam muss nicht nur wissen, welche Qualitätskriterien für sein Produkt erfüllt sein müssen, es muss auch in der Lage sein, diese Kriterien zu erreichen. Die Maßnahmen dafür beschreibt das Team in einer Definition of Done.

Die Definition of Done ist abhängig vom Produkt und vom Kontext der Produktentwicklung. Eine App fürs Online Banking hat andere Qualitätsanforderungen als ein medizinisches Gerät und braucht deshalb andere Maßnahmen, um diese Qualität herzustellen.

Als Team zusammenwachsen

Es geht in Scrum nicht darum, als Einzelner möglichst tolle Leistungen zu erbringen. Viel wichtiger ist es, als echtes Team zusammen zu arbeiten. Die Gesamtleistung eines gut funktionierenden Teams übertrifft dabei die Leistungsfähigkeit
der einzelnen Mitglieder bei weitem. Dabei arbeitet das Team als Ganzes am gemeinsamen Ziel, z.B. dem Sprintziel.

Quality first!

In Scrum ist Qualität nicht verhandelbar. Sie wird nicht zu Gunsten einer kurzfristig schnelleren Entwicklung ignoriert. Teams, die mit Scrum wirklich erfolgreich sein wollen, dürfen deshalb nicht der Versuchung erliegen, Abkürzungen
in Bezug auf die Qualität zu akzeptieren, um noch eine weitere Funktionalität liefern zu können.

Geeignete Architekturen einsetzen

Da sich Anforderungen in Scrum laufend ändern können, muss die Software flexibel und erweiterbar sein. Die Softwarearchitektur entwickelt sich zusammen mit der Software. Gute Prinzipien der Softwareentwicklung wie
lose Kopplung / starke Kohäsion, Self-contained Systems oder konsequentes Refactoring helfen dem Team dabei.

Automatisierung einsetzen

Werkzeuge allein machen kein gutes Team. Aber die richtigen Werkzeuge können ein gutes Team dabei unterstützen, noch besser zu werden und auf die vielfältigen Anforderungen in der Softwareentwicklung zu reagieren.
Entwicklungsteams
sollten nach technischer Exzellenz streben und Werkzeuge gezielt einsetzen, wo diese sie bei der Softwareentwicklung, -verteilung und -betrieb unterstützen. Prinzipien wie Testgetriebene Softwareentwicklung oder DevOps können hilfreiche und sinnvolle
Praktiken für Scrum Entwicklungsteams sein.

Unfertige Features isolieren

Scrum Teams müssen spätestens am Ende eines Sprints ein auslieferbares Product Increment liefern. Häufig stehen Teams vor der Herausforderung, dass zu diesem Zeitpunkt noch unfertige Funktionalität in der Codebasis
vorhanden ist, die nicht auslieferbar ist.
Entwicklungsteams sollten Strategien entwickeln, um diese unfertigen Teile der Software isolieren zu können, damit trotzdem ein Done Increment präsentiert werden kann.
Kurzlebige Branchesim Versionskontrollsystem können dabei helfen, sind jedoch oft ein Risiko, weil es beim Merge zu Konflikten und Fehlern kommen kann. Eine Entwicklungsstrategie mit nur einem Master Branch und die Verwendung von Feature Toggles können
dieses Problem beheben.

Sind wir jetzt Done?

Diese Frage ist spannend. Scrum Teams liefern mit jedem Sprint ein Done Increment, also müssen sie irgendwann mal „Done“ sein. Auf der anderen Seite lernen sie jeden Sprint etwas Neues dazu und verbessern sich und
ihre Arbeitsweise. Sie sind dadurch in der Lage, ihr Verständnis von Done zu verfeinern und die Maßnahmen hin zum Done Increment zu verbessern.
Diese vom Team übernommene Verantwortung führt häufig zu einer Erweiterung des Denkens. Entwicklungsteams
kümmern sich nicht mehr nur um die reine Softwareentwicklung, sondern übernehmen mehr und mehr Verantwortung für den gesamten Lebenszyklus des Systems. Diese Geisteshaltung von DevOps ist die Basis vieler sehr guter Scrum Teams.
Ein Scrum Team
hat also nicht irgendwann eine Definition of Done, mit der es ab dann auslieferbare Product Increments liefert. Vielmehr schließt sich hier der Kreis zur Legende vom Heiligen Gral: dieser kann auch nicht gefunden werden, sondern der Weg
hin zum Gral und die Vervollkommnung der Person ist das Ziel.
Jeder im Scrum Team, insbesondere im Entwicklungsteam, ist verantwortlich dafür, diesen Weg mit zu gehen und die kontinuierliche Verbesserung bei sich selbst und im Team voran zu bringen.

Autorenprofile

Peter Götz

Peter ist agiler Coach mit mehr als 15 Jahren Erfahrung in der Softwareentwicklung. Als Professional Scrum Trainer der Scrum.org und Mitglied im international Software Architecture Qualification Board (iSAQB) unterstützt er seine Kunden.
Peter hat langjährige Erfahrung als Softwareentwickler und –architekt, sowie als agiler Coach, Scrum Master und Product Owner.

Thomas Schissler

Thomas ist Leiter der Softwareentwicklung bei der artiso solutions GmbH und unterstützt als Coach und Consultant Kunden bei der Verbesserung ihrer agilen Softwareentwicklungsprozesse. Seit 2007 ist er jährlich mit dem Microsoft MVP
Award im Bereich Visual Studio ALM ausgezeichnet worden. Seit 2010 ist er Professional Scrum Trainer. Sein Steckenpferd ist aktuell das Thema DevOps.

• Die Verlässlichkeit der Velocity wird unter anderem durch die folgenden Faktoren beschränkt: Hindernisse, Impediments
• Motivation → was treibt uns an
• Wissen / Expertise / Kompetenz der Entwickler
• Entwicklungsumgebung (lokal wie auch TFS Infrastruktur etc.)
• Transparenz
• Zielvorstellungen
• Prozess
• Das Ziel (das Produkt)
• Krankheit
• Unvorhergesehene / ungeplante Ereignisse

• Aus unserer bisherigen Erfahrung ist das Schätzen in einer abstrakten Größe genauer als eine rein zeitbasierte Schätzung.
• Bei größeren Release-Planungen ist die Planung immer zyklisch anzupassen und es gilt zu beachten, dass auch die Velocity nur eine Planzahl ist.
• Scrum bietet zusätzlich den Vorteil, dass die Planungen nach jedem Sprint (alle 2-4 Wochen) angepasst werden können und somit eine gute Reaktionsfähigkeit gegeben ist, die es ermöglicht die wichtigen Dinge zuerst zu implementieren.

Ein Thema das Softwareentwicklungs-Teams oft beschäftigt: Wie können wir als Team besser zusammenarbeiten? Interessanterweise kommt diese Frage erst auf, wenn das Team bereits einen gewissen Reifegrad erreicht hat. Erst dann genügt es nicht, am selben Produkt zu arbeiten, Code zu sharen und vielleicht sogar ein Scrum-Team zu sein. Ein echtes Team zeichnet aus, dass alle Mitglieder im Team ein gemeinsames Ziel teilen. Und das darf nicht nur lauten: “Wir wollen am Ende des Sprints alle versprochenen Backlog Items abgearbeitet haben”.

Wie sieht nun ideale Zusammenarbeit in einem Team aus? Sicher ist hier ein gegenseitiges Angebot zur Unterstützung bei Problemen alleine nicht ausreichend. Ich kenne kein Team bei dem der Kollege bei einer Frage oder einem Problem weggeschickt wird. Keiner sagt “Das ist nicht mein Problem, sehe selber zu, wie du das lösen kannst”. Also ist dieser Level der Zusammenarbeit höchstens ein Einstieg, aber es muss doch besser gehen.

Es geht es darum, wie können wir alle Teammitglieder so einbinden, dass wir Kompetenzen bündeln, Probleme schnell und effizient lösen und dabei gute Qualität liefern? Wie können wir durch gemeinsame Diskussionen gute Lösungen finden und wie können wir individuelle Schwächen kompensieren und Fehler vermeiden? Eine Voraussetzung für diese Punkte ist, dass wir nicht nur am selben Produkt, sondern am selben Thema arbeiten. Damit wird das Verständnis viel besser und jeder fühlt sich direkt betroffen. 

Eine Methode diese Zusammenarbeit zu fördern, ist das sogenannte Swarming. Eine Technik mit der das Team gemeinsam zum Ziel hat, das wichtigste Backlog Item (PBI) so schnell wie möglich abzuarbeiten. Dazu stell sich jeder im Daily Scrum die Frage “Kann ich eine Aufgabe übernehmen, damit wir dieses PBI voranbringen?”. Wenn nicht, lautet die zweite Frage: “Kann ich einen Kollegen unterstützen, damit dieser mit seiner Aufgabe schneller vorankommt?”. Erst wenn beide Fragen mit “Nein” beantwortet werden, wird mit Arbeiten am zweitwichtigsten PBI begonnen.

Es genügt aber nicht, die Aufgaben im Daily gut zu verteilen, viel entscheidender ist die Frage, wie die Zusammenarbeit während des Tages läuft. Hier mache ich mit 2 Teams gerade ein Experiment, bei dem wir versuchen, die Zusammenarbeit durch Umformulierung der Frage “Kann ich dich bei deiner Aufgabe unterstützen?” zu verbessern. Zukünftig wollen wir so vorgehen, dass ein Entwickler, der eine Aufgabe abgeschlossen hat, überlegt, an welcher Stelle er gerade das größte Hindernis zur Fertigstellung des PBIs sieht. Den Kollegen der gerade an dieser Aufgabe arbeitet fragt er dann “Wo stehst du gerade?”. Den folgenden Kurzbericht kann der Entwickler der gerade seine Aufgabe abgeschlossen hat nutzen um konkrete Unterstützungspunkte zu identifizieren. Daraus entsteht dann entweder eine Arbeit im Pair oder auch eine Aufteilung der noch zu erledigenden Punkte.

Die Umformulierung des Unterstützungsangebots zu einer Statusabfrage aus meiner Sicht einen entscheidenden Vorteil: Während bei der klassischen Vorgehensweise der aktuell beschäftigte Kollege überlegen soll, wo eine Unterstützung möglicherweise Sinn macht, drehen wir das um. Er muss dann nur kurz berichten, wo er steht, das identifizieren von Unterstützungsmöglichkeiten liegt dann aber beim Kollegen der seine Aufgabe gerade abgeschlossen hat. Ich erhoffe mir aus dieser Vorgehensweise mehr Unterstützungen während des Tages, da beim bisherigen Vorgehen der Gefragte ja auch einfach sagen kann: “Danke, brauche gerade keine Unterstützung”, was für ihn meistens wohl der bequemere Weg ist. Zudem hilft dem Gefragten sicher mal kurz zu reflektieren, wo er gerade steht. Und er wird ja nicht aus seinem Kontext herausgerissen, da es ja genau um sein Thema geht.

Ich bin gespannt, wie sich das Vorgehen bei den beiden Teams auswirkt. Ich werde wieder berichten. 

Vor kurzem habe ich mit einem Team die interessante Frage aufgeworfen, ob Softwareentwickler Leidenschaft für das Produkt das sie entwickeln benötigen oder ob Leidenschaft für Technologie wichtiger ist. Und wie wirkt sich diese Frage auf die Zusammenarbeit im Team aus?

Hintergrund der Frage ist, dass viele Teams mit denen ich zusammenarbeite, zwar Scrum nutzen, aber im Grunde genommen im Sprint einzelne Backlog Items abarbeiten und am Ende des Sprints ein Inkrement an den Product Owner liefern. Bewusst oder unbewusst haben die Entwickler aber sehr wenig Kontakt mit Personen außerhalb des Scrum Teams. Und daraus ergibt sich die Frage, was ist das Ziel des Teams?

Nach Definition des Scrum Guides ist das Ziel eines Development Teams, ein „Done“ Inkrement des Produkts am Ende jedes Sprints abzuliefern. Das Development Team ist damit verantwortlich für die Qualität des Produktes. Hier ist nun genau die Frage, welche Qualität hier genau gemeint ist. Natürlich ist das Development-Team verantwortlich für die „innere Qualität“ des Produktes, also für die Wartbarkeit und Erweiterbarkeit des Codes und dafür, möglichst wenig technische Schuld aufzuhäufen. Auch für den Teilaspekt Fehlerfreiheit der „äußeren Qualität“ ist klar, dass das Development Team dafür die Verantwortung trägt. Wie sieht es aber mit anderen Aspekten wie Usability, Sicherheit oder allgemein mit dem Thema „Zufriedenheit des Anwenders“ aus? Kann ein Development Team sich ausschließlich auf die technischen Aspekte fokussieren und das Generieren von Mehrwert dem Product Owner überlassen? Schließlich ist das genau die Aufgabe dieser Rolle. Der Product Owner wird oft ja auch als „Value Maximizer“ bezeichnet.

Nach der Diskussion mit dem Team bin ich überzeugt, dass das Development Team eine Leidenschaft für das Produkt haben muss. Die Entwickler müssen zunächst das Interesse haben, ein gutes Produkt zu entwickeln, das die Anwender begeistert. Die Erstellung von gutem Code allein darf hier nicht genügen. Hier kommt mir ein Vergleich mit einer Fußballmannschaft in den Sinn. Wenn alle Spieler nur das Ziel haben technisch perfekt zu spielen und persönlich möglichst keine Fehler zu machen, wird das möglicherweise nicht ausreichen um das Spiel zu gewinnen. Wir brauchen also ein übergeordnetes Ziel. Im Fußball ist es, das Spiel zu gewinnen. In der Software ist es, mit unserer Software Anwender zu begeistern oder wenigstens zufrieden zu stellen.

Damit übernehmen die Entwickler auch eine gewisse Kontrolle, dass der Product Owner einen guten Job macht. Er trifft zwar letztendlich die Entscheidungen, aber wenn das Development Team das Gefühl hat, dass die falschen Schwerpunkte gesetzt werden und dass Potenziale nicht ausgeschöpft werden, dann muss es darüber zumindest eine Diskussion geben. Diese wird aber nur dann stattfinden, wenn sich die Entwickler nicht als reine Umsetzer verstehen, die einen Arbeitsauftrag bekommen und diesen möglichst gut umsetzen. Sie müssen sich mit Leidenschaft für den Erfolg ihres Produktes einsetzen – also nicht das Produkt des Product Owners. Diese Leidenschaft wird aber nur entstehen, wenn die Entwickler verstehen wie ihre Software genutzt wird, wenn sie direkt Feedback von Anwendern bekommen und selbst verstehen wie auf bestimmte Funktionen reagiert wird. Dieses Feedback kann im Sprint Review entstehen oder durch Telemetriedaten die die Nutzung durch die Anwender visualisieren oder durch soziale Medien oder, oder. Dem Product Owner erwächst hier eine zusätzliche Aufgabe. Er muss die Leidenschaft für das Produkt bei den Entwicklern wecken, indem er die Ziele und Vision erklärt, indem er Success-Stories mit den Entwicklern teilt und auch indem er Fehlschläge oder Misserfolge direkt kommuniziert.

Darüber hinaus ist auch wichtig, dass das Development Team an dieser Stelle einheitlich agiert. Sollten nur einzelne Teammitglieder diese Leidenschaft für das Produkt besitzen, so sind soziale Spannungen bereits vorprogrammiert. Wenn ich das tollste Produkt aller Zeiten entwickeln möchte und ich gleichzeitig das Gefühl habe, dass der Kollege ein anderes Ziel hat und seine persönliche Agenda verfolgt, wird das zu Spannungen führen. Ähnlich wie bei dem zuvor genannten Beispiel aus dem Fußball gehört natürlich die Fähigkeit und die Kompetenz auf technischer Ebene dazu, denn nur so werden wir in der Lage sein das Spiel zu gewinnen bzw. ein gutes Produkt zu bauen. Aber es ist eben nicht unser primäres Ziel. Um ein gutes Produkt zu erstellen gehört noch mehr dazu als Technologie zu beherrschen.

Aber letztendlich macht eines für mich eine Gruppe von Personen erst zu einem Team – wenn sie ein gemeinsames Ziel haben, das sie verfolgen. Für das sich jeder engagiert und seinen Beitrag leistet. Wo wir möglicherweise unterschiedlicher Meinung sind, wie wir das gemeinsame Ziel am besten erreichen. Wo wir aber diese Meinungsvielfalt nutzen, um aus verschiedenen Optionen die besten auszuwählen.

Vielleicht lohnt es sich für sie auch einmal die Frage zu stellen, ob ihre Softwareentwickler Leidenschaft für ihr Produkt haben und wie sie diese evtl. wecken oder steigern können. Denn letztendlich ist diese Leidenschaft nichts Anderes als Motivation und wer möchte denn nicht motivierte Mitarbeiter? Leidenschaft und Motivation werden aber nur entstehen, wenn den Teams auch Gestaltungsmöglichkeiten eingeräumt werden und nicht alles von außerhalb vorgegeben ist.

Die Wichtigkeit des Product Owners

Zweifellos ist der Product Owner die Einzelperson innerhalb eines Scrum Teams die den größten Einfluss auf Erfolg oder Misserfolg eines Software-Projektes hat, schließlich bestimmt er oder sie die strategische Ausrichtung des Projektes und damit, wo die Kapazität des Teams investiert werden soll. Er muss eine klare Produktvision entwickeln, die definiert, was macht unser Produkt so besonders, wie können wir uns vom Wettbewerb abheben, wo können wir den maximalen Mehrwert für unsere Anwender generieren und wie bringt dieses Produkt unser Unternehmen weiter. Der Product Owner versucht also den Nutzen aus der Investition (die Entwicklungsleistung des Teams) zu maximieren. Manche sagen auch, dass der Product Owner ein CEO auf Projektebene darstellt. Und in der Tat gibt es hier viele Überschneidungen in den Aufgaben und Verantwortlichkeiten. Die Aufgaben des Product Owners beschränken sich eben nicht darauf, das Backlog zu verwalten, sondern sie gehen weit darüber hinaus.

Kontinuierlicher Austausch mit den Stakeholdern

Ein guter Product Owner kennt seine Stakeholder und ist mit diesen in kontinuierlichem Austausch. Zu diesen Stakeholdern gehören nicht nur die Anwender, sondern auch das Produktmanagement, Marketing und Vertrieb, Support, Management, sein und andere Teams und alle anderen die ein Interesse an diesem Projekt haben. Durch den regelmäßigen Austausch helfen die Stakeholder dem Product Owner, zu erkennen, wo es Potenzial für eine hohe Wertschöpfung gibt. Diese Einschätzungen der Stakeholder können oftmals konträr und widersprüchlich sein. Die Aufgabe des Product Owners ist, diese verschiedenen Meinungen und Strömungen zu einer einheitlichen Produktvision zu vereinigen, bei der ein möglichst guter Konsens erzielt wird. Diese Produktvision und der aktuelle Status des Projektes wird der Product Owner kontinuierlich mit den Stakeholdern abgleichen, um neue Ideen, Bedenken, Marktentwicklungen oder Erkenntnisse frühzeitig mit einfließen zu lassen. Dabei ist der Product Owner gut beraten, gut auf das Feedback seiner Stakeholder zu hören, was aber keinesfalls bedeutet, dass er ein reiner Erfüllungsgehilfe ist, der lediglich die Vorgaben der Stakeholder umsetzt.

Innovationen entwickeln

Vielmehr muss ein guter Product Owner auch visionär sein und auch neue Impulse setzen, statt nur zu versuchen, die aktuellen Bedürfnisse seiner Stakeholder zu befriedigen. Er erkennt zukünftige Potenziale und Chancen und bereitet sein Team und sein Produkt darauf vor. Allerdings geht er hier nach dem Lean Startup Gedanken vor und versucht mit dem Konzept Build-Measure-Learn seine Hypothesen durch möglichst kleine Experimente zu untermauern statt monatelang in eine Neuerung zu investieren, die sich dann doch als wenig lukrativ herausstellt. Wie ein solches Minimum Viable Product, also das kleinste Experiment aussieht, wie dieses bewertet werden kann und welche Lehren aus den Ergebnissen der Experimente gezogen werden kann, all das gehört zu den wichtigsten Aufgaben des Product Owners. Wie gut er oder sie dabei ist, werden letztendlich die Stakeholder bewerten. Ein weiterer Grund, für eine enge Abstimmung und eine hohe Transparenz über das woran das Team gerade arbeitet, was die Ziele sind, die damit erreicht werden sollen und wie die aktuelle Produktvision aussieht.

Input einholen

All diese Dinge kann eine Person schwerlich alleine stemmen, deshalb wird sich der Product Owner, wo immer möglich, Unterstützung holen. Im Scrum Guide ist zwar klar festgelegt, dass der Product Owner eine Einzelperson sein muss, kein Komitee. Aber natürlich wird der Product Owner sich Input von außen holen. Sein Development-Team ist einer der wichtigsten Input-Geber. Schließlich ist das Development-Team nicht ausschließlich für die Umsetzung der Product Backlog Items verantwortlich, sondern es fühlt sich genauso dem gemeinsamen Ziel verpflichtet, ein erfolgreiches, hilfreiches und wertschöpfendes Produkt zu entwickeln. Das Development-Team kennt die Produktvision besser als jeder andere Stakeholder und wird diese gemeinsam mit dem Product Owner ständig hinterfragen, ergänzen, konkretisieren und weiterentwickeln. Vor allem aus der technischen Perspektive kann das Development-Team dazu beitragen, weitere Innovationen zu entwickeln. Darüber hinaus wird der Product Owner sich aber auch Input von außerhalb seiner Organisation einholen. Bei Vorträgen und auf Konferenzen, in Artikeln, im Internet, durch Berater – die Quellen sind vielfältig und unerschöpflich.

„Was“, nicht „Wie“

Bei alldem bleibt aber der Fokus des Product Onwers auf der inhaltlichen Ebene. Er bewertet alles aus der Anwendersicht und konzentriert sich auf das, was erreicht werden soll. Das „Wie“ überlässt er dem Development-Team. Er vertraut dem Development-Team, dass es die besten technischen Lösungen findet, um seine Anforderungen zu realisieren. Natürlich wird er das Development-Team fordern und gemeinsam mit den Stakeholdern die technischen Lösungen bewerten, aber immer in ihrer Wirkung und nicht in ihrer Umsetzung. In dieser Trennung von Anforderung und Lösung auf verschiedene Rollen liegt ein wichtiger Vorteil von Scrum.

Warum gibt es dann nicht nur gute Product Owner?

Bei dieser Beschreibung der Aufgaben und Funktionen eines Product Owners wird klar, welches Potenzial ein Team mit einem idealen Product Onwer entwickeln kann. Aber auch, welche Herausforderungen diese Rolle mit sich bringt. Dennoch finde ich es bedauerlich, wie leichtfertig manche Organisationen die Möglichkeiten vergeben. In der Realität beobachte ich häufig, dass der Product Owner diese Rolle mehr als Nebenjob ausführt und eine Vielzahl anderer Aufgaben wahrnimmt. Dadurch bleibt zu wenig Zeit für den Product Owner und damit bleibt diese Rolle nur teilweise ausgefüllt. Eine weitere Beobachtung ist, dass der Product Owner nicht in der Lage ist, eine Produktvision zu entwickeln. Es fehlt an der notwendigen Unterstützung, die dafür notwendigen Fähigkeiten zu erlernen, sei es durch Trainings, Coaching oder einfach durch Teilhabe an unternehmensinternem Wissen. Ebenfalls verbreitet ist der Umstand dass sowohl der Product Owner selbst als auch sein Umfeld die Rolle wesentlich eingeschränkter interpretieren. Da wird der Product Owner oftmals auf die Funktion eines Projektleiters beschränkt der für die Einhaltung des Budgets und der Liefertermine verantwortlich ist. Berücksichtigt man, was ein guter Product Owner für sein Unternehmen bewirken kann, dann sollte für diese Aufgaben immer ausreichend Zeit und Unterstützung vorhanden sein.

Um Teams dabei zu unterstützen, die Sprint-Retrospektiven interessant zu halten und aus unterschiedlichen Perspektiven immer wieder neue Verbesserungsmöglichkeiten zu finden, experimentiere ich momentan mit alternativen Formaten zum klassischen “Was war gut / schlecht / Was wollen wir besser machen?”. Ich möchte meine Erfahrungen mit diesen Formaten in einer losen Folge von Blog Posts teilen wobei sicher die Erfahrungen nicht ohne weiteres auf andere Teams übertragbar sind.

Das erste Format in dieser Reihe nenne ich das “Was wäre wenn Format”:

Als Scrum Master habe ich eine reihe von hypothetischen Fragen vorbereitet, z.B.:

Was wäre wenn…?

• unser Sprint 4 Wochen wäre
• unser Sprint 1 Woche wäre
• wir keinen Scrum Master hätten
• wir keinen / einen anderen Product Owner hätten
• jemand aus einem anderen Team unseren Code reviewen würde
• wir auf Pair Programming verzichten würden
• wir einem Kunden unser Produkt „verkaufen“ müssten
• wir eine beliebige technische Rahmenbedingung ändern könnten
• wir eine beliebige organisatorische Rahmenbedingung ändern könnten
• wir das Sprint Planning II stark kürzen würden (z.B. 1/2 Std.)
• wir 3 Monate für Refactoring Zeit bekämen
• wir keine Stunden für unsere Tasks schätzen würde
• wir unsere PBIs nicht mehr schätzen würden
• der Product Owner das aktuelle Inkrement ausliefern würde
• das Team deutlich größer / kleiner wäre
• etc.

Ich habe diese Fragen auf einem Zettel ausgedruckt und dem Team erklärt, dass nun jeder Reihum eine dieser Fragen oder auch eine beliebig andere an ein beliebiges Teammitglied richten soll. Der Gefragte beantwortet die Frage aus seiner Sicht und dann können die anderen Teammitglieder wiedersprechen oder beipflichten, neue Aspekte einbringen oder sich sonst an der Diskussion beteiligen. Währen der Diskussion habe ich für alle sichtbar einige der Punkte notiert. Wenn die Diskussion abgeschlossen war, stellt der Gefragte die nächste Frage.

In der abschließenden Feedback-Runde wurde das Format vom Team als sehr positiv bewertet, weil:

• Die Retro sich nicht nur auf den letzten Sprint bezogen hat, sondern auch grundsätzlichere Themen zur Sprache kamen
• Die Bedeutung von Dinge die inzwischen als normal betrachtet werden zur Sprache kamen und deren Wichtigkeit nochmals betont wurde was die Motivation erneuerte, auf diese Dinge zu achten
• Sich alle Teammitglieder aktiv an der Retro beteiligt haben
• Auch Dinge die als unveränderbar erscheinen nochmals angesprochen wurden

Insgesamt war die Erfahrung mit dem Format sehr positiv, so dass ich dieses Format in Zukunft immer wieder anwenden werde, auch mit andern Teams.

1. Entwicklerteams sind in dieser Phase bemüht, eine möglichst gute Grundlage für Entscheidungen zu treffen. Dafür wird auch einiges an Zeit investiert. Aber die Erfahrung zeigt, dass diese Entscheidungen nicht immer lange Bestand haben. Eine neue Anforderung, eine Änderung der strategischen Ausrichtung und schon ist vieles in Frage gestellt. Was wir hier brauchen ist einen hohen Grad der Veränderbarkeit der Software. Und der Versuch der umfangreichen Evaluierung und Planung im Vorfeld, das sogenannte Big Design Upfront reduziert die Veränderbarkeit unserer Software. Zum Einen, weil an Entscheidungen in deren Vorbereitung viel Zeit investiert wurde, oftmals viel zu lange festgehalten wird und zum anderen weil man die Evaluierung ja gerade mit dem Ziel durchführt, Veränderungen zu vermeiden. Ich plädiere statt dessen dafür, Änderungen in der Software bereits zu einem frühen Zeitpunkt des Projektes herbeizuführen, auch gerne Grundsätzliche Änderungen. Nur so werden wir feststellen, ob unsere Architekturkonzepte die Wandelbarkeit erhöhen, nur so werden wir lernen können, was wir vielleicht noch besser machen können. Möglicherweise stellt sich nach wenigen Wochen der Entwicklung heraus, dass wir doch besser ein Web-Frontend genutzt hätten statt auf WPF zu setzen, die von uns gewählte UI Bibliothek stellt sich als kompliziert heraus oder dem Kunden fällt auf einmal ein, dass die Anwendung jetzt doch auf Mobilgeräten laufen soll. Zu Beginn des Projektes können wir solche Änderungen noch verschmerzen, je weiter die Implementierung vorangeschritten ist, desto mehr tut uns das weh. Und wir können feststellen, wie gut die Entkopplung in unserem Code funktioniert hat? Wie gut können wir bestimmte Teile der Anwendung umbauen und andere Teile bleiben von dieser Anpassung unberührt? Das geht nur, wenn wir tatsächlich diese Änderungen haben und ich würde sogar soweit gehen, diese explizit zu einem frühen Stadium unseres Projektes einzufordern. Wenn die Änderung einer Entscheidung weh tut, werden wir lernen, es das nächste Mal besser zu machen und Strategien für diese Szenarien entwickeln.
2. Das zweite Problem ist hier, dass das Team sich erst mal nur mit technologischen Aspekten beschäftigt. In dieser Phase fehlt echtes Feedback von Anwendern und Kunden. Wir haben nichts, das wir wirklich zeigen können. Das ist auch der Grund, weshalb Scrum sagt “Es gibt keinen Sprint 0” und “Jeder Sprint muss Kundennutzen erzeugen”. Das bedeutet, wir beginnen damit erste Anwenderfunktionalität zu schaffen und diesen innerhalb eines Sprints zu implementieren. Da bleibt nicht viel Zeit für Evaluierungen und wir müssen evtl. im nächsten Sprint einiges umbauen, aber unser Kunde sieht von Beginn an, wie sich das Projekt entwickelt. Das schafft Vertrauen, Vertrauen das für eine gute Zusammenarbeit wichtig ist.

• Warum haben wir diesen Fehler bei unseren Tests nicht gefunden und wie müssen wir zukünftig unsere Tests verbessern, um ähnliche Fehler finden zu können?
• Warum wurde der Fehler überhaupt eingebaut? Haben wir Erfahrungs- oder Wissensdefizite im Team oder haben wir hier eine neue Problemkategorie entdeckt, die uns so nicht bewusst war?
• Sollte ich die Kollegen auf den Fehler und seine Ursachen aufmerksam machen, damit sie in ähnlichen Situationen ähnliche Fehler bereits beim Implementieren vermeiden können?
• Ist der Fehler durch eine Erweiterung oder Anpassung entstanden bzw. ist er ein Seiteneffekt durch eine andere Änderung? Wie können wir unsere Architektur anpassen, um solche Effekte für die Zukunft zu reduzieren?
• Was können wir tun um den Fehler bereits frühzeitig zu entdecken. Fehlt den Entwicklern Qualitätsbewusstsein oder haben sie nicht alle relevanten Einsatzszenarien verstanden?