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.

Führt man bei einem Team das Schätzen in Story Points ein, kommen oft Diskussionen in gang wie: Was ist Komplexität? Was bringt uns das Schätzen? Warum schätzen wir in Story Points und nicht gleich in Zeit? Dieser Artikel bietet einen Überblick warum wir in Story Points schätzen und was die Vorteile dessen sind. Was sind Story Points? Story Points sind eine abstrakte Einheit, welche die Größe einer User Story beschreiben. Was ist nun diese Größe von Story Points? Es geht bei der Größe nicht um die benötigte Zeitdauer zur Umsetzung der Story, sondern um die Eigenschaft der „Struktur“ der User Story – also ihrer Komplexität. Jedes Team kann Komplexität anders definieren. Komplexität kann zum Beispiel bedeuten ob und wie oft welche Schichten unseres Architekturmodells durchstoßen werden. Das heißt, dass die wachsende Erfahrung eines Teams und die daraus resultierende schnellere Abarbeitung einer Story keinen Einfluss auf deren Größe hat, da die Eigenschaften der Story sich dadurch nicht verändern. Dadurch steigern erfahrenere Teams mit der Zeit ihre Velocity. Was bedeutet der Begriff Velocity? Unter dem Begriff Velocity versteht man innerhalb von Scrum die Geschwindigkeit, die ein Scrum Team im Verlauf eines Sprints erreicht. Diese Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration. Was bedeutet der Begriff Geschwindigkeit? Im englischen wird, anders als im deutschen, der Begriff Geschwindigkeit in speed und velocity unterschieden. Machen wir nun eine kleine Exkursion in die Physik, ist der Unterschied einfach zu erklären: speed ist der Betrag der Geschwindigkeit, also eine skalare Größe. velocity gibt zusätzlich die Richtung an, ist also eine vektorielle Größe. Das „Richtige“ entwickeln Was bedeutet das für die Software-Entwicklung und die Schätzung in Story Points? Ein Team, das nur aus schnellen Entwicklern besteht resultiert vielleicht in einer hohen Geschwindigkeit – speed – aber nicht unbedingt einer hohen velocity. Betrachten wir nun zusätzlich die Richtung, haben wir nur dann eine hohe Velocity, wenn wir auch das Richtige entwickeln. Damit wir das Richtige entwickeln, müssen wir bei der Planung Diskussionen generieren in denen das Verständnis und die inhaltliche Richtigkeit der User Stories hinterfragt werden. Dies gelingt, indem wir für die Schätzung der User Story eine abstrakte Größe verwenden. Denn kommen beim Schätzen stark abweichende Werte heraus, existiert im Team vielleicht noch kein einheitliches Verständnis über das betreffende Feature in welche Richtung die Umsetzung erfolgen sollte. Warum tun wir uns so schwer diese Diskussionen zu generieren, wenn wir in Zeiten schätzen? Hierzu ein kleines Beispiel: Du, als guter Jogger, benötigst du für eine bestimmte Strecke 30 Minuten. Als schlechterer Läufer benötige für die gleich Strecke 60 Minuten. Wir diskutieren am Ende über 30 – 60 – 30. Das bringt uns nicht weiter. Ein Kompromiss wären 45 Minuten. Wir hätten am Ende aber gerne eine Schätzung die uns beiden dient. Wir könnten auch weiter argumentieren, anstatt einen Kompromiss zu schließen. Das Problem ist jedoch, dass wir beide recht haben. Du benötigst 30 Minuten ich aber 60 Minuten. Wenn wir versuchen mit Zeiten zu schätzen werden wir keine Lösung finden, da wir mit unterschiedlichen Geschwindigkeiten laufen (arbeiten). Wenn wir aber eine abstraktere Messmethode verwenden, werden wir uns schnell einig, dass der Weg 5 km lang ist. Wir sind uns nur nicht einig, wie lange wir dafür benötigen. Wie die Läufer können sich Entwickler über 5 Story Points einig werden. Die schnellen Entwickler denken „das schaffe ich an einem Tag“. Die langsameren denken „dafür benötige ich zwei Tage“. Aber sie sind sich einig, dass der Aufwand für die User Story 5 Story Points beträgt. Des Weiteren können wir einfach feststellen, dass die neue User Story doppelt so lange dauert wie eine bereits abgearbeitete User Story mit einem Story Point. Das heißt wir werden die neue Story mit zwei Punkten schätzen. Dennoch denkt der eine es sind 5 Stunden Arbeit wogegen der andere von 10 Stunden Arbeit ausgeht. Story Points sind sicher eine Zeiteinheit (Aufwand), aber die Anzahl der Zeit pro Story Point unterscheidet sich je nach Teammitglied. Zudem ist das Schätzen nachweislich genauer, wenn wir in Relation zueinander schätzen (größer / kleiner / gleich). Am einfachsten funktioniert das Schätzen der Größe, wenn man die PBIs in Größenkategorien einteilt. Das können genauso T-Shirt Größen wie S, M und L sein. Es geht also nicht darum, einen genauen Wert zu erhalten, sondern nur eine Kategorie. Die Nutzung der Velocity zur Prognose kompensiert die Ungenauigkeiten relativ gut. Alles andere wäre Scheingenauigkeit. Würden wir nun Story Points mit Zeit gleichsetzen, nähmen wir dem Team die Möglichkeit auf diese Weise zu schätzen. Würde also jemand das Team beispielsweise instruieren, dass 1 Story Point 8 Stunden entspricht, ginge der Vorteil der abstrakten Schätzung verloren. Bis jetzt wurde nur erläutert welche Vorteile es für das Entwicklungsteam hat mit einer abstrakten Größe zu schätzen. Aber auch für den Product Owner ist die Größe der Velocity relevant. Beispielsweite um Release-Planungen erstellen zu können. Hier könnte beispielsweise die Frage auftauchen ob eine identische Anzahl an Story Points stets die gleichen Kosten (Zeit) verursacht. Hierzu ein kleines Rechenbeispiel: Würde ein Team bei einem 20 Arbeitstage andauernden Sprint (4 Wochen) mit einer durchschnittlichen Velocity von 50 Points arbeiten, bekäme man (50 Points / 20 Tag = 5/2 =) 2,5 Story Points pro Tag. Daraus ließe sich umgekehrt errechnen, dass das Team für ein Projekt mit einem Umfang von 450 Points etwa (450/2,5 =) 180 Arbeitstage brauchen würde, also etwa 9 Monate. Rein rechnerisch ist das nachvollziehbar. Aber wie verlässlich ist diese Prognose in der Praxis? Betrachten wir das oben Gesagte, liegt die Antwort auf der Hand: Mehr oder weniger verlässlich. Denn trotz Scrum ist auch die Velocity nur eine Planzahl, die sich aus einem Mittelwert (Median) der bisherigen Sprints errechnet. Wir behaupten jedoch auch, dass mit ansteigender Anzahl an Sprints, die für die Berechnung der durchschnittlichen Velocity verwendet werden, die Genauigkeit der Zeit (Kosten) die pro Story Point angesetzt werden kann zunimmt. Möchte man eine größere Release-Planung, zum Beispiel für die nächsten 9 Monate, ist dies das bestmögliche Vorgehen, das im Moment bekannt ist. Es gilt zu berücksichtigen, dass die Releaseplanung immer zyklisch anzupassen ist. Scrum bietet durch seine „kurzen“ Iterationen eine gute Möglichkeit dazu.

• 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

Zusammenfassung

• 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.

Eigentlich sind langlaufende Projekte etwas tolles. Als Entwickler gewinnt man Sicherheit, man versteht den Kunden und seine Anwendungsdomäne immer besser, kann sich dadurch auf technische Themen fokussieren. Die Projektrisiken sind besser einschätzbar, der Kunde muss immer weniger erklären weil die Entwickler sein Umfeld immer besser verstehen und nicht zuletzt für Dienstleister bietet ein langfristiges Projekt auch wirtschaftliche Sicherheit und planbare Auslastung für einen längeren Zeitraum. Bei der artiso haben wir einige Projekte die ohne einem definierten Ende laufen, d.h. so lange der Kunde mit unseren Leistungen zufrieden ist, können wir, zumindest auf absehbare Zeit, in dem Projekt aktiv weiterarbeiten. Wir nutzen in diesen Projekten Scrum und ich bin absolut überzeugt davon, dass die Entwicklung in kurzen Sprints mit einem klar definierten Sprint-Ziel viele Vorteile bietet gegenüber einem Projekt in dem der Planungshorizont Monate oder gar Jahre umfasst. Aber was ich in letzte Zeit beobachte, die Teammitglieder in den langlaufenden Projekten sind weniger zufrieden als die, die in Projekten mit kürzerer Laufzeit arbeiten. Und auch zwischen den langlaufenden Projekten gibt es deutliche Unterschiede. Einzelne Mitarbeiter berichten, dass sie ihr aktuelles Projekt langweilt und dass sie sich unterfordert fühlen. Der erste Erklärungsversuch war, dass in diesen Projekten ältere Technologien (z.B. .Net 3.5) eingesetzt werden. Natürlich kann man hier jetzt sagen, dass das Jammern auf hohem Niveau ist, aber die Mitarbeiterzufriedenheit ist bei uns im Unternehmen ein hohes Gut und so haben wir diesen Punkt sehr ernst genommen und begonnen den entsprechenden Mitarbeitern in anderen Teams neue Herausforderungen zu geben. Aber nach einiger Zeit konnte keine Korrelation zwischen den eingesetzten Technologien und der Unzufriedenheit der Mitarbeiter festgestellt werden. In einem Projekt wurde z.B. die neuesten Technologien genutzt und dennoch hat die Begeisterung und Motivation bei einem Mitarbeiter in kurzer Zeit in Unzufriedenheit umgeschlagen. Es musste also eine andere Ursache dafür geben. Ein paar Gespräche und Überlegungen später, habe ich nun eine neue Theorie, was zu dieser Unzufriedenheit führt: fehlende Zielvorgaben! Das hört sich vielleicht zunächst paradox an, in einem agilen Umfeld zu kritisieren, dass uns die konkreten Zielvorgaben fehlen. Aber die Projekte, in denen wir eine hohe Motivation der Mitarbeiter haben, sind durchweg dadurch gekennzeichnet, dass es in den Projekten Konkrete Ziele gibt. Dies können Messetermine sein, zu denen die neue Software vorgestellt werden soll und wir deshalb möglichst viele geniale Features haben um die Kunden von der neuen Software zu begeistern. Oder ein Termin zu dem der erste Kunde die neue Software einsetzen soll und wir dann fieberhaft daran arbeiten, dass alles was dafür notwendig ist, in der Software drin ist. Oder wir haben ein sehr begrenztes Budget und müssen in diesem Rahmen für den Kunden den maximal möglichen Nutzen realisieren. Was diese Ziele alle gemeinsam haben: Sie stellen eine Herausforderung für das Entwicklungsteam dar. Im Gegensatz dazu haben wir teilweise Projekte, wo zu Beginn des Sprint geplant wird, was am Ende fertig sein sollte und das wird dann im Sprint Review dem Product Owner vorgestellt. Wenn das Team das Ziel erreicht hat, gibt es ein kurzes Lob, wenn nicht, zeigt sich das Team zerknirscht, aber die fehlenden Features werden in den nächsten Sprint geschoben und dort dann einfach fertiggestellt. So haben wir zum Teil schon über 6 Monate und länger ausschließlich für den Product Owner entwickelt und der hat als Teil des Scrum Teams natürlich auch ein großes Verständnis für alle Probleme die dazu geführt haben, dass das Sprint-Ziel nicht erreicht wurde. Mein Fazit ist, dass Software-Entwickler Herausforderungen mögen, vor allem, wenn sie sich als Teil einer Gemeinschaft fühlen, die aus dieser Herausforderung das Beste herausholt. Also einfach unrealistisch kurze Timelines setzen ist nicht die Art von Herausforderung von der ich spreche, sondern zu einem bestimmten Termin eine überzeugende neue Version bereitzustellen, die coolste Benutzeroberfläche aller Zeiten zu bauen oder die Performance der Anwendung signifikant zu verbessern. Wichtig ist, dass das Team kontinuierlich überprüfen kann, wie der Fortschritt auf dem Weg zu diesem Ziel ist, also z.B. wie viele Elemente haben wir noch auf dem Backlog die wir unbedingt bis zur Messe umsetzen müssen, was ist die Zielvorgabe für die Performance, wie reagieren die Anwender auf unsere neue Oberfläche. Und es ist wichtig, dass gemeinsam mit dem Product Owner für die Zielerreichung “gestritten” wird, also z.B. ist dieses Feature wirklich unbedingt notwendig oder können wir nicht etwas anderes, wichtigeres implementieren, brauchen wir dieses Feature in dieser Form oder finden wir eine einfachere Lösung die zunächst auch genügt? Fazit: Diese Herausforderungen und die gemeinsame Anstrengung im Team zu Zielerreichung, das ist ein wichtiger Teil der Motivation von Software-Entwicklern. Wir sind nun daran, mit unseren Kunden abzustimmen, wie wir in den Projekten über Ziele die Herausforderungen vergrößern können. Das passt auch zum Feedback eines meiner Teams die sich bei mir als Scrum Master beklagt haben, dass sie in dieser Iteration zu wenig Arbeit haben und der Product Owner keine PBIs vorbereitet hat um sie mit weiterer Arbeit zu versorgen. Damit halte ich die These widerlegt, dass der Mensch von Haus aus faul ist und nur dann Leistung bringt, wenn er entsprechende Anreize (Geld, Druck) empfängt. Somit sehe ich durch unsere aktuelle Situation die Beschreibung im Buch Drive von Daniel Pink absolut bestätigt.

Eigentlich ist das doch der Traum eines jeden Entwicklers – wir starten ein komplett neues Projekt. Grüne Wiese, keinen Legacy Code – dieses Mal machen wir alles perfekt! Aber die erste Begeisterung weicht schnell, wenn es dann darum geht, festzulegen wo man nun konkret beginnen soll. Vor uns liegt ein großer Berg mit Anforderungen, einige sind schon sehr konkret, einige erst ganz grob definiert – schließlich sind wir ja agil. Wir haben viele neue Ideen, sowohl im Bereich der Technologien die wir einsetzen wollen als auch bei Architektur-Konzepten oder Bedienkonzepten. Die Gefahr besteht, dass das Entwicklungsteam sich nun zunächst mal mit Technologie-Evaluierungen und Architekturentscheidungen aufhält. Noch ist der Termin für das Ende des Projektes ja in weiter Ferne und wenn nicht jetzt, wann können wir uns sonst die Zeit für solche Dinge nehmen. Mit diesem Ansatz sehe ich 2 Probleme:

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.

Wie entscheiden wir also nun, wo wir am Besten beginnen? Auf jeden Fall muss es Kundennutzen generieren. Und dann sollten wir uns durch das Risiko leiten lassen. Besonders zu Beginn des Projektes ist noch vieles unklar, Anforderungen sind erst im Entstehen und das Team lernt viel über die Business-Domäne des Kunden. Man ist dadurch oft verleitet an der Stelle zu beginnen, wo die meiste Klarheit herrscht und das Team die größte Sicherheit hat. Die Stelle bei der es das geringste Risiko gibt, dass wir falsche Entscheidungen treffen und dann alles wieder umbauen müssen. In der Zwischenzeit erlangen wir mehr Gewissheit über andere Bereiche und können dann diese umbauen. Aber stopp mal, funktioniert das wirklich? Wenn wir noch eine ganze Reihe von blinden Flecken haben, wie wollen wir dann sicher sein, dass das was wir da gerade bauen, tatsächlich zu dem passt was wir dann später brauchen? Wir müssen versuchen, diese blinden Flecken zu beseitigen und zuerst über diese Bereiche mehr lernen. Aber das wollen wir nicht in klassischer Wasserfall-Manier durch Planung machen, nein, hier gibt es einen besseren Weg. Wir beginnen in diesen Bereichen mit der Implementierung. So lernen wir viel schneller, sowohl auf der technischen Ebene als auch im Verständnis was unser Kunde wirklich braucht (und das können die meisten Kunden nicht in einem Planungs-Workshop sagen). Wir implementieren hier so viel, bis wir ausreichend viel gelernt haben und wenden uns dann dem nächsten unsicheren Bereich zu um dort zu lernen. Nicht die Strategie erst mal einen Bereich fertig machen, dann beginnen wir den nächsten ist hier gefragt, sondern die Maximierung unserer Lerngeschwindigkeit ist in dieser frühen Projektphase das wichtigste. Es gibt zwei Risiken die zu Unsicherheit in bestimmten Bereichen unserer Software führen. Zunächst einmal das technische Risiko. Das können Software-Entwickler üblicherweise recht gut einschätzen. Wir wissen aus anderen Projekten, wo wir vielleicht Probleme hatten und noch keine ideale Lösung parat haben. Wir wissen Bereiche die neue Herausforderungen an uns stellen, beispielsweise Technologien, mit denen wir noch nie gearbeitet haben. Und wir können mit etwas Nachdenken auch recht gut identifizieren, welche Bereiche der Applikation ein besonderes Performance-Risiko bergen. Darüber hinaus gibt es aber ein weiteres Risiko, für das sich Software-Entwickler meist gar nicht verantwortlich fühlen. Nämlich das Risiko ob wir die Erwartungen unseres Kunden erfüllen. Dazu ist es wichtig diese Erwartungen zunächst einmal zu kennen. Was ist die Motivation die den Kunden veranlasst, die Software entwickeln zu lassen? Gibt es bereits heute eine Software, die in diesem Bereich eingesetzt wird und welche Verbesserungen erwartet sich der Kunde durch die Neuimplementierung? Welche Kriterien bestimmen, ob der Kunde das Projekt als erfolgreich betrachtet oder nicht. Hier liegt das zweite Risiko das wir versuchen müssen frühzeitig im Projekt zu minimieren. Der Kunde wird uns glauben, dass wir seine Stammdatenverwaltung gut implementieren können. Aber funktioniert seine innovative Idee zur Verwaltung von Kundenbeziehungen auf der sein Business-Modell basiert? Und die Verantwortung dafür, zu erkennen, was dem Kunden wichtig ist und welche Risiken sich daraus ergeben liegt nicht ausschließlich beim Product Owner. Das gesamte Team muss hier mitwirken. Ich betreue gerade ein Team, das genau in der Situation steckt, ein neues umfangreiches Softwareprojekt zu starten. Der erste Impuls der Entwickler war, eine Lösung zum dynamischen Aufbau der UI umzusetzen. Aber das wurde bereits in einem anderen Projekt umgesetzt, sicher nicht perfekt und es gab viele Ideen, das besser zu machen, aber keiner im Team hatte Zweifel, dass das scheitern würde. Die Hauptmotivation des Kunden war, dass er eine 15 Jahre alte Bestandsanwendung ablösen möchte. Der Hauptkritikpunkt bezog sich dabei auf die Oberfläche. Weder sah diese zeitgemäß aus noch war das Bedienkonzept entsprechend intuitiv und z.B. für Touchbedienung ausgelegt. Statt also mit den dynamischen Oberflächen zu beginnen wurde zunächst die Benutzeroberfläche umgesetzt. Dabei stellte das Team fest, dass mit den vorgesehenen Mindestvoraussetzungen an die Hardware die Oberfläche nicht ausreichend responsiv war. Deshalb wurde im Anschluss hier die Performance näher untersucht und an Strategien gearbeitet, diese zu verbessern. Wäre dieses Risiko nicht früh im Fokus gestanden, hätte man das möglicherweise immer weiter aufgeschoben und dann wäre es vermutlich zu spät gewesen, grundlegende Änderungen an der UI vorzunehmen. Aus diesem Grund plädiere ich dafür, weniger Zeit im Vorfeld für Evaluierung und Planung zu investieren und statt dessen darüber nachzudenken, wo im Projekt die größten Risiken gesehen werden und wo die Implementierung demzufolge starten sollte. Nicht der Weg des geringsten Widerstandes führt hier zum Erfolg, sondern wir müssen uns den Herausforderungen des Projektes früh stellen und die problematischen Stellen früh beherrschen. Dann können wir den Rest des Projektes auch ganz entspannt umsetzen, weil wir die Gewissheit haben, dass wir die großen Brocken bereits aus dem Weg geräumt haben. Und so erhöhen wir auch die Chancen, dass wir zum gesetzten Zeitpunkt oder mit dem vorhandenen Budget eine gute Software für unseren Kunden gebaut haben – das Optimum was unter den gegebenen Rahmenbedingungen möglich war. Das ist genau das, was unser Kunde von uns erwarten kann.

“Durch Schaden wird man klug” – diese alte Volksweisheit scheint bei Entwicklern nicht ganz angekommen zu sein. Jedenfalls beobachte ich häufig, dass Entwickler sich damit zufrieden geben, wenn ein Bug gefixt ist. Und wenn dabei nicht noch andere Dinge kaputt gemacht werden, dann wähnt man sich bereits nahe am Optimum.   Aber in Fehlern steckt so viel Potenzial sich zu verbessern. Fragen die nach jedem gefundenen Fehler gestellt werden sollten sind z.B. :

• 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?

Ich glaube, wenn wir uns solche Fragen bei jedem Bug stellen, wird das zu einem Lerneffekt führen der sowohl die Methoden als auch das Mindset der Entwickler verändert. Und dies wird die Qualität unseres Teams nachhaltig verbessern – eine Chance die wir verpassen wenn wir nicht bereit sind aus unseren Fehlern zu lernen sondern diese einfach als gegeben akzeptieren und nur möglichst schnell beseitigen. Also bis zum nächsten Bug 🙂

Aktuell geistern zwei Begriffe durch die Entwicklerwelt, “Continous Deployment” und “Continous Delivery”. Gemeint ist damit, kontinuierlich (häufig) neue Funktionalität bereitzustellen, meist mit dem Ziel schnelles Kundenfeedback zu bekommen. Sind die beiden Beriffe nun gleich und wurde hier nur mal wieder für die gleiche Sache zwei verschiedene Begriffe eingeführt? Nein, es gibt hier einen kleinen Unterschied. Während “Continous Deployment” davon ausgeht, dass die Funktionen direkt bis zum Endanwender geliefert werden ist “Continous Delivery” ein kontinuierliches Deployment aus der Entwicklung and die nächste Instanz (z.B. UAT – User Acceptance Testing). Vielleicht lässt sich das an einem kleinen Beispiel verdeutlichen. Microsoft entwickelt den Team Foundation Server in Sprints von 3 Wochen. Daraus werden 2 Produkte gespeist, Visual Studio Online (Team Foundation Server in der Cloud) und der Team Foundation Server on premise (der im eigenen Netz installiert werden kann). Für Visual Studio Online nutzt Microsoft “Continous Deployment”, am Ende jedes Sprints wird die Produktivinstanz aktualisiert. Für den TFS on premise nutzt Microsoft “Continous Delivery”, d.h. die aktuelle Version wird intern für Tests deployed und häufig auch in Form von CTPs außerhalb von Microsoft verfügbar gemacht. Aber der TFS on premise wird nur ca. alle 3 Monate offiziell released. Nun kann man natürlich darüber diskutieren, ob 3 Wochen noch kontinuierlich ist. Die eigentliche Idee von “Continous Deployment” ist, eine neue Funktion sofort auszuliefern, wenn sie implementiert wurde und alle Tests gelaufen sind. Aber im Vergleich zu früher (2 Jahres Releases”“) ist das schon recht kontinuierlich und natürlich hängt die Deployment-Strategie auch vom darunterliegenden Prozess ab. So unterstützt beispielsweise Kanban “Continous Deployment” etwas besser als Scrum, da in Scrum typischerweise erst am Ende des Sprints deployed wird während Kanban einen kontinuierlichen Fluss einzelner Funktionen durch den Entwicklungsprozess abbildet. Man kann also vereinfacht sagen: Continous Delivery != Release Continous Deployment = Released