Die Grauzone zwischen klassischem und agilem Projektmanagement

Ist es an der Zeit, das klassische Projektmanagement ad acta zu legen? Nein, sicherlich nicht. Mit klassischem Projektmanagement wurden und werden unzählige große Projekte sicher zum Erfolg geführt. Auch im klassischen Projektmanagement bzw. in der Projektsteuerung gibt es den Plan-Do-Check-Act-Zyklus sowie ein eindeutiges und motivierendes, klares Projektziel. Auch dort gibt es Selbstorganisation. Und verschiedene Terminplanebenen, von grob bis fein. Was aber auch zum klassischen Projektmanagement gehört, ist das teils grenzwertige Anspruchsdenken der Akteure. Manch ein Auftraggeber äußert seinen Unmut in etwa folgendermaßen: „Es ist doch alles ganz genau geplant. Warum gibt es jetzt eine Abweichung vom Plan? Klarer Fall: Da hat jemand versagt. Diese ständigen Terminverschiebungen – das kann doch nicht sein. Dabei wissen wir doch genau, was wir wollen …“

Klare Projektvoraussetzungen entpuppen sich oft als Illusion

In der Realität wird von manch einem Auftraggeber nicht anerkannt, dass der Scope bei vielen klassisch gemanagten Projekten längst nicht so klar ist wie erhofft bzw. gegenüber den Stakeholdern dargestellt. In so einem Fall bleibt vielfach nichts Anderes übrig, als den Scope über ein iteratives Vorgehen im vollen Galopp zu klären. So eine Situation bringt die Projektleitung schnell in Erklärungsnot. Wie soll man das der Abteilungsleitung erklären und wie soll diese wiederum der Bereichsleitung Rede und Antwort stehen? Schließlich wurde die Budgetplanung für die nächsten drei Jahre vom Ausschuss genehmigt und diese stimmt schon jetzt nicht mehr. Genau darin liegt die Krux: Auf der einen Seite erfordern Entscheidungsprozesse in vielen Unternehmen oder Behörden eine detaillierte Budget- und Mittelabflussplanung für die nächsten Jahre – am besten auf den Cent genau. Auf der anderen Seite wird jedoch nicht anerkannt, dass viele Projektverläufe gar nicht so sicher planbar sind, weil etwa fachliches oder technisches Neuland betreten wird oder eine komplexe oder zumindest komplizierte Herausforderung zu bewältigen ist.

Ein Projektleiter muss immer auch Erwartungsmanager sein

Wenn es der Projektleiter in so einer Situation schafft, allen Beteiligten immer wieder klarzumachen, dass es Änderungen im Projektverlauf gibt und weiterhin geben wird, dass diese normal sowie unvermeidbar sind und damit bewusst umgegangen werden muss, dann kann das klassisch gemanagte Projekt zum Erfolg werden. Dabei stehen dem Projektleiter eine ganze Bandbreite im klassischen Projektmanagement bewährter Techniken zur Verfügung, wie z. B. Zielmanagement, Änderungsmanagement, Erwartungsmanagement, Krisenmanagement oder ein Taskforce-Modus. Oft reichen diese Methoden aber nicht mehr aus – hier kann es sinnvoll sein, auf agile Methoden zurückzugreifen.

Der Wechsel von Klassisch zu Agil

Idealerweise gelingt es einem Projektleiter, der sich im Rahmen einer agilen Transition in der Rolle des ScrumMasters oder Product Owners wiederfindet, eine zeitraubende Methodendiskussion zu umgehen und stattdessen in kleinen Schritten bewährte Elemente aus der agilen Toolbox auf das Projekt zu übertragen. Entscheidend ist, ein agiles Framework nicht blind überzustülpen, sondern sich des „Warums“ bewusst zu sein und mit Augenmaß vorzugehen. Bei Bedarf mag es helfen, Anpassungen am „Standard-Scrum“ vorzunehmen und sinnvolle Abweichungen von der „Standard-Methode“ zuzulassen, wenn sie dem Projekt dienlich sind. Denn Agile heißt noch nicht automatisch besser. So sind beispielsweise das Reflektieren und der Plan-Do-Check-Act-Zyklus auch im klassischen Projektmanagement bestens bekannt, allerdings fehlt häufig eine Kultur der regelmäßigen und systematischen Reflexion, etwa durch Retrospektiven. Im klassischen Projektmanagement finden Reflexionen, z. B. in Form von Lessons Learned, viel zu selten und oft erst nach Projektende statt. Für manch einen erfahrenen Projektleiter mag jedoch das Reflektieren eine Selbstverständlichkeit sein, noch während das Projekt läuft, sodass der Methodenwechsel von Klassisch auf Agil fließend gestaltet werden kann.

Augenmaß hilft bei der Einführung einer neuen Methode wie Scrum

Im Gegensatz zur Einführung agiler Methoden mit Augenmaß machen viele Unternehmen jedoch etwas Anderes: Sie führen Scrum pauschal auf der Teamebene ein. Dadurch kann eine unkoordinierte und erklärungsbedürftige Kluft zwischen der Realität in Projekt und Organisation auf der einen Seite und dem Idealbild von Scrum aus dem Lehrbuch auf der anderen Seite auftreten. Es gibt für die Implementierung agiler Methoden kein einfaches Schwarz-Weiß-Schema. Die Kunst liegt im Herausarbeiten der richtigen Grauschattierung – je nach Projektsituation und momentaner Verfassung der beteiligten Personen. Dazu gehört der Mut der Projektbeteiligten, den Fokus weiterhin auf die Erreichung der Projektziele und das Liefern von Ergebnissen zu richten und sich nicht in einer neuen Methode zu verlieren. Leider stehen in Unternehmen nicht immer erfahrene Projektleiter bereit, die dabei helfen, die Schmerzen der Einführung einer neuen Methode zu mildern.

Müssen Sprints dabei immer kurz sein?

Üblicherweise wird agiles Arbeiten mit kurzen Sprintzyklen verbunden, d. h. innerhalb von ein bis vier Wochen Sprintdauer wird ein Produktinkrement erstellt, anschließend Feedback dazu eingeholt und auf Basis der neuen Informationen entschieden, wie es weitergeht. In großen und z. B. technisch aufwendigen Projekten können vier Wochen bei Weitem nicht ausreichen, um ein testbares Produktinkrement zu liefern. In solchen Projekten kann ein Entwicklungszyklus mehrere Monate dauern. Bedeutet das, dass ein agiles Vorgehen in der Projektbearbeitung für solche großen bzw. aufwendigen Projekte nicht funktioniert? Müssen wir uns nicht auch im Agilen von einer falschen Vorstellung lösen? Agil ist nicht immer nur Scrum. Auch große bzw. technisch anspruchsvolle Projekte können mit agilem Mindset durchgeführt werden. Was spricht denn gegen einen 15-Monats-Sprint? Solange die Beteiligten wissen, dass es ein Sprint ist und nach oder sogar während des Sprints auf das (Zwischen)-Ergebnis und den Prozess geschaut wird und alle Beteiligten bereit sind, den Kurs zu korrigieren, sind die Anforderungen an agiles Vorgehen wunderbar erfüllt. Die Länge eines Sprints ist letztlich Definitionssache und muss zum Projekt bzw. Produkt passen.

Bei der agilen Projektbearbeitung sind Erwartungs- und Zielmanagement inkludiert

Wenn eine agile Vorgehensweise im Projekt vereinbart wird, dann müssen sich die Stakeholder auch darauf einlassen, dass der Scope nicht vollständig klar und im Detail fixiert ist. Es wird anerkannt, dass zu einem fixen Zeitpunkt nicht auch gleichzeitig ein vorher fixiertes Ziel erreicht werden wird. Stattdessen verständigen sich die Stakeholder auf eine Vision als Grundlage der Projektbearbeitung. Entlang dieser Vision wird in Teilschritten vorgegangen, es werden Minimum Viable Products (MVPs) und Zwischenlieferungen vereinbart. Es gibt zwar durchaus eine Planung für den zukünftigen Projektverlauf, jedoch entspricht dieser eher einer Prognose für eines von vielen möglichen Szenarien. Eine Roadmap, gerne auch über mehrere Jahre, hilft in der Kommunikation mit den Stakeholdern. Der Fokus liegt jedoch nicht auf dem Plan für die Zukunft, sondern auf den konkreten Arbeitsergebnissen der nächsten Meilensteine. Beim agilen Arbeiten erfolgt das Zielmanagement durch regelmäßige Kommunikation, z. B. in Form von Feedback. Das heißt, es wird immer wieder über die Ziele verhandelt. Und Verhandlungen können unbequem sein, sie können dauern. Aber sie sind unerlässlich, um am Ende Einigkeit in Bezug auf die Erreichung der Vision und eine klare Richtung für alle Projektbeteiligten zu gewinnen.

Bei langandauernden, bedeutenden Projekten ist häufig ganz automatisch das Top-Management involviert.

Bei großen Projekten kann durch die Management-Attention etwas gelingen, was im Zusammenhang mit weniger bedeutenden Projekten aufgrund fehlender Aufmerksamkeit von „oben“ nicht gelingt: Es entsteht echte Business Agilität, die weit über die Agilität des operativen Projektteams hinausgeht. Die strategische Ebene und die operative Ebene tauschen sich über den weiteren Kurs aus – die Geschäftsleitung bzw. Bereichsleitung geht mit der Programm- bzw. Projektleitung in den Dialog und gemeinsam klären sie die Ziele für den nächsten Quartals- oder Jahres-Sprint.

Business-Agilität braucht Koordination zwischen strategischer und operativer Ebene

In der „neuen“ agilen Welt wird die Verzahnung über alle Unternehmensebenen hinweg dringend benötigt, damit die agilen operativen Teams nicht von der strategischen Ebene abgekoppelt werden. Elemente, die eher dem klassischen Projektmanagement zugeordnet werden, wie Meilensteinplanungen, Budgetplanungen und Projektzielvereinbarungen, sind für die Stakeholder-Kommunikation unabdingbar – nur so werden die Entscheider-Ebene und das Top-Management abgeholt. Es geht um Kommunikation, wobei Projektleitung bzw. Scrum-Team stets vermitteln müssen, dass Planungen als Kommunikationshilfen und Prognosen zu verstehen sind, die Zukunft jedoch selten exakt planbar ist und außerdem von zukünftigen Entscheidungen abhängt.

Die Realität in vielen Unternehmen hat längst gezeigt: Es geht sowieso nur klassisch UND agil.

Lassen Sie sich nicht festlegen, ob ihr Projekt klassisch oder agil geführt wird. Wie oben beschrieben, gibt es nicht das Modell für Agilität, das man 1:1 umsetzen sollte. In der Realität muss man immer auf das Projekt bzw. das Produkt und das Unternehmen schauen und ein Vorgehen wählen und zusammenstellen, das tatsächlich passt. Ziel muss immer sein, eine praxistaugliche individuelle Lösung zu erarbeiten. Hierbei ist die Erfahrung ihrer besten Projektmanager eine äußerst wertvolle Basis, der Blick von außen, etwa durch Consultants, vervollständigt die Perspektive. Wir unterstützen Sie gerne, den richtigen Methodenmix für ihr Projekt, Produkt und Unternehmen zu erarbeiten.

Die Suche nach dem Warum – und wie Sie Ihre Vision finden

Ich arbeite jeden Tag mit Teams zusammen, die auf ambitionierte Ziele hinarbeiten. Sie bereiten beispielsweise den Market-Launch eines völlig neuartigen Hardware-Produkts vor oder überarbeiten das bestehende IT-System grundlegend. Diese Produkte erweitern das bisherige Angebot des Unternehmens. Sie sind Teil der Weiterentwicklung des aktuellen Geschäftsmodells und zahlen auf die Neuausrichtung ein, die vom Top-Management angestrebt wird. Die Teams selbst sehen jedoch häufig nur eines: Diese neuartigen Produkte passen nicht zum bisherigen Angebot des Unternehmens. Und so steht immer wieder die unausgesprochene Frage im Raum: Warum machen wir das?

Die Antwort auf dieses Warum bleibt man den Teams oft schuldig. Man gibt ihnen keine Vision, zeichnet ihnen kein Bild der Zukunft und lässt sie im Ungewissen, worauf ihre Arbeit einzahlt. Wenn wir uns die folgende Geschichte ansehen, wird jedoch deutlich, welchen entscheidenden Unterschied ein solches Zukunftsbild bewirken kann:

Ein Fremder geht durch die Gassen einer Stadt. Er trifft auf drei Maurer und sieht ihnen bei der Arbeit zu. Nach einiger Zeit fragt er die drei, was sie da tun. „Das sehen Sie doch”, erwidert der erste mürrisch, „Ich bearbeite einen Stein.” Und der zweite Maurer, der das Gleiche tut, sagt gelangweilt: „Na, ich errichte eine Mauer.” Der dritte Maurer allerdings antwortet mit glänzenden Augen: „Ich baue eine Kathedrale.”

Wir wollen alle eine Kathedrale bauen

Warum ist eine Vision wie der Bau einer Kathedrale so wichtig für uns? Weil wir alle auf der Suche nach unserem persönlichen Warum sind, das uns jeden Tag aufs Neue motiviert. Wir sind auf der Suche nach einer Vision, die unsere persönlichen Werte widerspiegelt. Und nach einer Organisation, die nach diesen Werten ausgerichtet ist und in der wir durch unsere tägliche Arbeit zur Umsetzung dieser Vision beitragen können. Wir wollen nicht einfach nur Stein auf Stein setzen. Wir wollen in 10 Jahren zu unseren Kindern sagen können: Das, was ich getan habe, hat etwas bewirkt. Siehst du diese Kathedrale dort? Die habe ich miterrichtet! Besonders in Zeiten der Veränderung und bei der Neuausrichtung eines Unternehmens braucht jeder Mitarbeiter und jedes Team ein solches Ziel vor Augen. Ein Ziel, das die Hoffnung auf Verbesserung aufkeimen lässt und den Weg in die neue Zukunft zeigt.

Und doch fehlt vielen Teams und Unternehmen eine solche Vision. Woran kann das liegen? Zum einen mangelt es oft an Zeit und andererseits fehlt das Wissen darüber, wie man überhaupt eine Vision entwickelt. Dabei ist das gar nicht so schwer.

Der Bauplan für Ihre Vision

Der erste Schritt ist meiner Erfahrung nach, sich als Führungspersönlichkeit – sei es als Product Owner oder Cluster Lead – die Zeit zu nehmen, um sich selbst darüber klar zu werden: Warum brauchen wir dieses Produkt? Eine Vision wirkt durch die Kraft der Worte, daher sollten Sie diesen ersten Entwurf Ihres Zukunftsbildes niederschreiben. Und dann stellen Sie sich die folgenden Fragen:

Wenn Sie jede dieser Antworten mit Ja beantworten können, dann nehmen Sie Ihre Vision und reden Sie darüber. Teilen Sie diese mit Sparring-Partnern und passen Sie sie immer wieder an. Sobald Sie Ihre Vision durch Iterationen entsprechend nachgeschärft haben, können Sie diese Ihrem Team vorstellen. Freuen Sie sich auf das Feedback, das ihnen dabei helfen wird, Ihr Zukunftsbild noch präziser zu formulieren.

Anschließend bleibt noch ein letzter wichtiger Schritt: Schicken Sie das Team mit dieser Vision auf die Suche nach dem Wie. Wie können wir als Team diese Vision erreichen? Welche Schritte sind notwendig? Seien Sie für Ihr Team da und beantworten Sie dessen Fragen. Und vor allem: Beobachten Sie, wie sich die Zusammenarbeit positiv verändert!

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:
Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.
In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.
Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?
Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?
Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.

Product Owner in Scrum

The Product Owner is mostly known to be responsible for two major things: a healthy ROI and prioritizing the backlog. However, his tasks go way beyond that and are critical for a Scrum team to succeed.
If you want to find out which other responsibilities a Product Owner has, please join me for my how-to video.

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

3 Argumente gegen User Stories und wie ihr ihnen begegnen könnt

In unseren Trainings oder in der Arbeit mit Teams begegnen wir einer Vielfalt von Gründen, warum eine bestimmte agile Praktik in diesem Team nicht angewendet werden kann. Dabei sind die Begründungen nur auf den ersten Blick spezifisch für das jeweilige Team und vor allem sind es in den seltensten Fällen tatsächlich sachliche Gründe, warum etwas nicht geht. Menschen stehen Veränderungen prinzipiell erst einmal kritisch gegenüber. Deshalb werden neue agile Praktiken nicht einfach ausprobiert, sondern meist erst einmal gründlich geprüft.
Daran ist prinzipiell nichts Falsches – unser Gehirn spart viel Energie, wenn es gelernte Praktiken abspielt und nicht immer Neues ausprobiert. Gleichzeitig kann es ganz schön frustrierend sein, wenn man einem Team etwas zeigen möchte und nur Widerstand erntet. Manchmal verbirgt sich hinter der vorgeschobenen rationalen Begründung auch ein Gefühl der Unsicherheit. Ehrlich wäre es, einfach zu sagen: „Ich will es nicht machen! Den alten Prozess kenne ich, der neue macht mir Angst, weil ich noch nicht weiß, was genau passiert.“ Im beruflichen Kontext sind aber wenige so reflektiert und ehrlich und deshalb lohnt es sich, sich als Scrum Master oder Agile Coach schon einmal auf die typischen Widerstände einzustellen, die einem bei der Einführung eines neuen Meetings, Artefakts oder einfach nur einer kleinen Prozessänderung begegnen werden.
In den nächsten Wochen wollen wir euch einige jener Argumente nennen, die uns immer wieder begegnen, damit ihr dagegen gewappnet seid und euren Teams helfen könnt, sich auf das Abenteuer des Ausprobierens einzulassen. Im ersten Teil widmen wir uns dem Thema User Stories.

„So ein simpler Satz ist mir viel zu wenig!“

Ganz klar, die User Story in ihrer klassischen Syntax ist einfach – und das soll sie auch sein! Eine gute User Story ist nämlich nichts anderes als eine „Einladung zur nachgelagerten Konversation“. Das bedeutet: In ihrer offenen Formulierung ist sie dazu gedacht, dass der Product Owner mit dem Team über die User Story spricht, sie auf den Prüfstand stellt und dadurch die Details immer klarer werden – bis die Story „ready for sprint“ ist.

„Aber eine User Story kann doch nicht mindestens zwei Mal im Refinement gewesen sein!“

Gerade weil User Stories anhand der INVEST-Kriterien formuliert werden, sollen sie unter anderem verhandelbar und klein sein. Das bedeutet, dass es viele Gespräche und einige Durchläufe braucht, um mehr Klarheit über die Anforderung zu bekommen, die sich in der User Story versteckt. Je vager die Formulierung und je näher die User Story noch an ihrer Ideenphase ist, desto klarer wird, dass es mehr Details braucht, bis alle Teammitglieder das gleiche Verständnis über den Inhalt der User Story haben. Das Backlog Refinement ist dafür der geeignete Termin. Sprecht als Team über den Inhalt, verschafft euch Klarheit und ergänzt, was das Zeug hält: Akzeptanzkriterien, Testfälle, Abhängigkeiten, Risiken und alle Details, die euch einfallen. User Stories werden dann auch oft kleiner geschnitten, wenn sie sich für einen Sprint als zu groß herausstellen.

„User Stories, okay, aber Personas? Brauch ich wirklich nicht!“

Simon Sinek sagt immer wieder, dass das „Why“, also das Warum, das einen antreibt, klar sein muss. Daher sollte die dahinterliegende Antwort etwas elaborierter sein als ein lapidares „Isso“. Auch wenn dem Team der Mehrwert klar ist, ist es unglaublich hilfreich, sich die Anforderungen mit der Brille bestimmter Zielgruppen anzusehen: Warum tickt meine Zielgruppe so wie sie tickt? Und was bedeutet das für mein Produkt? Gibt es widersprüchliche Anforderungen meiner User-Gruppen? Worauf will ich als Product Owner mein Augenmerk legen und für wen priorisiere ich? Personas helfen dabei, sich als Team in die jeweilige Zielgruppe hineinzuversetzen. Je mehr Daten und Fakten in die Persona fließen, desto besser – und dennoch: Entwerft eure Personas so, als wären sie reale Wesen mit Charakter, Lebenslauf, Vorlieben und gebt eurem Produkt damit so viel Kontext, dass ihr euch der Frage nach dem „Why“ leichter nähern könnt.
Sind euch in eurer Arbeit noch andere Argumente gegen User Stories begegnet? Lasst uns wissen, wie ihr darauf reagiert.

Dieser Beitrag ist im Pair Writing mit Sandra Wittmann entstanden.
Foto: CC0 Creative Commons, pixabay – aitoff

Wenn’s wichtig ist, kommt’s wieder: über das "Nein" des Product Owners

In meiner Karriere als Beraterin durfte ich viele Projekte und Produktentwicklungen beobachten. Eine dieser Beobachtungen möchte ich besonders gerne teilen: Teams, die zu vielen Anforderungen „nein“ sagen, sagen immer zu einigen wenigen, wirklich wichtigen, ein ganz klares „Ja“. Diese Anforderungen werden mit einem Commitment gekrönt und werden garantiert in einer hohen Qualität geliefert. Diejenigen, die zu allem „ja“ sagen, bekommen in der Regel nur Weniges wirklich fertig. Hier wird es immer schwieriger, sich zu fokussieren und eine gute Priorisierung hinzubekommen.
Und wenn das Team merkt, dass etwas mal wirklich vergessen wurde, oder sich auf Basis der gelieferten Features und Stakeholderfeedback herausstellt, dass etwas wichtig ist, wird dies vom PO bereitwillig ins Backlog aufgenommen.
Das St. Galler Management Modell sagt dazu: „Durch das Weglassen von Vielem wird das Realisieren von Wenigem ermöglicht.“ Damit stellt es ein Grundparadigma für gutes Management heraus, das mit den Werten, Haltungen und Sichtweisen agiler Produktentwicklung und der Aufgabe des PO übereinstimmt, mit Anforderungen sehr selektiv umzugehen.
Der gute Product Owner bewältigt zwei Herausforderungen:
a.) Er bringt den Mut zum „Nein“ auf und
b.) vertraut darauf, dass wirklich Wichtiges wiederkommt, obwohl es schon einmal abgelehnt wurde.
Das spart Zeit beim Verwalten langer Anforderungslisten und ermöglicht den Fokus auf das Liefern, aufs Wesentliche.
Wagen Sie das Experiment und sagen Sie „Nein“.

Foto: (c) rawpixel

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Video: Der Product Owner

Die Rolle des Product Owner ist vielleicht die einfachste Rolle und doch auch jene, die von vielen vollkommen missverstanden wird. Der Product Owner ist Teil des Scrum-Teams. Er arbeitet mit dem Scrum-Team. Das heißt: Er ist kein Anforderer, der etwas vom Team bauen lässt, sondern ein integraler Teil. Er hat eine spezielle Sicht auf die gemeinsame Arbeit. Er will, dass das Scrum-Team möglichst nur das liefert, was auch wertvoll ist – also vom Kunden gekauft werden wird.
Der Product Owner ist für den Return on Investment zuständig, er entwickelt die Produktvision, teilt diese, arbeitet mit den Stakeholdern, um die Constraints zu finden und reduziert das Backlog immer wieder, um möglichst nur das Wichtigste und Wertvollste zu entwickeln.
 
image_Strategie-Product_Owner
 
Im Video stelle ich den Product Owner kurz vor und ich hoffe, es ist verständlich, was ich dazu zu sagen habe.
 

 
Viel Spaß beim Anschauen! — Boris

How do stakeholders participate in Scrum projects?

A program manager asked me how one makes sure that all necessary information from different stakeholders is considered in a Scrum initiative. How can it be made sure that nothing gets forgotten? Usually, the answer to this question is: the team has to care for all the information. Another solution would be: everybody needs to be part of the team. However, these solutions look great on paper but they are not feasible in organisations which want to start using an agile approach. Well, at least in the beginning.
We have to differentiate between strategical and tactical processes of product development. In other words, you have to consider the long term view (strategical) and short term view (tactical). Any organisation needs to plan and execute both processes simultaneously. But both aspects need different good practices to support success.
I suggest to free the Product Owner from working on tactical issues as much as possible. So we do not want him/her to spend time on e.g. writing user stories or talking to end users to come up with ideas for features. At borisgloger consulting we believe his/her capabilities should be strengthened in order to work on the strategic level. On one hand that means he/she shall have the authority to work strategically more often and on the other hand it means he/she shall dedicate his/her time to the practices that one needs for performing on this level:

Most people in the Scrum community know how to build a product vision or a product backlog but what is a list of constraints? What is its purpose and where does it come from?
image_stakeholders
 

List of Constraints

The list of constraints contains the needs of the stakeholders. The Product Owner is responsible for facilitating a conversation amongst all stakeholders. In this conversation they are supposed to talk about their specific needs (see picture above). I use the word “needs” instead of “interests” because I want to distinguish strategic needs from tactical features. For instance, if someone in an organisation is responsible for making sure that a product meets the regulatory requirements of the Food and Drug Administration (FDA), he has the need that these requirements are acknowledged. So it is the job of the Product Owner to translate this need into strategical constraints. This practice ensures that the regulatory requirements are not treated as a low priority feature.
Together with all stakeholders, the Product Owner creates the list of constraints at the beginning of a Scrum initiative (product, service). However, it is not a static but a rather dynamic list. It is the job of the Product Owner to stabilise this list over time. To do this, he creates a reflexive process that continuously reviews the validity of constraints. He also updates the list if necessary. Please notice that he has to communicate all updates to all stakeholders. He also has to ensure that all resulting changes are incorporated into the product or service.

Stakeholders

For understanding Scrum as a model, reducing the list of stakeholders to a set of roles is useful. However, a model masks the fact that a Product Owner needs to take the needs of all stakeholders into account. So, who is a stakeholder of a Scrum initiative? Which players are part of a project or department? Who is influenced by it? Who wants to influence the outcome of the project, even if they do not have a role within the project? And, most important, what are their interests and motives? Analysing who will be relevant stakeholders is essential for being successful with your projects. Again, the list of stakeholders must be reviewed and monitored throughout the delivery cycles. So the list I present here is not a comprehensive one but may rather be seen as a starting point for you:

  1. Customer (internal, external): Who is the customer? Who ist the real decision maker? What is his/her need?
  2. People in the development team: What does every individual in the team want to achieve for his- or herself? Maybe your team consists of parents of very young children. What do they need to be effective team members?
  3. Other departments/projects: What are the needs of these projects or departments? Means: Which interests does the management of these initiatives have? For example:
    a. HR department
    b. the work council
    c. Sales
  4. End user: Who is the end user? Which needs do they have, besides ideas for new features?
  5. Management:  Which interests does the management or the management of sister departments have? Are there any political aspects we have to bear in mind in this project?
  6. Suppliers (other teams, external companies): Do our suppliers have specific needs that our  project/service needs to meet
  7. Governments/Regulators: Is there a player that we need to take into consideration? What do we need to know about them?

Dialogue

In our company we follow a very strict principle: “Community building first, decision making second.” It means more or less: bring the respective people together and do so on a regular basis. What’s the idea behind this? We want to create a mutual relationship to build trust. Because we believe trust is based on knowing each other. So it is paramount that the Product Owner talks with all people using round table discussions. The purpose of this conversation is to recognise all needs and build trust.
We use a format called the Circle Way to facilitate these meetings successfully [1]. By doing this on a regular basis you will be able to create a “community” that cares for your product or service. As an additional benefit, it creates a clear and concise picture of the environment a Scrum initiative is working in and for.

Tactical work

The tactical work for your Scrum initiative is done by the cross-functional, multi-disciplinary product/service (development) team (in short: the team). In its role as a stakeholder the team works with the Product Owner on creating, understanding and updating the list of constraints. Team and Product Owner share their vision and they work together on the roadmap. However, the team works with the end user on ideas for features and creates the according user stories, implements the user stories into the application, runs the sprints and so on. The Product Owner works with the team on the tactical level to enable and facilitate decisions but he/she shall not heavily influence tactical decisions of the team.
Using this refined understanding of the role of the Product Owner, the usage of constraints and the way stakeholder can influence the Scrum initiative on a regular basis will enable Scrum-teams to become more productive because it channels information to the right people and gives them  authority.
 
Literature
[1] If you are interested to know more about the Circle Way please have a look into this little 2-page document. It will tell you how to run a meeting using this process.

Ein Product Owner für zwei Teams, oder?

Mein Kunde hatte sich innerhalb eines großen Entwicklungsprojekts vorgenommen, nicht nur die verschiedensten Applikationen den neuen Anforderungen des Marktes anzupassen, sondern gleichzeitig die Software-Architektur zu modernisieren, um Continuous Delivery zu ermöglichen. Gestartet wurde mit mehreren parallel laufenden Scrum-Teams an vier verschiedenen Standorten. Wir hatten einen Kollegen aus dem Fachbereich, der neben der Rolle des Kunden auch zwei Scrum-Teams als Product Owner betreuen sollte. Auf welche Herausforderungen stößt dieser nun in der Rolle als Product Owner mit seinen beiden Scrum-Teams?

Was der Product Owner eigentlich tun sollte

Im Allgemeinen ist der Product Owner für das entstehende Produkt und den dazugehörigen Business Value verantwortlich, den das Produkt für das Unternehmen erzeugen soll. Gemeinsam mit dem Team arbeitet er an der Vision, pflegt das Backlog (Schreiben von User Storys und deren Priorisierung im Backlog) und er ist im ständigen Kontakt mit den Stakeholdern.
In meinen Augen ist der Product Owner ein betriebswirtschaftlicher Allrounder mit Liebe zur eingesetzten Technologie, der verschiedene Funktionen in einer Person vereint und dafür sorgt, dass das Richtige entwickelt wird. Zusätzlich bringt er die unterschiedlichen Positionen von Team und Stakeholdern zum größtmöglichen wirtschaftlichen Nutzen für das Unternehmen auf einen Nenner. In diesem Fall sah es aber anders aus.
Bild_ella_1

Der Product Owner hat keine Zeit

Bereits in den ersten Sprints stellten beide Scrum-Teams unabhängig voneinander fest, dass ihr Product Owner für sie kaum zeitlich verfügbar war. Das Backlog war weder vorbereitet noch priorisiert und daher liefen die Meetings sehr unstrukturiert und nicht konstruktiv ab. Nur sehr schwer konnten die Teams in Erfahrung bringen, welche User Storys im kommenden Sprint bearbeitet werden sollten. Für Fragen während des Sprints stand der Product Owner nur sehr eingeschränkt zur Verfügung, da er in seiner Rolle als Hauptansprechpartner im Fachbereich viele Aufgaben wahrnehmen musste und häufig unterwegs war. Letztendlich war auch der Product Owner mit der Situation unzufrieden, weil er den Anforderungen der beiden Teams nicht gerecht wurde und zunehmend überfordert war.

Der dreigeteilte Product Owner

Während einer Coachingsitzung mit diesem Product Owner entstand folgendes Bild:
Bild_ella_2
Es zeigt, dass schlichtweg die Fokussierung fehlte. Der Verantwortliche konnte sich weder seiner bisherigen Tätigkeit als Kunde noch seinen beiden Scrum-Teams widmen.
Mit dem Fokus auf nur ein Team könnte er sich besser in die Rolle des Product Owners einfinden. So sollte ein Product Owner Vertrauen in die Fähigkeiten seines Teams haben und es selbstständig entscheiden lassen, wie es seine Anforderungen umsetzen will. Dieses Vertrauen kann er jedoch nur erlangen, wenn er sich auf eine Sache, hier ein Scrum-Team, konzentrieren und sich mit dem Team und dessen Fähigkeiten auseinandersetzen kann. Zusätzlich ermöglicht die Fokussierung, auch ausreichend Zeit in die eigene Vorbereitung zu investieren. Mit einem vorbereiteten Product Owner laufen die Meetings strukturiert und effizient ab, sodass alle motiviert in den neuen Sprint starten können.
Ein Product Owner ist zudem Teil des Scrum-Teams. Er teilt sich im Idealfall mit dem Dev-Team und dem ScrumMaster einen eigenen Teamraum, verwaltet dort seine Artefakte (Story Map, Product Backlog etc.) und ist als Ansprechpartner verfügbar: für das Team und für die Stakeholder. So kann er sich voll und ganz auf das Team und deren Anfragen konzentrieren und wird nicht ständig unterbrochen. Auf allen Seiten ist dadurch ein Produktivitätsschub zu erwarten.

Ein Product Owner für zwei Teams, oder?

Im Laufe der ersten Sprints erkannten wir, dass die Konstellation nicht zielführend war. Selbst nachdem der Product Owner ein Scrum-Team abgegeben hatte, spürten wir keine wesentliche Verbesserung. Und so wurde schlussendlich entschieden, dass sich der Vertreter des Fachbereichs nun auf diese Rolle konzentrieren sollte – sie beanspruchte seine volle Aufmerksamkeit.
Ich bin der Meinung: Grundsätzlich ist es nicht sinnvoll, einen Product Owner für zwei Scrum-Teams einzusetzen, geschweige denn einen Kollegen, der mit zusätzlichen Aufgaben betraut wird. Die beschriebene Situation zeigt gut, auf welche Schwierigkeiten alle Beteiligten stoßen und dass diese sich nicht immer beseitigen lassen. Die Kunde-Product Owner-Konstellation führte außerdem dazu, dass zwei Teams nicht ausreichend gut und schnell entwickeln konnten und das wiederum verlangsamte das Projekt. Um einer solchen Situation künftig vorzubeugen, sollten alle Projektinvolvierten vor dem Start in den Aufgaben und Rollen innerhalb von Scrum trainiert werden. Zusätzlich sollten die Ausgestaltung der Scrum-Rollen und die Erwartungshaltung innerhalb der Organisation besprochen werden. So können bereits im Vorfeld mögliche Bottlenecks identifiziert und gelöst werden, bevor sie innerhalb des Projekts zu realen Schwierigkeiten führen. Und schließlich bin ich davon überzeugt, dass ein Product Owner seine Rolle nur so effektiv wie möglich ausführen und alles Nötige für sein Team geben kann, wenn er fokussiert arbeitet und sich nicht um mehrere Teams oder Projekte innerhalb der Organisation kümmern muss.
Übrigens ist es durchaus möglich, in Scrum einen Product Owner für zwei Teams einzusetzen. Allerdings setzt das unbedingt voraus, dass die Teams bereits seit mehreren Jahren mit Scrum gearbeitet haben und dass es die Produkt-Business-Beziehung vollständig durchdrungen hat. Der Grad der Selbstorganisation innerhalb der Teams ist dann bereits so hoch, dass es ausreicht, die große Vision des Product Owners zu kennen, um das Richtige zu liefern.
Bild_ella_3
 
Weitere Informationen zu Scrum 3.0 finden Sie hier: “Von Scrum 1.0 zu Scrum 3.0” oder “Boris Gloger and Scrum 3.0: Is the Future of Scrum Really No Backlogs or Standups??”

Real life tips: Do's and Don'ts for Scrum implementations – the Product Owner

Do

Make the Product Owner a part of your Scrum Team. Why? Because it’s supposed to be one delivery unit. Not two, with one side delivering ideas, and the other side delivering the product and then both sides arguing about what was really required. I’ve seen a good share of political fights for power over people being carried out on the back of the employees: The PO wasn’t allowed to sit next to the Dev Teams because the PO’s manager was afraid of limited influence. Of course his behavior consequently influenced nothing but lead time and the quality of features.
The Product Owner, just like the ScrumMaster, also assumes a leadership role. Therefore, empower your Product Owners to make (risky) decisions on their own. Why? Because eventually it enables everyone to learn from mistakes: A Product Owner once hesitated to switch on a feature that went live four weeks ahead of schedule, because her superior was on vacation and she was afraid that something might go broke. So instead, all the additional buffer that could have been used to fix potential bugs before the promised date, was consumed and the feature was switched on the exact date when it was supposed to – and, of course, it turned out to be buggy and left behind dissatisfied customers.
If your Product Owners work in a different location than your development teams, make them visit each other on a regular basis. Having Skype calls and telcos is better than writing emails and tickets, yet, looking each other in the eye when trying to fix a serious issue or discussing priorities is a whole new ball game! Especially regarding different cultural backgrounds and mother tongue, personal meetings and workshops help to identify barriers quicker and to get the involved parties on the same page. If you encounter political differences between parties, set up a meeting on neutral ground so no one feels like they’re having a disadvantage.

Agiles Anforderungsmanagement mit dem Poke-Prinzip

Marco Ley, Leiter eEntwicklung bei CosmosDirekt, sprach auf den Softwareforen Leipzig letzte Woche über “Agiles Anforderungsmanagement: Das Poke-Prinzip – von harten Anforderungen zu kleinen Experimenten.“ Ich muss von diesem Vortrag erzählen, weil ich so stolz auf dieses CosmosDirekt Team bin. Ich habe nichts dafür getan, dort kennt man mich nicht, und ich will gar keine Lorbeeren einheimsen, die Marco Ley gehören, aber ich bin einfach vollkommen fasziniert.
Kennt ihr das, wenn ihr hart für etwas arbeitet und dann feststellt, dass all das, worüber ihr nachgedacht und ständig gesprochen habt, plötzlich Realität wird? Nun ja – so fühlte ich mich an diesem Morgen beim Vortrag von Marco Ley. Er sprach davon, dass seine Entwicklungsteams vollständig crossfunktional aufgestellt sind – UX, RE, Tester, Developer. Diese Teams arbeiten nicht etwa Anforderungen ab, sondern erarbeiten die User Storys selbstständig, basierend auf groben Vorgaben. Und es sind nicht etwa klassische User Storys, sondern Hypothesen, die in mehr oder weniger aufwendigen A/B Tests auf der Produktivumgebung geprüft werden, so dass die Funktionalitäten für das gesamte CosmosDirekt-Portal live gestellt werden. Die durch die Implementierung gewonnenen Daten beweisen, ob sie wirklich einen Return On Investment bringen.
Damit zeigt uns Herr Ley, dass es ihm gelungen ist, die Rolle des Product Owners so zu leben, wie es meiner bescheidenen Meinung nach sein sollte. Er kümmert sich darum, Ideen zu finden, diese daraufhin zu bewerten, ob man damit Geld verdienen kann und macht dann diese Ideen zu Hypothesen, die er von seinen Kollegen durch Implementierung überprüfen lässt. Was funktioniert, wird behalten, der Rest wieder entsorgt. Einfach toll!
Wir haben ihn natürlich gefragt, wie er erkennt, ob er Erfolg mit der Funktionalität hatte, und er sagte: „Weil wir eine Datenbasis haben.” Er trifft Entscheidungen auf Basis von Daten, die er durch Ausprobieren gewinnt und nicht durch politische Überlegungen. Chapeau!Wenn man ihm so zuhört, tut mir die übrige Online Direktversicherungsbranche leid. Sie kann sich warm anziehen, sollte sich sein Vorgehen bei ComosDirekt weiter durchsetzen. Sein Team wird allen anderen einfach davonlaufen.
Vielen Dank für diesen tollen Vortrag!
An dieser Stelle noch etwas Werbung: Die Softwareforen in Leipzig haben mit der Agilen User Group, die sich dort zwei Mal im Jahr trifft, eine wirklich tolle Veranstaltung ins Leben gerufen. Ich bin sehr dankbar, dass ich dabei sein darf. Mehr Infos hier

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.
IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.
Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.
Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Skalierung aus der falschen Richtung

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.
In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.
Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.
Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.
In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.
Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?
Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.
Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?

Mit der Reihe “Design Thinking für Product Owner” wollen wir Product Owner Anhaltspunkte dafür geben, wie sie ihr Produkt gestalten können und wie sie die Items für das Product Backlog generieren können.

Warum ist Design Thinking für Product Owner wichtig?

Der Product Owner ist für den Return on Investment verantwortlich, er bestimmt die Eigenschaften des Produkts, priorisiert nach Business-Value und kommuniziert eine klare Produktvision. Aber was der Nutzer wirklich braucht und wie aus vagen Produktideen eine klare Produktvision wird, beantwortet Scrum nicht!
Genau hier kann Design Thinking den Product Owner unterstützen. 
In Iterationen nähert man sich der bestmöglichen Lösung für den Nutzer, generiert Wissen für sich und andere und kann schlussendlich dem Kunden und dem eigenen Scrum-Team eine getestete und erfolgversprechende Produktvision im Spannungsfeld aus Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit präsentieren.
DT01_1
Design Thinking behält dabei stets die Menschen, die das Produkt benutzen sollen, im Fokus und strebt danach, die Erfahrung des Nutzers mit der kreierten Lösung zu verbessern.

Was ist eigentlich Design Thinking?

Viele Menschen sehen auf den ersten Blick nur den Design-Thinking-Prozess, im Grunde ist Design Thinking aber eine agile Grundhaltung und eine Sammlung verschiedener Techniken aus unterschiedlichen Disziplinen. In der Kombination soll dies die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen. Die Entwicklung von Ideen im moderierten Design-Thinking-Prozess ist dabei absolut nutzerfokussiert, ergebnisoffen und doch ergebnisorientiert. Das interdisziplinäre Team sucht nach aktuell unbefriedigten menschlichen Bedürfnissen, die dann im Mittelpunkt der Lösungsfindung stehen.
Mitte der 1990er-Jahre wurde an der Fakultät für Ingenieurwesen der Universität Stanford der Name “Design Thinking” für dieses methodische Gerüst der Innovationsarbeit geprägt und in der 1991 gegründeten Innovations-Agentur IDEO bereits angewendet.
In Europa wird diese Methode heute an der School of Design Thinking des Hasso-Plattner-Instituts in Potsdam … nun, nicht gerade gelehrt … eher erfahrbar gemacht.

Was heißt “agiles Mindset”?

Die wichtigsten Komponenten sind das Team, der Raum und der Prozess, aber ohne die passende persönliche Einstellung funktioniert Design Thinking nicht. Design Thinking braucht “T-shaped People”! Eine Bezeichnung für Menschen, die eine Tiefe/Spezialisierung in ihren Skills (vertikaler Balken) aufweisen, aber dennoch in der Lage sind, über Ihre Disziplin hinaus (horizontaler Balken) mit anderen Experten und Perspektiven zusammen zu arbeiten, zu teilen und zu wachsen.
 Der Design-Thinker sollte mit Unvorhersehbarkeit und Unsicherheit umgehen können. Positiv formuliert: Es bedarf einer mutigen, neugierigen und ergebnisoffenen Grundhaltung, denn der Design-Thinker kennt zu Beginn die Lösung nicht und wird erst im Laufe des Prozesses zum Experten. Er provoziert das Scheitern und setzt sich dem gnadenlosen Feedback der Nutzer aus … und das tut weh! 
Aber es ist auch der Auftakt zu neuen Erkenntnissen und – da man stets im Team arbeitet – zum gemeinsamen Lernen.
All dies sollte der Design-Thinker wirklich wollen, verordnen kann man es nicht.
Design Thinking & Change Management Flipcharts
In den folgenden Beiträgen zu “Design Thinking für Product Owner” werde ich Design Thinking näher erklären und aufzeigen, wie es mit Scrum kombinierbar ist.
 Ich freue mich über Fragen, Anregungen und Diskussionen!

Der ScrumMaster – zwischen Stühlen und Fronten

Ort: Meetingraum
Zeit: 08:47
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Weit gefehlt.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.

You can't be everything to everybody – 4 Strategien für ein Minimum Viable Product

In einem meiner letzten Beiträge habe ich bereits über die Bedeutung des Minimum Viable Products geschrieben. Dieses Mal stelle ich nun vier mögliche Strategien vor, Kunden aber auch potentielle Investoren bereits vor dem eigentlichen Launch für ein Produkt zu begeistern und wertvolles Feedback einzuholen.
Das Erklär-Video
Das Erklär-Video ist kein Produkt im engeren Sinne, sondern beschreibt dem potentiellen Nutzer die Funktionen, die er in Kürze von dem Produkt erwarten kann. Dieses Video ist entweder ein kurzer Animationsfilm, oder vielleicht ein Video eines bereits funktionierenden Prototypen. Ein gutes Beispiel für ein Video als MVP lieferte Dropbox: Bereits vor Fertigstellung der ersten Release sprang die Zahl der Newsletter-Abonnenten innerhalb eines Tages von 5.000 auf 75.000. Defintiv genug, um ein Gefühl dafür zu bekommen, ob es sich lohnt, weiterzumachen. Es versteht sich von selbst, dass ein solches Video entsprechend beworben werden muss.
Die Landing Page
Auf einer Landing Page landen Kunden in der Regel dann, wenn sie im Vorfeld auf eine Online-Anzeige geklickt haben. Sie ist also eine Art Barometer für den Erfolg der Online-Marketing Aktivitäten. Trotzdem soll sie den Besucher im nächsten Schritt dazu anregen, sich für einen Newsletter zu registrieren. Die größte Herausforderung besteht darin, die Value-Proposition so simpel und eindrucksvoll wie möglich zu transportieren – beispielsweise indem man sie mit dem Erklär-Video kombiniert. Achtung: Eine Landing Page ist nur dann wertvoll, wenn man entsprechende Analyse-Tools, wie beispielsweise Google Analytics, einbindet, um den Erfolg oder Misserfolg auch messbar zu machen.
Das Wizard of Oz MVP
Ein Wizard of Oz Minimum Viable Product gibt an der Oberfläche vor, ein Produkt oder ein Service zu sein, das in Wahrheit so noch nicht existiert. Das US-Vorbild des Onlineversandhandels Zalando, zappos.com, hatte beispielsweise damit angefangen, Schuhe in lokalen Schuhläden zu fotografieren und anschließend online zu stellen. In dem Moment, in dem Kunden diese dann online auswählten, gingen die Gründer von Zappos zurück in den Laden, kauften das ausgewählte Modell und kümmerten sich um den Versand. Wichtig: Hier geht es noch nicht darum zu überprüfen, ob ein Produkt oder Geschäftsmodell skalierbar ist, sondern lediglich darum, eine Hypothese zu testen.
Das Concierge MVP
Das Concierge MVP eignet sich besonders dann, wenn das zukünftige Produkt automatisierte Prozesse beinhalten soll, die so noch nicht abbildbar sind. Ich selbst habe sehr gute Erfahrungen mit dieser Art von MVP gemacht: Für eine Smartphone App wollten wir Veranstaltungsdaten über ein Content Management System auch in der App verfügbar machen. Da die erforderliche Schnittstelle für Datenimport und -umformatierung noch nicht fertig war, wir aber unbedingt den Kunden von unserem Produkt überzeugen wollten, haben wir die Daten eben selbst und von Hand eingetragen – mehrere Tage hintereinander, gerne bis tief in die Nacht. Das war zwar mitunter nicht die spannendste aller Tätigkeiten, aber auf diese Weise konnten wir zeigen, wie sich unser Produkt auf Nutzerseite am Ende anfühlt, ohne dass wir bereits den kompletten Funktionsumfang anbieten mussten.
Der Grad der Anwendbarkeit des MVP-Ansatzes und der hier aufgeführten Strategien variieren sicherlich stark, je nachdem, um welches Produkt es sich letztlich handelt.
Die Grundidee des Minimum Viable Products – sich bei der Produktentwicklung auf einige wenige Kernfunktionen des späteren Produkts zu fokussieren – ist jedoch branchenübergreifend gültig und sollte jedem Product Owner präsent sein.

Halbgare Visionen

Welche Führung braucht es, um Produkte zu entwickeln? Zu den Aufgaben von Führungskräften gehört sicher die Entwicklung der Mitarbeiter und das Durchsetzen eines groben Zielbildes. Und doch sind diese Aspekte zu wenig, wenn es um Produktentwicklung geht. Viel zu wenig. David Auerbach hat im Slate Magazine die Lanze für den agilen Produktmanager gebrochen. Sein Credo: Es reicht nicht, das beste Team auf Erden zu haben, wenn keiner da ist, der die Entwicklung so genau kennt, dass er jederzeit entscheiden kann, was tatsächlich gebaut werden soll.
In der traditionellen Vorstellung von Führung kommt der CEO mit einer Vision und lässt diese durch die Unternehmensinstanzen (in hierarchischer Reihenfolge) ausbuchstabieren, planen und umsetzen. Die Interaktion zwischen den hierarchischen Ebenen beruht auf Delegation und regelmäßiger Überprüfung der festgesetzten Erwartungen auf Erfüllung. Die Führungskraft ist dann erfolgreich, wenn Mitarbeiter die gesteckten Ziele erreicht haben.
Was kommt bei einem solchen Ansatz raus? Nichts Gutes. Auerbach spricht von “half-baked visions” – halbgaren Visionen. Als Beispiele nennt er Microsoft, Google und Facebook. Alle drei Unternehmen seien technisch auf hervorragendem Niveau, doch fehle, anders als bei Apple, die Entwicklung eines stimmigen Produktdesigns: “Pretty much every new Microsoft product of the last 10 years fell prey to lousy execution of a half-baked vision, from the Kin to the Surface to Windows 8. But you can see difficulties of product management affecting other companies as well. Facebook’s user experience is simply a mess, still not offering any significant search capabilities (…). Google’s user experience seems to be splitting in two, with its traditionally austere search properties bearing little resemblance to the more gaudy presentation of Google Plus, with Gmail and YouTube seemingly caught in the middle.”
Diese konkreten Einschätzungen kann man teilen oder nicht. Was bleibt, ist das Bild, das Auerbach vom agilen Produktmanager zeichnet. Er ist nicht mehr derjenige, der sich auf die grobe Vision beschränkt. Seine Vision sind die vielen Details, die in der Produktentwicklung stecken. Der agile Produktmanager kennt sein Produkt “end to end”, so dass er in jeder Diskussion mitreden und entscheiden kann. Sein Arbeitsplatz ist nicht das Vorstandsbüro, sondern die Werkbank – eben überall dort, wo Entwicklung stattfindet. Als positives Beispiel nennt er Marissa Mayer von Yahoo. Ihre Detailversessenheit wird ihr häufig negativ ausgelegt, doch Auerbach sieht gerade darin ihre Stärke. Denn erst mit ihrem Wissen sei sie in der Lage, die Lieferungen der einzelnen Teams zu einem kohärenten Ganzen zusammen zu fügen:
“The product manager ideally does not take credit for the deep skills of the people with whom she works. Instead, she works as a peer to draw the necessary connections between them and keep them in sync. She pays attention to the existing self-organization of small groups of smart people and sympathetically exerts soft power to try to leverage their skills on a larger scale, without wrecking what they already do well. She does not build from the ground up, but helps fit pieces together—horizontally.”
Dieses Rollenbild – es ist extrem anspruchsvoll. Es verlangt erstens vom Produktmanager, sich in Tiefen vorzuwagen, die traditionell nur Entwicklern vorbehalten sind. Zweitens verlangt es vom Produktmanager, sein Tiefenwissen eben nicht dafür einzusetzen, bei jeder Diskussion mitzureden und mitzuentscheiden. Das bedeutet, dass die Interventionen des Produktmanagers anders motiviert sein müssen: Nicht das tölpelhafte Mitmischen auf gleicher Augenhöhe, sondern das Zusammenführen und Erheben der besten Ansätze muss im Mittelpunkt seiner Arbeit stehen. Diese integrative Leistung kann nur jemand erbringen, der genügend Abstraktionsfähigkeit und Standhaftigkeit besitzt, um die Attraktivität lokaler Ziele nicht mit der Attraktivität des Gesamtproduktes zu verwechseln.
Wenn das aber gelingt, dann ensteht etwas, wie wir es fast nur noch von handwerklichen Gewerben wie Schuh-, Uhrenmachern oder Juwelieren kennen: Produkte, die wie aus einer Hand gegossen sind, weil sie die Signatur ihres Urhebers tragen. Und deshalb auch einzigartig sind.

Führung ja, nein, jein?

Das Thema Führung hat in Unternehmen und Organisationen in den letzten Jahren eine erstaunliche und erfreuliche (scheinbare?) Renaissance erfahren. Man scheint auf breiter Basis erkannt zu haben, dass Führung – und ebenso Hierarchien – zentrale Elemente sozialer Systeme sind. Viele Dynamiken der vergangenen Jahrzehnte, wie Globalisierung, neue Technologien und vor allem die Herausforderungen permanenter und schneller Change-Prozesse, verlangen nach Orientierung, Sicherheit und Entscheidungen – also Führung. Was allerdings häufig noch fehlt: diese Erkenntnis auch stringent in die Unternehmenspraxis umzusetzen. Denn das heißt schlicht: Aufwand, Zeit und Kosten.
Reinhard K. Sprenger ist überzeugt, „dass die Aufgaben von Führung Universalien sind…“ („Radikal führen“ Campus Verlag 2013). Damit ist gemeint, dass Führung ein gegebenes, natürliches und unverzichtbares Element für Unternehmen ist. Dem ist uneingeschränkt zuzustimmen. Es kann also in diesem Sinne nicht mehr darum gehen, das Führen als Funktion und Rolle in Frage zu stellen, sondern darum, wie Führung ihre Aufgaben wirkungsvoll und effektiv erbringen kann. Zweifellos kostet schwache oder dysfunktionale Führung viele Unternehmen jährlich eine Milliardensumme. Ablesbar ist das u.a. an mangelnder Leistung, zahlreichen Krankenständen, Konflikten und hoher Fluktuation.
Führung ist zum einen das gezielte Gestalten von Interaktionen zwischen Führenden und Geführten (Mitarbeiterführung) und zum anderen das Steuern und Managen der Organisation (Unternehmensführung), beides meist in einer Rolle. Es braucht auf der einen Seite Führungspersönlichkeiten mit Ausstrahlung, sozialen Kompetenzen und Freude an der Führungsrolle. Auf der anderen Seite professionelle Werkzeuge und Instrumente zur Umsetzung in die Führungspraxis. Sache ist also, dass jedes Unternehmen höchsten Wert auf die Auswahl, Ausbildung und Pflege ihrer Führungsmannschaft legen muss. Und zwar nicht als Alibifunktion, um etwas getan zu haben, sondern als hoch priorisiertes, strukturiertes und nachhaltig umgesetztes strategisches Kernanliegen.
Dies gilt genauso, oder gerade, für laterale Führungsrollen, also Führung ohne disziplinarisches Mandat. ScrumMaster, Product Owner, Projektleiter, Teamkoordinator, Supervisor, Arbeitsplatzsteurer, oder wie immer sie auch fantasievoll tituliert werden, findet man immer häufiger in lateraler Führungsverantwortung. Gerade diese, oft neu definierten Rollen, haben meist eine ungünstige Ausgangssituation. Zum einen wird ihnen jede Menge Verantwortung übertragen und zugeschoben, zum anderen fehlt ihnen aber die echte Legitimation, gezielte Ausbildung und Weiterentwicklung und vor allem Unterstützung von oben. Ist die disziplinarische Führung schwach, zu wenig präsent, sich ihrer Unterstützungsfunktion nicht ausreichend bewusst, geraten die lateralen Funktionen in eine schwer lösbare Sandwichsituation. Im Scrum-Kontext wird das dann auch noch mit dem „Prinzip der Selbstorganisation“ verbrämt. So kann man die wertvollsten Mitarbeiter mittelfristig frustrieren oder gar ausbrennen.
Konsequenz für das Unternehmen – siehe oben: Führung als strategisches Kernanliegen betrachten, HR-Abteilungen stark machen und entsprechend investieren.
Konsequenz für betroffene Führungskräfte, insbesondere in lateraler Position: offensiv Legitimation von oben fordern und transparent machen, entsprechende Weiterbildungsmöglichkeiten nutzen und vor allem dazu stehen, dass ihre Führungsfunktion für Teams und Unternehmen elementar ist und ein genuiner Teil von Selbstorganisation.
Tipp: Die eigene Führungskraft stärken – mit dem Wissen aus den Scrum Supplements

Die Kraft der Unzufriedenheit

Auf dem Weg zur Agilität haben wir glücklicherweise immer wieder mit den Widrigkeiten eingekrusteter Strukturen, langen, scope-fixen Releases, dem magischen Dreieck etc. zu tun. Releaseplanungen und Backlog Groomings unter diesen Bedingungen durchzuführen, macht besonders viel Spaß. Man muss nämlich das Beste draus machen und gleichzeitig versuchen, den nächsten Schritt Richtung Produktorientierung zu gehen.
Was es für einen Sinn macht, Backlog Groomings, Releaseplanungs-Meetings zu veranstalten und ein gemeinsames Releaseboard zu pflegen?
Im besten Fall halten die Teilnehmer der Meetings diese irgendwann für so sinnlos und nervig, dass sie selbst anfangen, sich Gedanken darüber zu machen, wie man die Zeit sinnvoller gestalten kann. Wichtig dabei ist aber, dass man sie nicht aus der Pflicht entlässt, dass sie die Zeit gemeinsam gestalten müssen.
Bei einem unserer Kunden haben wir damit angefangen, dass alle Teams im skalierten Umfeld ihre Backlogs teamweise für die nächsten drei Sprints auf Story-Ebene auf einem riesigen Board plakatierten. Alle zwei Wochen veranstalteten wir Meetings, in denen die jeweiligen POs die Stories vorstellten, an denen ihr Team in den nächsten drei Sprints arbeiten würde. So weit im Voraus sollte das Backlog ja einen recht stabilen Stand haben. Um diese Planung machen zu können, hatten die POs aber im Vorfeld die Aufträge schon in mehr oder weniger technische Arbeitspakete geschnitten und auf die Teams/Komponenten aufgeteilt. Im Meeting selbst wurden also keine Abhängigkeiten mehr entdeckt und bei der Vorstellung der User Stories für die nächsten drei Sprints schliefen die POs entweder aus Höflichkeit oder weil wir vor dem Board standen nicht ein.
Zuerst wurde viel über das Meeting gemeckert. Es würde nichts bringen, man würde ja eh auf die anderen POs zugehen, wenn man etwas von ihnen bräuchte. Außerdem sei es zu aufwendig, die Stories auszudrucken und aufzuhängen… Als klar wurde, dass wir das Meeting trotzdem beibehalten würden, wählten sie eine andere Strategie. Statt meckern: besser machen.
Anstatt schon vorab alles zu klären und auf die Teams zuzuordnen, will man nun versuchen, die unterschiedlichen Themen mit initialen User Stories in der Priorität des Company Backlogs abzubilden. Das Meeting kann dann dazu dienen sich bewusst zu machen, welche Aktivitäten nötig sind, um das Thema abzuschließen. Außerdem kann sofort gesehen werden, ob an den richtigen Prozessen gearbeitet wird bzw. ob sich ausreichend Teams aus den oberen Themen Stories ziehen. Die Endlichkeit der Wand führt außerdem automatisch zu einer Fokussierung. Es finden vielleicht gar nicht alle Themen Platz. Die wichtigsten können aber aufgehängt werden. Merkt man, dass die kleinen Stories für die Top-Themen ausgehen, kann man in kleineren Gruppen die Detaillierung durchführen. Burndown-Charts auf Themen-Ebene werden möglich. Die nächste Stufe könnte sein, nicht mehr Themen abzubilden, sondern vielleicht die Kernprozesse im Backlog zu haben, an denen Änderungen gemacht werden. Die Priorität richtet sich dann evtl. danach, welcher Prozess am wichtigsten für das Business ist, oder wo die größten Einsparungen realisiert werden können.
Sind das Meetings und Artefakte wie sie im Buche stehen? Sicher nicht, aber es sind Mittel, die dem PO-Team helfen, den Überblick zu behalten und anderen zu geben.
Welche Möglichkeiten habt ihr durch Unzufriedenheit mit dem Status quo gefunden?

Von der Projektkultur zur Produktkultur

Ihr seid vielleicht damit beschäftigt, eure Entwicklung effizienter zu machen bzw. eure Produktivität oder Qualität zu steigern. Aber die Frage, wie man richtig, schnell oder gut liefern kann, sollte nicht die einzige Frage sein, die uns bewegt. Zentral ist die Frage, ob wir das Richtige tun, ob wir richtig auf den Kundenbedarf antworten. Mit anderen Worten: Was bedeutet es, eine Produktorganisation zu sein? Wie sieht es mit eurer Produktkultur aus?
Die Einführung von Scrum wird oft von der IT-Abteilung initiiert, der historisch eine typische Haltung als Dienstleister oder Support-Abteilung zukommt. In einer solchen Organisation ist das Produktmanagement im besten Fall eine separate Abteilung (ein weiterer Silo), deren Schwerpunkt u.a. auf Marketing, Innovation oder Business Development liegt. Leider ist diese Abteilung oft sehr weit von der IT entfernt. Im schlimmsten Fall gibt es überhaupt keine Produktmanagementkultur, sondern eine reine Projektmanagementkultur. Die Gründe dafür, warum die Entscheidung auf ein bestimmtes Projekt/eine bestimmte Produktentwicklung fällt, sind nicht transparent bzw. nicht jedem bekannt.
Meistens sind solche Entscheidungen meinungsgetrieben (Kostenanalyse, Vorstandsprojekt, Lenkungsausschuss, etc.) und selten datengetrieben (Marktentwicklung, Kundenbedarf, Wertschöpfung, Outcome, etc.). In Unternehmen mit reifen Portfolios sammeln “Produktmanager” Anforderungen aus dem Verkauf oder dem Kundenmanagement und beschränken sich auf die Aufgabe des Ressourcenmanagements. Die Produktentwicklung wird nach den verfügbaren Ressourcen priorisiert.
Auch die agile Transition wird oft von der IT-Abteilung vorangetrieben – also von einer Abteilung, die von Produktentwicklung keine Ahnung hat, weil sie über Jahrzehnte in die Rolle des Umsetzers und Dienstleisters gedrängt wurde. Deswegen konnten sich auch kaum die nötigen Kompetenzen oder das passende Mindset entwickeln. Zwar kann sich die IT dann darin verbessern, das Produkt richtig zu liefern, aber gleichzeitig weit davon entfernt sein, das Richtige zu liefern. Also wird auch der Unternehmenserfolg nicht in dem Ausmaß vorangetrieben, in dem er vorangetrieben werden könnte.
Wenn eine agile Organisation eine kundenorientierte Organisation ist, dann bedeutet das eigentlich, eine Produktorganisation aufzubauen. Es bedeutet also, eine Produktkultur einzuführen. Es bedeutet, ständig nachvollziehen zu können, ob der Kunde mit den Produkten zufrieden ist, ob neue Produkte vom Kunden angenommen werden und ob das Unternehmen damit Erfolg hat. Der Aufbau der agilen Organisation/die agile Transition sollte daher aus Produktsicht getriggert, gewünscht und geführt werden. Kundenbedarf, Wert für den Kunden, User Experience und Unternehmenserfolg: Das ist letztendlich die Sprache, die gelernt werden muss.
Wenn ich mir meine bisherigen Scrum-Implementierungen durch den Kopf gehen lasse und mir die Wege dieser Unternehmen zur agilen Organisation ansehe, sehe ich immer den Product Owner bzw. die Produktorganisation als wichtigen Knotenpunkt. Die Einbettung der Agile Delivery in eine Produktkultur ist für die Zukunft eines Unternehmens entscheidend:

Daher habe ich eine Bitte: Unterstützt eure Product Owner dabei, echte Produktmanager zu werden! Denkt von Anfang an daran, dass das Produktmanagement kein isolierter Silo sein darf, sondern eine Funktion und sogar ein Mindset sein muss, das alle im Unternehmen betrifft!

Das Review als Nicht-Meeting

Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:

Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?

Die KITA-Bewohner spielen wieder!

Sieben frisch aufgesetzte Scrum-Teams arbeiten derzeit eine klassische Releasebeauftragung eines halben Jahres ab. Mitten im Release ging der Überblick darüber verloren, was tatsächlich schon ausgeliefert worden war, was bereits fertig entwickelt war und auf den Releasewechsel wartete und was noch zu tun war. Jedes Team für sich konnte dazu zwar Auskunft geben, aber die Zuordnung zum Company Backlog war mehr als schwierig aus den elektronischen Tools, aber auch vom Releaseboard abzulesen.
Dort sah man zwar ca. 100 Stories und Epics, allerdings konnte man nicht erkennen, was zu welchem Item aus dem Company Backlog beitrug bzw. ob es überhaupt im Company Backlog auftauchte. Die klassische Beschriftung mit Zahlen brachte uns leider auch kein Stück weiter. Also gingen wir auf Textmarker-Jagd, um möglichst viele unterschiedliche Farben zu ergattern. Als wir mit dem ersten Product Owner anfingen, die Stories aus seinem Backlog den unterschiedlichen Company Backlog Items zuzuordnen, gingen uns aber zu schnell die Farben aus. Was in der Theorie so schön aussieht, war bei uns im aktuellen Release absolute Theorie und hatte nichts mit dem tatsächlichen Releaseboard zu tun.
Nach kurzer Ratlosigkeit kam ein ScrumMaster auf die Idee, nicht nur Farben, sondern zusätzlich Symbole einzuführen. Ich gebe zu, ein Workaround! Wir sind einfach noch nicht bei thematischen Releases.
Aber immerhin half uns dieses Vorgehen zu identifizieren, was im Company Backlog alles fehlte und bei welchem der hoch priorisierten Epics im Backlog die Arbeit noch nicht mal gestartet worden war. Außerdem hatte es den schönen Nebeneffekt, dass sich die POs selbst Symbole und Farben aussuchen durften, mit denen sie ihre Stories kennzeichneten. Ich freue mich schon, wenn wir im Grooming demnächst über das Sonnenepic sprechen 😉
Da die Visualisierung initial einiges an Zeit beanspruchte, bekamen wir von den Büro-Bewohnern in unmittelbarer Umgebung des Releaseplans bei jeder Gelegenheit zu hören: “Ach, die KITA-Bewohner spielen wieder.” Für mich war es toll zu sehen, wie das Arbeiten an den Wänden, auf dem Boden und im Stehen zu sehr viel Interaktion und Aktion führte. Stifte wurden hin und her geworfen, über blöd gemalte Symbole gelacht, sich gegenseitig beim schnellen Ausmalen geholfen…
Meine Hypothese, warum es funktioniert hat? Weil es einfach war und jeder sofort mitmachen konnte!
Und trotzdem: Wir haben zwar jetzt eine Zuordnung der “User Stories” und Aufgaben zu einer übergeordneten Liste. Ein Company Backlog ist das allerdings noch nicht. Ein rhythmisches Liefern erst recht nicht! Es hat aber deutlich gemacht, dass wir etwas ändern müssen, wenn wir anfangen wollen, gemeinsam zu liefern!

Warum überhaupt schätzen?

Schätzen bedeutet für viele Menschen Stress. Wie sollte es auch anders sein? Solange Schätzungen herangezogen werden, um das Fertigstellungsdatum festzulegen, wird es ein abgekartetes Spiel bleiben. Die einen wollen ein tolles Produkt liefern und versuchen daher, durch möglichst großzügige Angaben und dem Einschieben von vielen Pufferzonen ihre Freiheit zu erkaufen. Die anderen wollen den Kunden behalten, haben ihm vielleicht sogar schon Zusagen gemacht, und versuchen daher, die Zeit bis zur Auslieferung maximal zu reduzieren.
Natürlich ist die Spannung beiden Seiten bekannt – und so versucht jeder, das Spiel mit möglichst wenig Kompromissen zu überstehen. Das Spiel kostet üblicherweise viel Zeit und Nerven, und führt letztendlich zu lokalen Optimierungsstrategien: Hier die Strategie, das beste Produkt zu entwickeln. Dort die Strategie, den besten Marktwert für das Produkt zu erzielen. Das Gesamtergebnis muss suboptimal bleiben, weil jede Strategie eigensinning arbeitet, ohne die andere wirklich miteinzubeziehen.
Angesichts dessen haben wir zwei Möglichkeiten: Das Schätzen komplett sein zu lassen und dem Kunden nur noch das zu versprechen, was in den nächsten Iterationen jeweils fertig gestellt werden kann. Vorteil: Der Kunde zahlt für genau das, was er bekommt. Und er kann nach jeder Iteration entscheiden, ob er noch mehr braucht. Dadurch spart er sich den Aufwand und die Schleierhaftigkeit, die mit allen großen Spezifikationskatalogen einhergehen. Nachteil: Nicht jeder Kunde möchte so arbeiten.
Die zweite Möglichkeit besteht darin, das Schätzen komplett umzudeuten. Wir machen das so: Anstatt die Entwicklungsmannschaft nach dem Fertigstellungsdatum zu fragen, lassen wir sie mit dem Product Owner über das Produkt reden. Geht es zum Beispiel darum, ein neues Suchfeld zu implementieren, wird nicht über Aufwand für Entwicklung und Testen gesprochen, sondern um die Funktionalitäten dieses neuen Suchfelds.
Die Entwicklungsmannschaft fragt dann den Product Owner, was dieses Suchfeld leisten soll: Nach welchen Kriterien Anfragen durchgeführt werden sollen, in welcher Reihenfolge und Form die Ergebnisse angezeigt werden sollen, und so weiter. Aus solchen Gesprächen entwickelt sich ein gemeinsames Verständnis für das Produkt. Das Team wird in die Lage versetzt, die noch verbleibende Arbeit nach ihrem funktionalen Umfang zu schätzen.
Und damit ist auch die Brücke zwischen Entwicklung und Markt geschlagen: Der Product Owner, der nach einigen Sprints weiß, wie viel Funktionsumfang sein Team im historischen Durchschnitt pro Sprint liefern kann, kann nun zum Kunden gehen und ihm anhand seines priorisierten Backlogs erklären, welche Funktionalitäten er wann erwarten kann (Kristina Kleßmann hat hier eine anschauliche Beschreibung zum Schätzen nach Funktionalität geschrieben).

Eine große Umstellung

Das Schätzen nach Funktionalität bedeutet für viele eine große Umstellung. Wir alle sind es gewohnt, nach Aufwand zu schätzen. Ein Entwicklungsteam möchte möglichst früh klären, was alles zu tun ist, um eine neue Produkteigenschaft zu implementieren. Zudem wird beim Schätzen nach Funktionalität schnell deutlich, wenn keine Weiterentwicklung stattfindet. Konzeptstories (auch “Spikes” genannt) liefern genau so wenig Produktivität wie technische Aufgaben und solche, die “nur” auf ein Redesign einer bestehenden Funktionalität abzielen. Im “schlimmsten” Falle heißt das dann: Das Team hat über mehrere Sprints keinen funktionalen Mehrwert geliefert. Für viele Teams ist das ein echtes Problem – vor allem dann, wenn das Management sie an ihrer Velocity (also dem Durchsatz an Funktionalitäten pro Sprint misst). Sie schätzen dann lieber nach Aufwand oder Komplexität (oder einer alchemistisch anmutenden Mischung aus beiden), um dem Unternehmen zu zeigen: Schaut her, wir machen unsere Arbeit.
Und so ist es in Scrum häufig wie beim Arztbesuch. Keiner steht gerne im Unterwäsche vor dem Mensch im weißen Kittel, um sich auf Herz und Nieren prüfen zu lassen. Trotzdem ist es wichtig, sich ab und an die Blöße zu geben. Zu erkennen, dass es hier und da nicht so gut läuft. Dass kein Kunde der Welt wirklich bereit ist, für Konzepte oder Generalüberholungen zu zahlen. Dass ein Unternehmen es nicht mehr schafft, seine Produkte weiter zu entwickeln, sondern an Bestehendem herumdoktert.
Entscheidend ist dabei, wie ein Unternehmen mit dieser Erkenntnis umgeht. Wie geht es Mitarbeitern, die solche Defizite offen ansprechen? Werden sie ernstgenommen und anerkannt, oder eher sachte beiseite geschoben und am Ende des Tages ignoriert? Und selbst wenn es ein Problembewusstsein gibt: Führt das im Unternehmen zu Hilflosigkeit und Frustration oder raufen sich alle zusammen, um einen Schlachtplan zu entwerfen? Teams spüren sehr genau, wie ihr Unternehmen tickt, welche “Persönlichkeit” es hat. In einem Unternehmen, das am liebsten gut dastehen möchte, wird die Offenheit, die mit dem Schätzen nach Produktivität einhergeht, keine guten Chancen haben. Das heißt aber nicht, dass die Methode die falsche ist. Es zeigt nur, dass sie nicht zum Selbstverständnis des Unternehmens passt.
Siehe auch: Martin Fowler: Purpose of Estimation

Gedanken eines frisch gebackenen Product Owners

Wahrscheinlich ist es meine Verantwortung für den ROI, die mich immer wieder dazu verleitet, die Priorisierung einzig und allein vom Wert der User Story in Euro und Cent, also dem originären Business Value ableiten zu wollen. Doch der Versuch, einen absoluten Wert hinter die Story zu schreiben, den der Kunde im Endeffekt sicher bezahlen wird, lässt mir eher graue Haare wachsen als ein priorisiertes Backlog gedeihen.
Denn machen wir uns doch nichts vor: Das, was ich hier im Backlog formuliere, sind Hypothesen. Wenn der Kunde noch nichtmal weiß, dass er das bald unbedingt haben will, weiß er doch auch heute noch nicht, wie viel er dafür zu bezahlen bereit sein wird. Ok, das Risiko bleibt also mal wieder an mir hängen. Ich muss mir sicher sein, dass meine Hypothese so gut ist, dass es sich lohnt, die Jungs und Mädels ein paar Tage dran zu setzen.
Auf der anderen Seite: Zu den Zeiten, in denen mir der Kunde vorgegeben hat, was er als Nächstes haben möchte und auch gleichzeitig den Preis mitgeliefert hat, möchte ich auch nicht zurück. Ok, also erstmal keine Euros … aber wie komme ich dann zu meiner Priorisierung? Irgendjemand hat mir mal gesagt, dass Scrum viel mit Menschenverstand zu tun hat … also …
Bauchgefühl? 
Hm, hat zwar weniger mit Verstand zu tun, aber dafür habe ich davon eine ganze Menge 🙂 Aber reicht das? Ich hätte da lieber was, mit dem ich die Komplexität zumindest scheinbar etwas greifbarer machen kann.
Was könnte greifbarer sein als die gute alte Deadline? Verliert ein Feature seinen Wert oder wird er erheblich verringert, wenn ich es erst nach der bestimmten Deadline auf den Markt bringe? Oder schlimmer noch: Muss ich vielleicht sogar mit einer Strafe rechnen, wenn ich das Feature nicht rechtzeitig zur Verfügung stelle? Klingt nach zwei guten Kategorien.
Wen muss ich denn mit dem Produkt beglücken? Gibt es Stakeholder, die ich vorrangig zufrieden stellen muss und oder kann ich einzelne Stories bestimmten Themen zuordnen, die als Gesamtpaket unterschiedlich wertvoll oder wichtig für das Produkt sind?
Da wir mit Scrum auch endlich mal unsere Systeme in den Griff bekommen wollen, könnte ich mir natürlich auch genau die Stories raussuchen, die die meisten Systeme gleichzeitig anfassen. Oder die Stories, die sich erstmal mit dem zentralen Sorgenkind beschäftigen. So können wir möglichst schnell identifizieren, wo die größten Probleme liegen. Apropos Probleme – was ist eigentlich mit Risiken? Könnte in die Kategorie Systemarchitektur fallen, aber auch der auslaufende Vertrag mit dem Zulieferer könnte zu einem Risiko werden, wenn wir noch vorher die entsprechende Unabhängigkeit der Daten sicherstellen.
Da fällt mir die Kooperation mit der Uni ein. Die haben bestimmte Vorlaufzeiten, damit sie die Studenten auftreiben können.
Puh, was könnte noch eine Rolle spielen?
Naja, wir hatten uns ja bei der Ausrichtung des Produktes damals so viele Gedanken gemacht, was es eigentlich für die Firma bringen soll. Vielleicht kann ich bewerten, wie gut das Feature dieses Ziel unterstützt? Falls mir das noch nicht reicht, könnte ich eine Kombination mit Methoden wie z. B. MuSCoW oder Kano versuchen:
MuSCoW: Must – Should – Could – Won’t
Kano: Basis-, Leistungs-, Begeisterungs- und Zurückweisungs-Merkmale!  
Ok, bevor ich das alles ausprobiere, erstmal zum PO Weekly. Immerhin gibt es auch noch die Abhängigkeiten zu den anderen Teams, die Einfluss auf meine Prio nehmen könnten. Und jetzt, wo wir so viele neue Scrum-Teams haben, könnten wir doch eigentlich eine übergreifende Priorisierung vornehmen und dabei die gleichen Kriterien anwenden. Mal sehen wie die anderen es machen – bekanntlich ist es ja einfacher, wenn man ab und zu die Köpfe im Team zusammensteckt.
Wir könnten im PO Team einfach mal aufschreiben, wer wie priorisiert und sehen, wo die Gemeinsamkeiten und Unterschiede sind und welchen Nutzen die einzelnen Aspekte für den jeweiligen PO haben. Macht es Sinn, dass wir die gleichen Kriterien anwenden und was verstehen wir eigentlich genau darunter? Und wahrscheinlich hat mein ScrumMaster auch noch ein paar Ideen und kann mir bei der Fülle der Möglichkeiten für die Priorisierung helfen … Aber wahrscheinlich wird er am Ende wieder sagen: “Triff einfach eine Entscheidung!” Product Owner sein heißt Entscheidungen treffen, und die trifft man per Definition unter Unsicherheit! Man muss es trotzdem tun und vor allem dazu stehen.

Am Ende eines langen Tages

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.
Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.
Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.
Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):
“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”
Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.
Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.
Drei Vorschläge:

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html
Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Warnhinweis: Produkte entstehen nicht von selbst

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.
 
All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.
 
Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem “Wozu” wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.
 
Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.
Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.
Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.
 
In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.
 
An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

  • Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
  • Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
  • Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
  • Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen “Elevator Pitch” zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.
 
Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.
Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.
Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.
Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

“Limit work in progress” – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.
Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.
Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.
Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.
Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.
Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: “Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?”
Paul Graham nannte 2009 die unterschiedlichen Zeitpläne “Maker’s schedule, manager’s schedule“. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. “Wenn Sie mich fragen: Ich mag ihn, den Sprint!”

Sie können abschalten, wir haben die Vision

Was sagt die Hirnforschung zum Nutzen von (Produkt-)Visionen? Ich bin daran höchst interessiert, aber ich weiß es nicht. Was ich allerdings weiß, ist Folgendes:
In der Hirnforschung gibt es einen Bereich, der sich mit Improvisation beschäftigt. Improvisation ist ein kreativer Prozess, Jazz ist dafür ein gutes Beispiel. Wir wissen, dieser Musikstil lebt von Improvisation. Misst man die Gehirnaktivität bei der Improvisation, dann stellt man etwas Spannendes fest: Entgegen der ersten Annahme, dass ein Feuerwerk der Aktivität im Hirn veranstaltet wird, schaltet das Hirn bestimmte Teile stark ab. Klar sind die Teile des Hirns, die für das Hören zuständig sind, sehr aktiv. Aber der frontale Teil des Hirns  (Frontallappen) schaltet sich bewusst weitgehend ab. Genauer gesagt schaltet sich der planerische Teil des Hirns ab – also der Teil, der weiß, was als Nächstes getan wird, der den Schritt nach dem Schritt kennt. Aktiv bleibt allerdings der Teil, der sich den langfristigen Zielen oder Rahmen widmet. Im Jazz wären das dann die kulturellen Grenzen der jeweiligen Zeit (Zeitgeist) und die damit verbundenen Muster.

Zu welcher Schlussfolgerung bringt mich das?

Wenn wir davon ausgehen müssen, dass wir für kreatives Handeln wie bspw. Improvisation sowohl 1.) einen Rahmen zur Orientierung brauchen und wenn 2.) kreative Prozesse planerisches Handeln ausschalten, dann bringt mich das zu Folgendem:
Planen und kreatives Handeln stehen für unser Hirn im Konflikt. Immer wenn wir Neues erschaffen, benötigen wir einen Rahmen, eine Orientierung, eine Marschrichtung, eine langfristig angelegte Mission oder Vision. An dieser Vision richten wir uns aus und im Rahmen der Orientierung können wir kreativ handeln. Den zu genauen Plan schiebt unser Hirn beiseite (sobald wir etwas Neues erschaffen müssen). Der Plan im Vorfeld ist nicht wichtig und kann nicht beachtet werden. Ausgehend von einem sehr groben Zielbild, einer Vision, die als Rahmen dient, orientiert sich unser Hirn an langfristigen Zielen. Diese Ziele müssen bekannt sein und grob vorliegen. In der Agilität schaffen wir eine Vision, arbeiten mit User Stories und in Scrum mit Sprint Goals. Alle drei Artefakte folgen dem groben Rahmen und vermeiden das detailreiche Planen. Könnte unser Hirn die Grundlage für den Erfolg dieser Artefakte sein?
Ob ich damit richtig liege, ich weiß es nicht. Ist es wichtig? Ich denke, nein. Wichtig ist jedoch zu wissen, dass Kreativität viel mit Kontrolle des Hirns über das Abschalten von Hirnaktivität zu tun hat und dass zuviel Detailplanung in kreativen Prozessen teilweise nicht berücksichtigt wird und unnötig ist – zumindest dann, wenn wir einen erneuten kreativen Prozess starten. Vielleicht noch ein belehrender Hinweis zum Schluss: Immer wenn wir neue Anforderungen für unser Produkt angehen, immer dann, wenn wir Software in Schale gießen, dann starten wir einen solchen kreativen Prozess.
Bevor Sie jetzt abschalten, noch eine Frage: “Wie ordnen sich meine obigen Gedanken zu ‘Front-Up-Design’ und zu ‘Emergent-Design’ ein?”

Wie viel bin ich wert? Die Geschichte einer User Story

Am Anfang war das Nichts und es war dunkel. Und mit einem Mal blitzte es kurz auf, es ward Licht im Geiste und ich entstand als eine assoziierte Idee. Und meine Erzeugerin sprach: „Ja, jetzt hab ich‘s“ und schuf mich auf einer kleinen, weißen Welt. Ich glaube, meine Welt war eine Scheibe. Jedenfalls war sie äußerst flach. Im Laufe der Zeit veränderte mich meine Erzeugerin noch an der einen und anderen Stelle. Teile von mir wurden durchgestrichen, Teile von mir wuchsen neu aus mir heraus.
 
Meine Erzeugerin war stolz auf mich und zeigte mich den anderen Göttern. Diese begannen sofort, über mich zu sprechen, meine Sinnhaftigkeit zu hinterfragen. Wie groß und komplex ich sei. Und dass ich in meiner jetzigen Form gar nicht umzusetzen sei. Zu aufgebläht sei ich und viel zu viele Abhängigkeiten hätte ich an mir haften. Die anderen Götter wollten mich halbieren und in kleine Stücke zerschneiden, denn ich sei eine Dreizehn!
 

Meine Erzeugerin gebot Einhalt und sprach:
„Nur im Ganzen kann ich sie brauchen. In kleinen Teilen nützt sie mir nichts!”

 
Die Götter aber ermahnten meine Erzeugerin und sprachen: „Dann sag uns, wie wertvoll sie für dich ist!“
Meine Erzeugerin antwortete beschämt: „Das kann ich nicht. Ich weiß nicht, wie viel sie wert ist. Aber sie ist wichtig, wir müssen sie umsetzen.“
 
Die Götter aber riefen voller Zorn: „Alles, was du uns bringt, ist wichtig und muss umgesetzt werden! Nenne uns ihren Wert, sonst werden wir sie in kleine Stücke hacken und einzeln umsetzen!“
Meine Erzeugerin nahm mich mit zu ihren Brüdern und Schwestern und fragte diese nach meinem Wert. Die anderen Erzeuger aber sprachen: „Wir wissen nichts über ihren Wert. Alles, was wir erzeugen, ist wichtig und dringend und muss umgesetzt werden.“
 
So wurde ich schließlich in einen Stapel gesteckt und zwischen anderen Welten meiner Art eingequetscht. Ich verlor das Bewusstsein kurz nachdem ich die Götter sagen hörte, ich sei wohl doch eher eine Vierzig. Als ich nach langer Zeit wieder erwachte, fand ich mich selbst wieder – gewandelt in eine Funktionalität. Seit langer Zeit warte ich nun darauf, dass ich endlich von jemandem benötigt und ausgeführt werde. Ich gebe die Hoffnung nicht auf, schließlich war ich doch so wichtig …
 
 
Die Moral dieser Geschichte ist ganz einfach. Product Owner dieser Welt, denkt über Business Value nach und gebt Euren User Stories einen ernsthaften, echten Wert mit auf den Weg!
 
Stories mit Business Value werden Euch helfen, Euer Backlog in eine priorisierte Ordnung zu bringen. Und sie werden die Kommunikation zwischen dem Team und Euch auf eine neue, ganz andere Ebene heben!
Das mag vielversprechend und beinahe zu schön klingen. Auf die Spitze getrieben möchte ich es folgendermaßen formulieren: Macht Euch und Eurem Team ein schönes und bequemes Leben, denn ohne Business Value habt Ihr die völlige Freiheit, tun und lassen zu können, was Ihr gerade gerne möchtet.
 
“Ich mache mir immer wieder Vorwürfe, dass meine Malerei nicht wert ist, was sie kostet.”
Vincent van Gogh
 
“Meist belehrt erst der Verlust über den Wert der Dinge.”
Arthur Schopenhauer

Der Kunde ist König, der Product Owner Kaiser

Warum verschwinden Unternehmen vom Markt? Weil sie zu sehr auf ihre Kunden hören. Das ist zumindest die These von Clayton M. Christensen in The Innovator’s Dilemma.
 
Moment mal: Wie kann das sein? Bekommen wir nicht überall gesagt, dass ein zufriedener Kunde das A und O für erfolgreiche Geschäfte ist? Dass man den Kunden gar nicht genug in die Produktentwicklung einbinden kann? Wie passt das zusammen?
 
Christensen hat sich die Geschichte der Festplattenentwicklung angeschaut. Seine These: Festplatten-Herstellern wie Digital, Seagate und IBM hat es nie an Innovationskraft oder Kundennähe gemangelt. Im Gegenteil: Ihre Festplatten wurden von Jahr zu Jahr schneller, günstiger und boten mehr und mehr Speicher. Und das in einem Tempo, das den Bedarf der Kunden zufrieden stellte. Eigentlich lief also alles gut. Doch genau in solchen Erfolgsmomenten, in denen Unternehmen scheinbar alles richtig machen, kann laut Christensen der Anfang vom Ende keimen. Andere Unternehmen kommen mit einer Lösung auf den Markt, die einen Bruch mit allem bisherigen darstellt: Bei den Festplatten war das der Bau kleinerer Festplatten. Das Problem war nicht, dass die Platzhirsche das nicht hätten bauen können – zum Teil hatten sie sogar schon Prototypen auf Lager. Nur: Keiner konnte etwas damit anfangen – am wenigsten der Kunde. Denn die kleineren Festplatten waren nur ein wenig günstiger, dafür hatten sie aber deutlich weniger Speicherplatz und waren notorisch langsamer. Die etablierten Unternehmen bauten die Festplatten für große Mainframe-Rechner – und dort gab es zunächst keinen Bedarf für kleinere Festplatten. Diese fanden dann in Mini-Computern und später (in noch kleinerer Form) in Desktop-Computern und Laptops Verwendungen. Erst nachdem sie sich dort – in einem alternativen, kleinen, heranwachsenden Markt – etabliert hatten, traten sie den Siegeszug an: Die kleinen Festplatten wurden immer leistungsfähiger und verdrängten schließlich den größeren Bruder komplett vom Markt. Zu dem Zeitpunkt war es für die Platzhirschen zu spät, um noch aufzuholen.

Nein!

Kennst du Menschen, die immer versuchen, es ihren Freunden recht zu machen? Die kritische Worte schwer über die Lippen bekommen und ganz selten deutlich “Nein” sagen? Vielleicht sind viele Unternehmen genau so gestrickt. Ein zufriedener Kunde ist schließlich ein zahlender Kunde. Da mag es schwer fallen, den Kunden mal nicht als König zu betrachten und bewusst einen ganz anderen Weg einzuschlagen, der zunächst nur wenige (und andere) Kunden verspricht. Die Hersteller größerer Festplatten bauten für wenige Großkunden und hatten entsprechend hohe Betreuungs- und Verkaufskosten, die wiederum durch Gewinnmargen kompensiert wurden. Bei den kleineren Festplatten sah das Geschäftsmodell ganz anders aus: Billige Komponenten, große Stückzahlen, einfache Verkaufskanäle und geringe Margen. Es ging also nicht nur darum, ein anderes Produkt zu bauen. Es geht vielmehr darum, das eigene Geschäftsmodell in Frage zu stellen.
 
Agile Teams haben bisweilen den Kunden als Product Owner. Das ist praktisch, denn der Kunde kann dem Entwicklungsteam genau sagen, was er will. Und wenn er das bekommt, was er will, dann ist das Unternehmen ja auch erfolgreich. Richtig? Nun ja, genau das haben wir eben exemplarisch in Frage gestellt. Wir haben gesehen, dass ein Kunde heute ganz andere Bedürfnisse haben kann als morgen. Und dass er von seinen zukünftigen Bedürfnisse bisweilen keine Ahnung hat. Aus der Perspektive kann es nicht schaden, wenn ein Product Owner sich eine gewisse Unabhängigkeit vom Kunden bewahrt und einen Schritt weiter denken kann. Nicht aus Arroganz oder Undankbarkeit, sondern aus einer gesunden Dosis Selbstvertrauen. Es ist sicherlich ein Risiko, Produkte zu lancieren, für die es noch keinen etablierten Markt gibt und vielleicht nicht geben wird (wer kann das schon im Voraus beurteilen?). Aber die Alternative – und Christensen zeigt das eindrücklich – kann bisweilen in eine tödliche Sackgasse führen.




Clayton M. Christensen: The Innovator’s Dilemma. The Revolutionary Book that Will Change the Way You Do Business.

Null-Fehler-Software

Oft wirft das Vorgehen nach Scrum ein paar Fragen und viele Diskussionen zum Thema “Umgang mit Bugs” auf. Manch einer mag sagen, dass die unten formulierten Regeln unrealistisch sind und man sie deshalb von vornherein ignorieren kann. Ich bin jedoch der Meinung, dass man sich dann daran erinnern sollte, warum man mit Scrum entwickeln will. Es gibt doch etwas, was man verändern will, sei es Time to Market reduzieren, Kundenzufriedenheit erhöhen, Qualität der Software verbessern oder oder oder … Und diese – zugegeben nicht einfach zu erreichenden – Veränderungen treten nunmal in der Regel nicht ein, wenn man so weitermacht wie bisher.
Scrum ist dabei ein Gesamtkonstrukt, das uns hilft, diese herausfordernden Ziele zu erreichen. Cherrypicking ist dabei zwar wie in allen anderen Bereichen nett, wird aber nicht die vollumfängliche Verbesserung bringen, die man sich wünscht – leider oft mit dem Fazit, dass Scrum versagt hat. Der Umgang mit Bugs ist da nur ein Beispiel von vielen.
Daher hier – ganz in der gewohnten Scrum-Manier – ein paar ganz einfache Regeln!

Bugs

Bugs werden sofort gefixt!

  1. Bugs sollten innerhalb von 24 Stunden gefixt sein! Ja, dafür muss im Zweifel ein bereits angefangener Task unterbrochen werden. Solange der Fehler nicht behoben ist, kann die Story nicht abgeschlossen werden. Das Gleiche gilt für Broken Builds, fehlgeschlagene Tests etc.
  2. Häufiger Einwand: Was ist mit Bugs, bei denen das Fixing länger dauert? Zumindest innerhalb der ersten 24 Stunden anfangen und sich dann fragen, was im Vorfeld schiefgelaufen ist.

Ein Bug ist ein Bug ist ein Bug – und damit ein FEHLER!

  1. Wir liefern fehlerfreie Software am Ende des Sprints!
  2. Keine Klassifizierungen in major oder minor oder high, medium low (notwendig). Ist es ein Bug, dann siehe Regel 1. Ist es eine neue Funktionalität –> ins Backlog priorisieren! Es werden keine Bugs zurück ins Backlog geschoben und für spätere Sprints “aufgehoben”!
  3. Häufiger Einwand: Nur Laien behaupten, dass es fehlerfreie Software gibt.
    • Mag sein, dass das Laien behaupten. Allerdings schließt das nicht aus, dass es das oberste, immer, ständig, absolut angestrebte Ziel ist, das es zu erreichen gilt. Und das sollte doch auch der Anspruch eines Teammitgliedes in einem Entwicklungsteams sein, oder? Lasst uns gute Arbeit machen und nicht Zeit mit Ausreden verschwenden!

Create a bug lane!

  1. Fügt über der Taksboard-Lane für die erste Story eine Bug Lane ein. Nehmt für Bugs eine andere Post-it-Farbe (Rot bietet sich an).
  2. Häufiger Einwand: Macht es nicht mehr Sinn, die Bugs den Stories zuzuordnen?
    • Die Arbeit in Scrum ist prioritätenbezogen: Was oben steht, wird zuerst bearbeitet. Außerdem sollte sowieso nur die oberste Story in progress sein, so dass die Zuordnung sowieso stimmt.

Das Team bekommt einmal so viel Zeit wie es braucht, um es richtig zu machen!

Calls / Hotfixes / Change Requests

Manche Teams, die auf Scrum umstellen, haben bereits produktive Systeme zu betreuen – sei es in Form von Maintenance, Calls, Hotfixes, vom Kunden entdeckte Bugs oder auch Change Requests. Dabei stellt sich immer wieder die Frage, wie man mit solchen Änderungen am besten umgeht.

Calls haben sich über Jahre angesammelt, der Überblick ist verloren gegangen? Der Call Stack kann nicht mehr abgearbeitet werden, sondern nimmt mit jedem Sprint zu?

  1. Alle Calls löschen!
  2. Mit der Einführung von Scrum sollten alle Calls gelöscht werden. Ab diesem Zeitpunkt werden alle neuen Calls konsequent sofort behoben (siehe Beschreibung oben). Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.

Kunden bezahlen einen fixen Betrag zur Wartung der Software und erwarten daher sofortige Änderungen!

  1. Der PO entscheidet über Priorisierung und Funktionalität!
  2. In diesem Fall muss oft zuerst genau definiert werden, was unter Maintenance fällt und in welchem Zeitraum diese abgearbeitet werden müssen (sofern es vertraglich festgelegt ist). Oft versucht der Kunde, neue Funktionalität und Change Requests als Maintenance einzubringen. Hier muss der PO die notwendigen Abgrenzungen und Entscheidungen treffen. Auf jeden Fall sollte Transparenz darüber geschaffen werden, wie viele Ressourcen und wie viel Zeit durch die Maintenance-Zahlungen des Kunden zur Verfügung stehen würden. Danach kann sich die Zeit richten, die das Team pro Sprint für Maintenance-Aufgaben nutzen kann (z.B. immer an den ersten oder letzten zwei Tagen eines Sprints). Hier sollte aber wieder darauf geachtet werden, dass es eine Teamleistung ist und diese timeboxed abläuft.

Der Kunde meldet Fehler im Live-System, die seine Arbeitsfähigkeit beeinträchtigen und verlangt sofortiges Hotfixing!

  1. Für den Fehler entschuldigen und sofort beheben!
  2. Halten sich diese Hotfixes im Rahmen, können sie vom Team im laufenden Sprint bearbeitet werden. Umgang wie mit neu entdeckten Fehlern (siehe oben). Nimmt das Hotfixing die gesamte Zeit in Anspruch, sollte eine grundlegende Überarbeitung angestoßen werden.

Es gibt eine überschaubare Menge an Bugs, diese können jedoch nicht in einem Sprint abgearbeitet werden. Das Team, das die Bugs fixen muss, ist nicht für die Produktion der Fehler verantwortlich.

  1. Mit dem Product Owner ein Bug-Burn-Down vereinbaren!
  2. Wie viele offene Defects gibt es und bis wann will man sie gelöst haben? Beispiel: 100 Bugs in 10 Sprints -> 10 Bugs pro Sprint werden gefixt. In der restlichen Zeit wird Funktionalität entwickelt. So schafft man einen Übergang zu einer fehlerfreien Software und bestraft das Scrum-Team nicht damit, ausschließlich die Fehler der anderen beheben zu müssen.

 
Um diesen Umgang mit Fehlern zu ermöglichen und Fehler möglichst früh zu erkennen, gehört daher das nötige Handwerkzeug zur Basisausrüstung eines Entwicklungsteams:

Erst hier ist die Entwicklungsphase abgeschlossen. Erst dann bekommt der (interne oder externe) Kunde die Software.

Und immer dran denken: weniger diskutieren, mehr fixen (Zwinkern)


Am Ende wird alles gut oder warum Lieferungen ständig mit heißer Nadel gestrickt sind

Der aktuelle Sprint neigt sich dem Ende zu. Es ist Reviewtag. Nur noch wenige Stunden bis zur Demonstration der Sprintleistung. In den Teams herrscht rege Hektik. Ein Blick auf die Sprint Backlogs der einzelnen Teams verrät, dass kaum ein Team schon wirklich „fertig“ ist. Auf Nachfrage erhalte ich Antworten wie: Wir sind fast fertig oder zwei Tests laufen noch nicht rund oder eine Doku steht noch aus, die dann noch gereviewt werden muss. Auf den letzten Drücker erfolgt dann noch die Abnahme des Product Owners und mit heißer Nadel bekommt die noch nicht ganz fertige Userstory ihren grünen Haken, als Zeichen dafür, dass sie erledigt (done) ist. Kurzum: Ich beobachte immer wieder das gleiche Phänomen. Die Lieferung des versprochenen (Commitment) Geschäftswerts kommt fast immer in allerletzter Sekunde. In vielleicht fünf (und da greife ich schon hoch) von hundert Sprints sehe ich Entwicklungsteams, die am Tag der Review nichts mehr für die aktuelle Lieferung tun müssen: Es (potential shippable increment) ist getestet (nicht nur unit-getestet), die Funktionalität ist integriert.
 
Grundsätzlich spricht nichts dagegen, wenn eine Userstory, mit heißer Nadel gestrickt, auf den Punkt genau fertig wird. Das spricht auch für das Team. Es hat, wie versprochen, Qualität geliefert und kann gemeinsam einen Erfolg einstreichen. Interessanterweise äußern sich die Teams nahezu einstimmig über die Gründe, warum alles immer auf den letzten Drücker fertig wird: in den ersten Tagen des Sprints wird getrödelt. Man hat gerade einen Sprint hinter sich gebracht und schon soll man wieder Vollgas geben. Das fühlt sich so an, als säße man im Hamsterrad. Darüber hinaus ist man zu Beginn eines Sprints noch nicht so mit der fachlichen Materie vertraut, wie während des Sprintzyklus oder zum Ende hin. Das heißt, dass gerade am Sprintanfang noch viele Dinge unklar sind.
 
Einerseits ist es also verständlich, dass die Teams die ersten Tage im Schongang unterwegs sind und die Arbeitsatmosphäre eher an das sprichwörtliche „Kommst du heut`nicht, kommst du morgen“ erinnert, als an Erich Kästners „Es gibt nichts Gutes, außer man tut es (Anm. d. Verfassers: und zwar am besten sofort).“ Allerdings sinkt mit steigendem Zeitdruck die Qualität der Arbeit und damit auch die Leistungsfähigkeit. Schon vor 100 Jahren wurde das Yerkes-Dodson-Gesetz, das bis heute als allgemein gültig akzeptiert wird, niedergeschrieben. Es besagt, dass „die menschliche Leistung bei einer mittleren Erregung die besten Werte erzielt, bei zu geringer und zu hoher Erregung die schlechtesten. Um die optimale Leistungsfähigkeit ausnutzen zu können, ist eine mittlere Aktivierung und ein wenig Druck, um wach zu werden und in Schwung zu kommen, zu begrüßen. Je stärker der Druck jedoch steigt, desto rapider nimmt die Leitungsfähigkeit ab“ (Kratz, 2011, S. 28).
 
Was kann ein Scrum-Team nun unternehmen, was kann der Einzelne unternehmen, um beiden Seiten der Medaille gerecht zu werden?

Gegen Aufschieberitis

Aufgaben wachsen in dem Maße, in dem man sie vor sich herschiebt. Bleiben Dinge unerledigt, dann wächst nicht nur die Liste der Erledigungen, sondern das Unerledigte sitzt uns immer stärker im Nacken und übt einen unangenehmen Druck aus. Deshalb kann ich nur die Empfehlung aussprechen, den großen Frosch zuerst zu vertilgen („Eat the frog“) – jeden Tag. Fangt mit den Sachen an, die am wichtigsten sind und die am meisten Arbeit machen, auch, wenn sie noch so unbeliebt sind. Es wird euch den Druck nehmen. Und macht es nicht allein (nicht selten beobachte ich, dass die Anzahl der Reviews zu Beginn leider sehr gering ist). Geteiltes „Leid“ ist schließlich nur halbes. Und noch was: Eat the frog and reward yourself. Möglicherweise kommt der große Brocken erst mitten im Sprint, weil man beim Planen etwas unterschätzt hat. Auch dann gilt das gleiche Prinzip:
 

Der Fehler als Leistung, der Fehler als Chance



Winston Churchill hat mal gesagt: „Perfektion ist Lähmung.“ Und er hat recht damit. Die Hauptursache für Aufschieberitis ist laut Professor Lothar Seiwert, Zeitmanagement-Guru, unser Perfektionismus (vgl. Seiwert, 2009, S. 198): „Wer immer alles perfekt erledigen will, der wird nie fertig und ist somit gezwungen, immer mehr Aufgaben immer länger vor sich herzuschieben. Natürlich wollen wir alle unser Bestes geben. Doch: Muss deshalb immer alles perfekt sein?“
 
Software-Entwickler neigen ebenso wie Ingenieure zu einem starken Hang zur Perfektion. Es muss alles 100 Prozent vollkommen sein. Alles, was weniger ist als alles, ist definitiv zu wenig. Und genau das führt dazu, dass man den Fokus verliert und nicht mehr unterscheiden kann, ob etwas (überhaupt noch) wirklich wichtig und für eine Lieferung überhaupt essentiell oder gar vonnöten ist (Definition of Done). Hier würde ich mir eine intensivere Kommunikation mit dem Product Owner und seinem Team wünschen. Akzeptanzkiterien auf der Basis der Requirements müssen klar definiert sein und sollten vor allem als Minimalanforderung besprochen werden: Das möchte ich mindestens haben. Wenn ihr das habt, dann gebt Bescheid. Gebt euch untereinander öfter Feedback – insbesondere bei euren Reviews. Hinterfragt euer Handeln! Tun wir noch das Nötigste oder ist es schon mehr, vielleicht schon zu detailliert, zu viel.

Review am Freitag?

Ein von mir äußerst geschätzter Entwickler und Mitglied eines sehr produktiven Scrum-Teams äußerte sich zu der oben diskutierten Problematik dahingehend, dass er sich am Ende eines Sprints zwar zufrieden fühlt, aber er sei auch ausgelaugt und “satt”. Ihm würde es helfen, wenn die Review an einem Freitag vonstatten ginge. Man könne so den Sprint auch tatsächlich abschließen. Nach einem erholsamen Wochenende würde dann am Montag das nächste Sprint Planning folgen und man wäre für neue Aufgaben ausgeruhter und bereit.
 
Was denkt ihr? Seht ihr das auch so? Wie sind eure Erfahrungen mit Lieferungen, die auf den letzten Drücker passieren?
 
 
Literatur


Kratz, Hans-Jürgen (2011). Aufschieben. Nein danke! Tu`s gleich! Die beste Strategie für mehr Lebensqualität. Walhalla.
 
Seiwert, Lothar (2009). Noch mehr Zeit für das Wesentliche. Zeitmanagement neu entdecken. Goldmann.

Mit dem Inneren Team Probleme lösen

Letztens kam ein in seiner Rolle noch unerfahrener Company ScrumMaster auf mich zu und äußerte sich besorgt zu seiner neuen Tätigkeit: „Ich bin mir nicht sicher, ob ich ein guter Company ScrumMaster sein werde.“ Ich fragte ihn, was ihn verunsichern würde. Er antwortete mit den Worten: „Einerseits denke ich, dass ich das sicher ganz gut hin bekommen werde. Ich kann Teams führen. Das wird mir in meiner neuen Aufgabe helfen. Andererseits bin ich mir aber nicht sicher, ob das reichen wird und schon gar nicht, ob ich für die Herausforderung, ein wirklich guter Company ScrumMaster zu werden, die notwendigen Fertigkeiten und Fähigkeiten besitze.“ Der Company ScrumMaster befand sich offensichtlich in dem inneren Konflikt, ob er den an ihn gestellten Anforderungen seiner neuen Verantwortung gewachsen sein wird – eine Situation, in der bestimmt jeder von uns schon mal war. Was tun und wie viel von was?
Ganz gleich, ob ich eine schwierige Entscheidungssituation zu klären habe, einen äußeren Konflikt lösen muss oder wie der zuvor zitierte Company ScrumMaster Antworten auf einen in mir herrschenden Konflikt suche, eines steht meines Erachtens außer Frage: Nur „wer mit sich selbst einig ist, kann der Welt mit vereinten Kräften begegnen.“ (2) Die Einigkeit mit sich selbst setzt jedoch voraus, dass ich weiß, dass jeder Mensch verschiedene Anteile in sich trägt. Sie sind das individuelle Abbild unterschiedlicher Rollen, Ziele, Erfahrungen, Ängste und Wertvorstellungen in uns. Diese Erkenntnis beruht auf einem Modell des Hamburger Kommunikationstheoretikers Prof. Dr. Friedemann Schulz von Thun, das er nach einer Metapher „Inneres Team“ nennt. Ähnlich wie Goethes Faust, in dem „zwei Seelen wohnen“, befinden auch wir uns, laut Schulz von Thun, ständig in einer Art Zerreißprobe, die unser Tun erschwert, weil sich in uns plötzlich Stimmen oder Impulse melden, die uns bremsen, warnen, antreiben, etc. Es gibt stärkere und schwächere, beliebte und unbeliebte Anteile, ja sogar weggesperrte (dissoziierte), die meist im Hintergrund wirken oder still in einer Ecke sitzen, aber auch unkontrolliertes Handeln und Erleben bewirken können. Schulz von Thun spricht hier von der Inneren Pluralität (3). Die Stimmen untereinander sind sich nicht immer wirklich einig oder stehen teilweise in einem Widerspruch zueinander, was unsere Kommunikation und unser Handeln stark beeinflusst. Wer jedoch nach außen in einer bestimmten (Problem-)Situation klar und authentisch (re-)agieren möchte, der muss jedem inneren Anteil des „zerstrittenen Haufens“ – so lästig dieser auch sein mag – Berücksichtigung schenken. Diese Form der Selbstklärung, also der Dialog mit den jeweiligen inneren Anteilen, soll zu einem handlungsfähigen Inneren Team führen und auf diese Weise zu einer verbesserten Kommunikations-, Konflikt- und/oder Problemlösefähigkeit beitragen.

Interview mit dem Inneren Team

Möchte man nun Klarheit darüber haben, welche inneren Anteile sich in einer bestimmten Situation zu Wort melden, muss man diese identifizieren, ihnen einen Namen geben und mit einer kurzen Beschreibung versehen. Der Befragte soll hierbei eine Außensicht einnehmen und von dort auf sein inneres Team schauen (Tipp: Visualisierung mit Moderationskarten je Anteil an einer Pinnwand). Nehmen wir noch mal das Beispiel des Company ScrumMasters. Erinnert euch, was er gesagt hat:
Einerseits denke ich, dass ich das sicher ganz gut hin bekommen werde. Ich kann Teams führen. Das wird mir in meiner neuen Aufgabe helfen.“ Der besagte Company ScrumMaster nennt diesen Persönlichkeitsanteil den „Erfahrenen“. Andererseits bin ich mir aber nicht sicher, ob das reichen wird“. Hier meldet sich „der Skeptiker“ in dem Company ScrumMaster. „…und schon gar nicht, ob ich für die Herausforderung, ein wirklich guter Company ScrumMaster zu werden, die notwendigen Fertigkeiten und Fähigkeiten besitze.“ Hier spricht „der Pessimist“.
Im nächsten Schritt geht es darum, jeden wichtigen Anteil (Tipp: nicht mehr als sieben) – auch die leisen, die beispielsweise still in einer Ecke sitzen und sich nicht trauen etwas zu sagen – einzeln zu würdigen und intensiv zu befragen, z.B.: „Angenommen, ich frage den Skeptiker, was würde er sagen, wenn …?“
Durch intensives Befragen wird nun herausgefunden, wie die inneren Anteile zueinander stehen (vgl. Rauen, 2001) (1):

Herrscht nun mehr Klarheit über die inneren Anteile und ihre jeweiligen „Charakterzüge“, sollten Gespräche, sogenannte Verhandlungen, zwischen den Inneren Teammitgliedern initiiert werden. Auf diese Weise sollen nicht nur bisher unbeachtete oder sogar unterdrückte Anteile im weiteren Tun berücksichtigt werden, sondern die Akzeptanz der inneren Pluralität soll schließlich dazu führen, dass das Innere Team handlungsfähig gemacht wird, denn – auch wenn ich mich wiederhole, nur „wer mit sich selbst einig ist, kann der Welt mit vereinten Kräften begegnen“ und das geht nur mit einem Team, auf das man sich verlassen kann.

Einsatzgebiete für das Innere Team

Das Innere Team kann beispielsweise in folgenden Alltagssituationen eingesetzt werden:

 
Literatur
(1) C. Rauen (2001). Coaching. Göttingen.
(2) F. Schulz von Thun (1998). Miteinander reden 3. Reinbek.
(3) F. Schulz von Thun & W. Stegemann (2008). Das Innere Team in Aktion. Reinbek.

Product Ownership: Der Unterschied zwischen guten und großartigen Teams

In Review-Meetings geht es häufig zu wie in der Schule: Der Product Owner prüft, ob sein Team alles richtig gemacht hat. Team und Product Owner stellen sich dann den Fragen der Besucher und hoffen, dass es möglichst glimpflich abläuft. In dieser Variante ist das Team Lieferant: Es tut das, was von ihm gefordert wird. Nicht mehr und nicht weniger.
Das Review-Meeting ist eigentlich dazu da, die Verhältnisse umzukehren: Team und Product Owner stellen ihr Produkt gemeinsam vor. Sie erzählen, was sie bisher schon erreicht haben, und wohin der weitere Weg gehen soll. Im Mittelpunkt steht hier nicht mehr die Frage, ob das Team alles richtig gebaut hat (das können Product Owner und Team vorab klären). Im Mittelpunkt steht vielmehr die Frage, ob das Produkt das richtige ist.
Fallbeispiel aus einem meiner neueren Projekte: Eine Firma kann sich nicht entscheiden, welches Produkt sie bauen soll. Zum einen ist da der Kundenwunsch nach einer schnellen und billigen Sonderlösung. Zum anderen gibt es die strategische Ausrichtung auf eine Zukunftstechnologie. Der Kunde ist ein sehr wichtiger, und er droht, zur Konkurrenz überzulaufen.
In dieser schwierigen Konstellation wird ein Scrum-Team aufgesetzt. Zunächst ist das Team komplett orientierungslos und frustriert. Es spürt ja, dass das Management bis hin zu den obersten Etagen nicht weiß, was zu tun ist.
Das Team ist allerdings hochkarätig besetzt: Die meisten Mitglieder sind schon lange mit dabei und haben tiefe Erfahrung mit der Produktfamilie.
Im Laufe eines zweiwöchigen Sprints vollzieht sich ein spannender Wandel: Das Team fängt an, eine eigene Haltung aufzubauen. Es wartet nicht mehr auf Entscheidungen des Managements, sondern prescht selbst voran. Es macht ein durch und durch souveränes Review, in dem es dem Management ein durchdachtes und belastbares Bild möglicher Lösungen präsentiert, das den Entscheidungskorridor absteckt.

Team: Jeder ist Produkt-Visionär

Entscheiden muss das Management trotzdem noch. Aber durch das selbstbewusste Vorangehen des Teams wird vielen klar, wie die Lösung definitiv nicht aussehen kann (weil sie technisch nicht machbar ist, weil sie den Kostenrahmen sprengt oder weil sie mit zu vielen Abhängigkeiten behaftet ist). Und es wird auch klar, dass sich beide Alternativen (Kundenwunsch versus strategische Ausrichtung) doch irgendwie verknüpfen lassen. Erstauntes Fazit eines Managers am Ende des Reviews: Wir brauchen ein starkes Team, um Entscheidungen treffen zu können! Ein Team, das Anfragen nicht nach Vorgabe bearbeitet, sondern selber die Zügel in die Hand nimmt und das Sorgerecht für das Produkt übernimmt.
Großartige Scrum-Teams zeichnen sich dadurch aus, dass das Ownership über das Produkt verteilt ist: Jeder ist Visionär des Produktes, jeder möchte es als sein eigenes präsentieren. Ein großartiges Team schreibt gemeinsam mit dem Product Owner User Stories. Teammitglieder suchen das Gespräch mit Benutzern, Kunden und Management – und können erklären, wie es weitergeht.
Wird der Product Owner dadurch überflüssig? Natürlich nicht. Er ist dann koordinierende und maßgebende Instanz, die dafür sorgt, dass es am Ende des Tages ein Product Backlog gibt. Und dass die Constraints, innerhalb derer sich die Produktentwicklung bewegen soll, möglichst klar und vor allem stabil sind. Der Product Owner ist somit ein Hort der Ruhe gegenüber den oftmals hoch volatilen Wünschen von Kunde und Management.
Der ganze Rest, die ganze hohe Kunst des Managements, lässt sich in zwei Worte zusammenfassen: Machen lassen (vgl. Takeuchi et Nonaka 1986: 139-140)!
Takeuchi, Hirotaka und Nonaka, Ikujiro: The New New Product Development Game. Harvard Business Review, January February 1986.

… der abgehängte Product Owner

Am eigenen Leib habe ich erfahren, dass es einfach nicht ausreicht, wenn man seine PO-Aufgabe nur halbherzig wahrnimmt. Zu Beginn eines privaten Projektes – dass das Überleben meiner Pflanze zum Ziel hatte, obwohl ich die Woche über ständig unterwegs war –  sprudelten die User Stories nur so aus mir heraus. Die Vision war klar und die Priorisierung leicht.
Doch nachdem die ersten Erfolge schnell sichtbar wurden, ließ ich es zugegebenermaßen etwas schleifen. Der „Nachschub“ für den Entwickler war unklarer als noch zu Anfang. Aufgrund seiner hohen Motivation entwickelte er jedoch fleißig weiter. Leider führte das dazu, dass ich mich immer weniger mit dem Produkt identifizierte, immer weniger Spaß an der Abnahme der Stories hatte und auch immer mehr Verbesserungen nötig wurden. Die Aussage: “Genau so wollte ich es haben!” und die damit verbundene positive Rückmeldung an den Entwickler wurde immer seltener. Kein Wunder, dass das die Motivation des Entwicklers nicht gerade beflügelte. Er machte nunmehr das, von dem er glaubte, dass ich es wollte und das, was ihm besonderen Spaß machte. Ein sich selbst verstärkender Prozess, denn ich erkannte mich immer weniger wieder und ließ ihn einfach machen.

Als wir uns nach einiger Zeit
mal wieder die Zeit nahmen die Nutzer-Brille aufzusetzen, stellten wir mit Erstaunen fest, dass sich die Vision des Produktes mittlerweile komplett verändert hatte. Eine Weiterentwicklung in die „alte“ Richtung konnte also keinesfallszu Mehrwert führen. Mir wurde bewusst, warum ich mich so abgehängt gefühlt hatte bzw. mich selbst abgehängt hatte.
Ich nehme für mich mit: Ganz oder gar nicht. Wenn ich mir wieder die Zeit nehme, werde ich es nicht mehr halbherzig angehen!
 

Als PO muss man mittendrin, statt nur dabei sein …

Man muss sich die Zeit nehmen wollen, es richtig zu tun!

ScrumStart(-Up)

Stellen wir uns vor, wir hätten eine revolutionäre Geschäftsidee. Ein Bild das uns dazu bringt zu sagen: “Ich will Entrepreneur werden und ich brauche Leute, die mir dabei helfen.” Eigentlich relativ einfach. Diese Leute müssen lediglich dasselbe Bild sehen, das wir sehen und schon beschließen solche Freigeister, der gewöhnlichen, 9 to 5-Welt zu entrinnen und sich einer revolutionäre Geschäftsidee anzuvertrauen.
 
Wir zeichnen und malen in Worten ein Ereignis, eine Abfolge, ein Szenario mit Umlauten, Händen & Füßen. Dieses Gemälde kann ein Rembrandt sein und wir sehen es. Wir alle haben Freunde, die uns schon lange kennen, bei denen es uns leicht fällt, unser Gemälde in die Köpfe zu pinseln. Die Kommunikation innerhalb unserer bekannten sozialen Systeme ist von geringer Missverständniswahrscheinlichkeit und geringem Aufwand geprägt. Aus meiner Erfahrung sind die ersten Ideenempfänger eines Entrepreneurkindes die engsten Vertrauten und Verwandten, vor deren inneren Augen das Entrepreneurkind ohne große Mühe eine so makellose Rembrandtkopie seiner Idee hinterlässt, bei der selbst Bansky vor Neid erblassen würde.

Aus eins mach sieben

Rembrandt Selbstporträt, 1656-1659, Museum Boijman Van BeuningenDie Idee steht und das Kind tritt aus seiner vertrauten Welt hinaus in die Welt der hiesigen Startup-Szene, um dort sein Gemälde in das Rampenlicht zu hängen, auf dass sich Menschen in dieses Gemälde verlieben mögen und dabei unterstützen, es real werden zu lassen. Auf der Bühne zieht das Entrepreneurkind voller Euphorie das Tuch herunter und findet die ersten 7 Interessenten, die sich vor dem Gemälde aufbauen. Das ist ein spannender Augenblick, das Entrepreneurkind beginnt zu malen und schafft es mit demselben Pinsel, derselben Auswahl an Farben und denselben Schwingungen, sieben (7) verschiedene Bilder zu kreieren.
 
Jedes Team hat ein Bild im Kopf. Keines dieser Bilder ist der Rembrandt. Die ersten zwei Teammitglieder wenden sich ab und gehen mit einem sinnlosem Bild von dannen. Der Rest ist zufrieden mit seinen Ideen und Bildern und lässt sich auf das Wagnis ein. Das Startup-Team des erwachsenen Entrepreneurs steht.
Das BigPicture soll Wirklichkeit werden. Alle rennen los.
 
Einer beschäftigt sich mit der rechten oberen Ecke des Bildes, ein paar andere mit der links unten und der Entrepreneur betupft die Mitte … und auch er macht denselben Fehler. Er schaut nicht über die Schulter, ob das Team beisammen ist und ihm folgt. Erst in den ersten Berührungen, bei denen die geschaffenen Teilgemälde in das nächst Größere fließen sollen, sieht das Team: Seit Wochen malen wir nicht zusammen an einem Gemälde, sondern haben eine Galerie farbiger Stofffetzen erschaffen, die nicht einmal die Bordsteine der Straßen auf dem Weg zum Louvre schmücken dürften!

Die Vision als Muse

Dieses Szenario kann verhindert werden. Es wird immer häufiger verhindert. Durch einen ScrumStart.Rembrandt Selbstporträt, 1660, Metropolitan Museum of Art
Der Entrepreneur stellt die Vision als Muse auf und beginnt das (Be-)schreiben von einzelnen Bild-Geschichten aus der Sicht eines späteren Betrachters. Immer wieder bespricht er mit seinem Team, was nötig ist, um seine kleinen Bild-Geschichten innerhalb der nächsten Woche Wirklichkeit werden zu lassen. Sie skizzieren gemeinsam den Grundriss und hören einander intensiv zu. Nun beginnt das Team die Farben aufzustellen und die Pinsel zurechtzulegen, und beschließt lediglich für die nächsten Stunden, wie es die ersten Striche arrangieren möchte. Hierbei zeichnet niemand im Alleingang, vielmehr bringt jeder seine Fähigkeit hinein und erklärt, welche Striche und Kleckse zu kreieren sind. Farbtopf in der einen, Tipp-Ex in der anderen Hand. Im Anschluss nimmt sich jedes Teammitglied eine kleine Ecke heraus und beginnt zu malen.
 
In kurzen regelmäßigen Abständen stellt sich das Team zusammen und jeder erzählt kurz, ob er noch genug Farbe hat, was er gemalt hat, welchen Fleck er nun ausbessern möchte und wie er jemanden aus dem Team mit Schwamm oder Pinsel helfen kann. Um dem Team Sicherheit zu geben, wird eine Person dazu ermächtigt, für die Einhaltung solcher “Prozesse” und “Tiegel” zu sorgen, ohne gleich hierarchisch platziert zu sein. Vielmehr ein Trainer, ein Coach des Teams…
Das Malen, Zeichnen, Radieren wird gemeinsam erlebt und mit dem Entrepreneur werden stetig die ersten Bilder aufgehängt.
 
Am Ende der Woche holt der Entrepreneur diverse Kunstinteressierte aus umliegenden Museen und das Team präsentiert die erste Landschaft der Vision als reales Gemälde. Die Kunstinteressierten werden angeregt zu äußern, was dem Kunstwerk fehlt, bis sie sich solch ein Gemälde in ihr Wohnzimmer hängen würden. Während der Product Owner, ach nein, der Entrepreneur diese Vorschläge aufnimmt und sie wieder in Bild-Geschichten erfasst, beginnt das Team, auf den letzten Sprint, Entschuldigung, Zeitabschnitt zurückzublicken, um Verbesserungspunkte bzgl. seines Schaffens herauszufinden, um sie in dem nächsten, nun schreib ich`s: Sprint, umzusetzen.
 
Von nun an wiederholt sich diese Schaffungsphase, das Startup bewegt sich in der agilen Produktentwicklung. Scrum.

Wir leiden an Selbstüberschätzung – und das ist auch gut so!

Diagnose: Selbstüberschätzung! Wir alle leiden darunter, eine Volkskrankheit sozusagen. Wir finden uns selbst und unser Handeln gut und denken, wir können alles besser als die anderen. Die anderen nämlich unterschätzen wir gerne. Natürlich kann ich besser einparken als die Kleinwagenfahrerin da vorne. Natürlich weiß ich besser über meinen Gesundheitszustand Bescheid als der Arzt – ich habe ja schließlich gegoogelt. Der Kollege wird das Meeting nicht halb so gut moderieren können wie ich. Pah! So schnell wird mir keiner etwas vormachen! So oder so ähnlich sieht es in vielen Köpfen aus.
 
Selbstüberschätzung ist ein Wahrnehmungsfehler, eine kognitive Verzerrung, wie die Psychologen es nennen. Rolf Dobelli (in: Die Kunst des klaren Denkens, 2011) lehnt sich an die Arbeit von Alpert/Raiffa an, die dieses Phänomen den Overconfidence-Effekt nennen. Wir alle tragen diese Eigenart in uns, können uns nicht dagegen wehren. Aber müssen wir es denn? Ohne diese Überschätzung würden wir keinen einzigen Schritt vorankommen. Der erste Schritt ist immer ein Versuch, immer ein Risiko, immer ein Wagnis. Daher ist das sogar gut, dass wir uns selbst überschätzen. Trial and error kann nur so funktionieren. Wir lernen bei jedem Schritt etwas dazu und kommen dem Ziel ein Schritt näher. Und genau damit nähern wir uns einer realistischen Einschätzung an. Wenn wir aber nur eine Chance zum Schätzen haben, dann sollten wir uns an der pessimistischsten Variante orientieren. Mit dem Wissen, dass wir zu hoch gestapelt haben.
 

Was bringt uns diese Erkenntnis in unserem Scrum-Alltag, zum Beispiel den Product Ownern?

Zum einen: Schwankt das Team in seiner Schätzung, nimm den pessimistischeren Wert. Das Team überschätzt sich möglicherweise. Zum anderen: Gib deinem Team eine Vision, die es anspornt, einen Schritt weiter zu gehen. Eine Vision, die die Möglichkeit gibt, sich an hohen Zielen zu orientieren. Und gib ihnen die Möglichkeit, oft auszuprobieren. Je mehr Versuche in der Entwicklung, desto besser das Produkt. Je häufiger Schätzungen stattfinden, desto realistischer werden sie sein.
Selbstüberschätzung in kleinen Dosen und zielgerichtet angewandt, kann sehr gewinnbringend sein, eine Überdosis jedoch ist schädlich. Und seien Sie sich stets bewusst, dass sie immer bei uns ist. Männer sind davon übrigens häufiger betroffen als Frauen, die sich danach also realistischer einschätzen. Ein weiterer guter Grund für Diversity im Team.

ScrumMaster vs. ScrumMasterin

Zum Hintergrund: Es ging bei folgender Szenerie um das Schreiben von User Stories aus der Sicht einer Persona. Die Sicht des Kunden, also der der Persona, verstand mein Gegenüber als eine weibliche Eigenschaft.
 
„Na ist doch klar, als Frau achtet man auch mehr auf Details. Wir Männer sind da eher pragmatisch veranlagt!“
 
Nicht nur, dass er diese schon eingestaubte und marode Mann/ Frau-Schublade aufmachte. Nein, diese überholte Ablage, verstaut in den Tiefen einer Schublade, wurde durch einen weiteren Kommentar noch bildlich untermauert: „Na wenn ich Hunger habe“, so die Einleitung „dann mach ich mir ein Schnitzel, esse das, bin satt und gut ist. Was muss ich denn da noch viel Schi Schi machen. Das ist dann mehr so ein Frauending.“
 
Auch ich dachte, der Hauptteil und Schluss wäre bei der Ausführung spannender, aber es blieb bei einer Kurzgeschichte. „Schi Schi machen, was meinst du damit?“ Der Spannungsbogen war mir nicht spannend genug, es war nicht mal ein Bogen. Eine platte Attitüde längst vergessener Ansichten lag nun in meinem Kopf und arbeitete sich durch alle Etagen ins Oberstübchen.
 

Geht es bei einem Perspektivenwechsel tatsächlich um weibliche Fähigkeiten?

Wenn ich von einer Persona spreche, rede ich von einem Kunden, einem Stakeholder oder auch von einer klassifizierten, vielleicht stereotypischen Persona, die mein Produkt konsumiert, nutzt und repräsentiert. Je nach Kunde überlege ich mir also eine Persona mit entsprechenden Eigenschaften dazu, die den Kunden repräsentiert.
Diese Persona/ Kunde zahlt Geld, um die Funktionalität zu nutzen, die ich anbiete, oder auch nicht. Mein Ziel und Interesse ist demnach sehr pragmatisch. Ich will einen zufriedenen Kunden! Schi Schi ist in jedem Fall angebracht, wenn mein Interesse darin besteht, dass mein Produkt nicht nur genutzt wird, sondern dass ich im Idealfall auch noch Geld damit verdienen kann, weil der Kunde zufrieden ist.
Missachte, ignoriere ich bei der Umsetzung meines Produktes die User/ Kunden/ Persona Sicht, dann hat das für mich nichts mit typisch Frau oder typisch Mann zu tun. Meiner Ansicht nach fehlt hier all zu oft das allgemeine Interesse ein Produkt für real existierende Menschen/ Kunden/User -> Persona zu bauen.
 
Zum Abschluss: Wir sind ScrumMaster, wir schreiben keine User Stories, aber wir  helfen unserem Product Owner dabei. Ob da nun ein ScrumMaster neben dem PO sitzt, oder eine ScrumMasterin, hat für mich keinerlei Einfluss. Für mich ist wichtig, dass der ScrumMaster in der Lage ist, den Kunden zu kennen, oder kennenzulernen, um mit dem Product Owner eine oder mehrere Persona(e) zu kreieren.

Embrace perfectionism by using trial and error

[quote author = “Tom Ford”]”Perfectionism is something you are born with [1].“[/quote]
Es ist geradezu erstaunlich, dass sich Tom Ford so offen zum PerfektionismTom Ford by Nicolas Geninus bekennt. Liest man ein paar Dinge über Steve Jobs, so ist das Erste, was einem auffällt: Er war geradezu besessen von Perfektion. Ford und Jobs haben gemeinsam, dass sie Industrien revolutioniert haben. Die Modebranche wurde von Tom Ford als Chef Designer von Gucci und Yves Saint Laurent tiefgreifend verändert. Steve veränderte die Art, wie wir heute den Computer sehen.
Beides Männer, die Wege gefunden hatten, ihre Ideen umzusetzen. Dabei liegt die Betonung auf ihren Ideen. Sie wussten, was sie wollten. Schaut man in dem Video über Tom Ford genau hin und schaut sich an, was er tut, so arbeitet er an seiner Kollektion auch dann noch weiter, wenn er sie sieht und sie für jeden Laien als “fertig” zu bezeichnen wäre. Die ersten Modelle sind geschneidert und wenn er sie zum ersten Mal sieht, dann verändert er sie – offenbar egal, was er zuvor designed hat. Vieles von dem, was er sich aufgemalt hatte, scheint nicht zu funktionieren, obwohl er vorher sicher war, dass er es so haben will.
16 Kollektionen hatte Ford entworfen, bevor er sich dem Filmemachen widmete und mit „A Single Man“ großen Erfolg hatte. Er selbst sagt von sich: “When I am awake, I am working … working is just the way I am!“ Damit wird auch Ford zum Inbegriff des Archetypen, wie ihn sich Marty Cagan [2] vorstellt. Ein Product Owner arbeitet viel. Viel mehr als der Durchschnitt.

Perfektionismus beim Product Owner

Vergleichen wir mal diese beiden Prototypen, Tom Ford und Steve Jobs, mit dem, was wir tagein tagaus in Firmen sehen. Welche Product Owner – ok, nein, nicht überall wird Scrum gemacht. Also: Welche Product Manager, welche Designer setzen tatsächlich um, was sie haben wollen? … Oops … fragt man diese Product Owner/Product Manager, dann hört man sehr häufig: “Wir müssen mal fragen gehen, wir müssen machen, was der Kunde will, wir müssen die Software-Architekten fragen, wir wissen ja selbst nicht so genau, wie es geht. Wir haben nicht genug Ahnung von unserem System.”
Product Manager, die nicht genau wissen, was ihre Kunden brauchen (man beachte: brauchen – nicht wollen), die keine Ahnung von den internen Funktionen ihrer Produkte haben. Product Manager, die überfordert sind … Das mag nun wie eine Kritik klingen, aber das sollte es gar nicht … es ist einfach nur eine Feststellung, eine Beobachtung. Aber warum? Warum wissen sie nicht genau, was ihre Kunden brauchen? Warum kennen sie ihre Applikationen nicht, wieso wehren sich denn diese Product Manager mit Händen und Füßen, wenn sie auch über die Technik Bescheid wissen sollen?
Weil der Perfektionismus, den all diese Leute haben – sonst wären sie nämlich gar nicht in diesen Positionen – falsch gelenkt wird.

Perfektion gelenkt durch Angst

Ihre Perfektion entstammt einer Angst. Diese Angst fußt auf der Unsicherheit, die Welt nicht kontrollieren zu können. Ford sagt selbst, dass er erst mit Mitte 40 erkannt habe, dass er nicht alles kontrollieren kann. Perfektionismus ist meist eine Folge einer tiefsitzenden Angst vor Kontrollverlust. Perfektionismus ist aber nicht per se falsch, wie wir bei Ford und Jobs sehen. Perfektionismus kann uns antreiben. Er ist ein sehr guter Ratgeber, wenn es darum geht, Qualität zu erzeugen und ein Freund beim Gestalten großartiger Produkte.
Aber: Perfektionismus ist auch ein Freund, der zum Feind werden kann. Er kann zum Gegner der Kreativität, zum Gegner des Neuen werden und zum Bewahrer, Verlangsamer und zum Tod des Neuen werden. Product Manager, die sich in ihrer Sache unsicher sind, die nicht genug Kenntnisse haben, die aber dennoch alles kontrollieren wollen, weil sie es ja richtig machen wollen, die ihre Perfektion nicht für die Sache kanalisieren, sondern sie nutzen, um alles richtig machen zu können, haben nicht nur ein wirklich hartes Leben, sondern sie verhindern den Erfolg ihrer Produkte. Diese Manager setzen Kontrollinstrumente auf, verbringen ihre Zeit mit dem Warten von Tabellen und wer mit ihnen über Scrum redet, hört in den Zwischentönen Immer ein tiefsitzendes Misstrauen. Werden die anderen denn den Ansprüchen genügen?
Leider kann man die Wette gegen die Menschen, dass diese Fehler machen, nicht verlieren. Wenn ich als Manager denke, mein Team wird sicher nicht alles richtig machen, und selbst wenn ich ihnen dann freie Hand lasse – ich werde immer enttäuscht werden, denn sie werden immer irgendeinen Fehler machen. Das liegt in der Natur der Sache. Nimmt man aber diesen Umstand der rationalen Tatsache, dass nie, absolut nie etwas über längere Zeit fehlerfrei sein wird, als ein Indiz für die „Unfähigkeit“ der eigenen Mitarbeiter, wird man immer gegen sein Team, seine Mitarbeiter, seine Freunde gewinnen.


Der Weg

Wie kommt man aber nun aus der Falle raus? Die Lösung ist: Verluste abschreiben! Vergossene Milch ist vergossene Milch. Meine Fehler von gestern sind Fehler von Gestern, die mich heute hierhin gebracht haben. Gleichmut der Tatsache gegenüber einnehmen, dass Menschen etwas anders gemacht haben, als ich erwartet habe.
Hinnehmen, dass der Qualitätsanspruch richtig ist, dass er sich immer wieder äußert und aus diesem Qualitätsanspruch jetzt neu handeln, eine neue Entscheidung treffen. Im Wissen, die Entscheidung war ja nur aus der Betrachtung aus dem Heute über die Vergangenheit falsch. Als wir sie getroffen haben, war sie richtig. Wir hätten sie doch sonst nicht getroffen. Das bedeutet auch, dass ich in mich und meine Entscheidungsfähigkeit investiere und mir klar ist, dass ich heute deshalb da bin, wo ich bin, weil ich so viel, oder so wenig investiert habe. Ist das teuer? Klar, sehr oft ist eine Investitionsentscheidung sogar fatal: Sony hatte auf H-DVD gesetzt. Blue-Ray hat sich durchgesetzt. Das war teuer – garantiert.
Kann ich Entscheidungen verbessern? Sicher! Durch Kenntnisse, Erfahrungen, Rat von außen. Aber es ist eine ganz simple Rechnung: Je weniger ich selbst weiß, desto mehr Rat braucht man, desto mehr muss man in die Entscheidung investieren. Zeit, Geld, Ressourcen. Wer keine Kenntnisse hat, hat halt keine Ahnung. Oft führt das leider zu ewig langen Entscheidungswegen, die aber nicht dem Erkenntnisgewinn dienen, sondern nur der Absicherung. Wenn die Firmenspitze die falsche Entscheidung trifft ….
Viel einfacher wäre es, eine Kultur der kleinen Schritte zu etablieren. Hinter diesen Überlegungen stecken die Ideen von Eric Ries [3] , Marty Cagan [2] und vielen anderen zur innovativen Produktentwicklung. Die gesamte westliche Wissenschaft basiert – nicht nur, aber sehr stark – auf “Trial and Error” (Versuch und Irrtum).[4] Das heißt ja nicht: “Mach einen Fehler und probiere es nochmal!” Sondern habe eine Hypothese und dann prüfe sie. Wieso dann nicht auch endlich den wissenschaftlichen Ansatz in der Produktentwicklung etablieren?
Embrace perfectionism by using trial and error.
 
Aktuelle Kollektionen: Website Tom Ford
Ein ganzer Blog über Tom Ford: Fulltime Ford
1] Dokumentation über Tom Ford: http://vimeo.com/33599333
[2] Inspired: How To Create Products Customers Love (Juni, 2008) von Marty Cagan -> Blick ins Buch
[3] The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesse (September 2011) von Eric Ries -> Blick ins Buch
[4] Trial-and-error-Methode von Karl Popper, Bücher: Conjectures and Refutations: The Growth of Scientific Knowledge by Karl R Popper -> Blick ins Buch,
Logik der Forschung (2007), Karl Popper

It's the product, stupid!

In seiner Nikomachischen Ethik schreibt Aristoteles, dass Dinge und Lebewesen auf der Erde sind, um einen bestimmten Zweck zu erfüllen. Ein Hammer ist dazu da, um Nägel in die Wand zu schlagen. Ein Pferd ist zum Reiten da. Und der Mensch ist da, um vernünftig zu leben. Natürlich können Menschen auch andere Dinge machen: schlafen, essen, laufen. Aber dieser einer Zweck – Aristoteles nennt ihn areté – macht den Mensch einzigartig, er hebt ihn von allen anderen Lebewesen ab.


Welche ist die areté deines Lieblingsproduktes? Wie oft hast du das Gefühl, in unmittelbarer Verbindung, in ungehemmter Interaktion mit einem Produkt sein zu dürfen? Und wie oft sind Produkte von ihren Herstellern so verbaut, dass du sie nur noch mit Schwierigkeiten oder schlechtem Gewissen verwenden kannst? Wie oft fragst du dich dann: Bin ich denn zu blöd, um dieses Ding zu verwenden?
Ich war lange Zeit zufriedener Nutzer eines großen deutschen E-Mail-Anbieters. Mit den Jahren aber wurde das Schreiben, Speichern, Empfangen und Versenden von E-Mails immer schwieriger. Das Login-Menü verschwand hinter einem riesigen, knallbunten Portal mit Nachrichten, Werbung und kostenpflichten Zusatzangeboten. Der Speicher lief regelmäßig über. Spam-Mails durchbrachen den internen Filter, Mails von Freunden blieben dagegen im Filter hängen. Seiten stürzten ab und bereits geschriebene E-Mails waren plötzlich weg. Mit meinem E-Mail Client konnte ich Nachrichten über den POP-Eingang nur alle 15 Minuten abrufen.
 

Profit über Kunden?

Als ich einmal voller Ungeduld die Zusage zu einer Bewerbung abwartete und mein Postfach im Minutentakt abrufen wollte, musste ich erst Mitglied in einem Club werden, dort virtuelles Geld kaufen, und damit dann ständige Abrufbarkeit kaufen. Und wenn ich mich nicht ausgeloggt hatte, wurde ich beim nächsten Besuch von einem Herrn im weißen Kittel gegängelt, der mich über mein Fehlverhalten aufklärte.
Bei Yahoo! sahen die Mitarbeiter bis vor kurzem auf ihrer internen Startseite den aktuellen Börsenkurs ihres Unternehmens. Marissa Mayer, Yahoos neue CEO, hat diese Information von der Startseite verbannt. Die Botschaft an die Mitarbeiter: Schaut nicht auf die Finanzzahlen, konzentriert euch auf eure Benutzer!
Jedes Unternehmen steht irgendwann vor der Wahl zwischen Produkt und Verkauf. Ein Portal, das mit Werbung und kostenpflichtigen Hürden zugepflastert ist, bringt einfach mehr Einnahmen. Aber wie wirkt sich das auf die Beziehung des Benutzers zu seinem Produkt aus? Wann ist der Tag gekommen, an dem er entnervt hinschmeißt und zur Konkurrenz wechselt, weil dort das Produkt eben das tut, was es eigentlich tun sollte?
 
Wer Zahlen in den Vordergrund rückt und Unternehmen vorrangig an der Erreichung von Umsatzzielen misst, der macht die Profitabilität des Unternehmens zu seinem Daseinszweck. Das aber ist eine gefährlich Fehleinschätzung, die Zweck und Konsequenz verwechselt.
Unternehmen sind nicht dazu da, um profitabel zu sein. Ihr Daseinszweck besteht darin, sich am Markt zu bewähren, mit ihren Produkten oder Dienstleistungen vom Kunden geschätzt und in Anspruch genommen zu werden. Profitabilität ist eine – erfreuliche und wünschenswerte – Konsequenz davon.
Kunden, die ihre Produkte mit Begeisterung nutzen, weil sie gerne mit ihnen in Berührung kommen, sind das beste Messkriterium für den Erfolg eines Unternehmens.
 
http://online.wsj.com/article/SB10000872396390443517104577575420060344832.html

Akute Visionslosigkeit

„Die User Stories sind eigentlich nicht so das Problem, aber bei der Vision habe ich noch keine richtige Quote by Helen KellerIdee …“ So oder so ähnlich beginnen viele Gespräche mit einem „frisch gebackenen“ Product Owner. In der Scrum Logik scheint das eine verkehrte Welt zu sein. In der Realität stehen Unternehmen und Product Owner bei der Einführung von Scrum jedoch oft genau vor diesem Problem.
 
Am liebsten würde ich in diesem Moment einen Freudensprung machen und dabei das Scrum Framework dafür loben, dass es mal wieder den Nagel auf den Kopf getroffen hat. Aber damit wäre nun wirklich niemandem geholfen. Vielmehr geht es jetzt darum, dass der Product Owner die Emotion, die Begeisterung und die Willenskraft selbst spürt, die er in der Vision transportieren will. Und da führt kein Weg daran vorbei, es für sich selbst rauszufinden.
 
Also, liebe POs, bevor ihr anfangt darüber nachzudenken, wie ihr eurer Team begeistern könnt, begeistert euch selbst! 

  •  Was begeistert Dich an dem Produkt? Wann fangen Deine Augen an zu leuchten?
  •  Was macht das Produkt zu Deinem Produkt? Was ist Deine Handschrift?
  •  Wie wäre es ohne das Produkt? Was wäre das Produkt mit einem anderen Product Owner?
  •  …

Zugegeben, ich kenne viele Situationen, in denen es aufgrund der Rahmenbedingungen nicht leicht scheint, eine Antwort auf die Fragen zu finden. Aber eine Kleinigkeit fällt einem immer ein – Aufschreiben und weitersammeln …

Interview mit einem Akzeptanzkriterium (Teil 2)

Wieder exklusiv aus Backlogsen: bor!sgloger-Reporter David Holzer.
In Teil 1 des Interviews war das Akzeptanzkriterium etwas aufgebracht, weil es Sehnsucht nach guter Kommunikation hat und die aber so selten bekommt. Heute geht es weiter – was wir schon immer wissen wollten:
Wie und womit werden Akzeptanzkriterien erarbeitet? 
Welche Fragen muss ich mir als Product Owner und Entwicklungsteam dabei stellen? 
Was sind die Merkmale „guter“ Akzeptanzkriterien?


David Holzer: Sie haben gesagt “Feedback, Feedback, Feedback” sei die Voraussetzung, um Sie gut und nachvollziehbar zu erarbeiten. Das klingt simpel. Oder ist es das etwa nicht?
Akzeptanzkriterium: Wer Feedback gibt, sollte immer mit dem Empfänger seiner Nachricht rechnen. Etwas zu schreiben oder zu sagen heißt noch lange nicht, dass mich mein Gegenüber versteht, geschweige denn ein Bild von dem hat, was ich möchte. Und eins muss unbedingt klar sein: Eine noch so ausgefeilte Dokumentation ersetzt auf keinen Fall die Kommunikation. Feedback geben ist eine Kunst. Und je mehr Feedback, desto besser das Verständnis und desto verständlicher das Akzeptanzkriterium – also ich.
David Holzer: Und wie funktioniert das dann? Je besser das Feedback, desto besser werden Sie?
Akzeptanzkriterium: Bevor ich Ihnen darauf eine Antwort gebe, möchte ich gern die Frage etwas umstellen. Es ist weniger das Wie als vielmehr das Womit. Wissen Sie, womit Sie so richtig viel über mich erfahren können? Womit Sie mich aus der Reserve locken und ich Ihnen meine dunkelsten Geheimnisse offenbare? Na? (zwinkert den bor!sgloger-Reporter an)
David Holzer (zwinkert zurück): Na?
Akzeptanzkriterium: Zum Beispiel mit den richtigen W-Fragen. Damit können Sie Schlüsselwörter besser verstehen. Sie haben ganz große Augen, was ist los, geht es Ihnen nicht gut, kann ich Ihnen helfen?
David Holzer: Richtige W-Fragen? Schlüsselwörter? Hä?

Akzeptanzkriterium: Na gut, weil Sie es sind, erkläre ich es ganz langsam und zum Mitschreiben. Ich unterteile die W-Fragen erstmal in zwei große Kategorien. Kategorie 1, die User Story-Fragen: wer, was und wozu? Kategorie 2, die Akzeptanzkriterien-Fragen: wann, wohin, wie? “Wie” meint Fragen wie beispielsweise “wie genau”, “wie oft”, “wie schnell”, welcher Bezugspunkt oder was passiert, wenn nicht. Schlüsselwörter sind Wörter in einer User Story, auf die es letzten Endes ankommt und die bei der Umsetzung einen Handlungsspielraum bei der Interpretation lassen: Verben, Adjektive, Umfassungswörter, Füllwörter, etc.
David Holzer: Und das heißt jetzt konkret?
Akzeptanzkriterium: Ok, ich seh schon, Sie brauchen ein Beispiel. Nehmen wir ein Internet-Portal für Leute, die eine Mitfahrgelegenheit suchen. Privatanbieter können dort Inserate einstellen und eine Mitfahrersuche schalten. Eine User Story könnte in diesem Zusammenhang lauten: Als Mitfahrer möchte ich eine unkomplizierte Bedienoberfläche, damit ich beim Suchen gut zurecht komme. Das Adjektiv „unkompliziert“ ist jetzt ein so genanntes Schlüsselwort. Was heißt „unkompliziert“? Welche Schritte sind notwendig, um „unkompliziert“ zu erhalten? Welche Nutzer sind zu berücksichtigen? Welche Zeitvorgaben sind zu beachten? Welche möglichen Standards gilt es zu beachten, wenn „unkompliziert“ umgesetzt werden soll? (mustert den Reporter) Sie sehen gerade so aus, als hätten Sie es verstanden.
David Holzer: Ich sehe nicht nur so aus, ich verstehe jetzt wohl wirklich, was Sie mit Kommunikation gemeint haben. Haben Sie für unsere Leser noch ein Beispiel für andere Schlüsselwörter?

Akzeptanzkriterium: Endlich versteht mich jemand! (seufzt laut auf) Selbstverständlich, ich habe noch tausende Beispiele, aber ich bleibe mal bei einem. Eine User Story könnte lauten: Als Admin möchte ich nicht ernstgemeinte Mitfahrannoncen sperren, um den Missbrauch der Seite zu verhindern. Das Verb „sperren“ ist ein Schlüsselwort. Wer sperrt? Und warum? Wie kann das „Sperren“ durchgeführt werden? Ab wann wird gesperrt? Wie kann ich überprüfen, dass der Sperrvorgang erfolgreich war? Was könnte „Sperren“ verhindern? Welche möglichen Fehleingaben müssen beim Sperren abgefangen werden?
David Holzer: Können auch Substantive Schlüsselwörter sein?
Akzeptantkriterium: Ja klar doch. Auch Substantive können Schlüsselwörter sein. Die User Story „Als User des Interportals möchte ich Benachrichtigungen bekommen, damit ich sofort neue und passende Angebote  sehen kann. Das Substantiv „Benachrichtigung“ ist ein Schlüsselwort. Welche Inhalte sollen dort enthalten sein? Wie sieht das Layout einer Benachrichtigung aus? Welche Inhalte von „Benachrichtigung“ sind nach welchen Regeln zu prüfen? Alles klar?
David Holzer: Jetzt wird mir einiges klarer. Eine Frage drängt sich mir aber auf. Inwieweit gibt es einen Widerspruch bei der Qualität einer Userstory (INVEST) und dem, was Sie gerade über die qualitativen Anforderungen eines Akzeptantkriteriums erzählen?
Akzeptanzkriterium: Wenn man sich an die drei C – Card, Conversation, Confirmation – hält, dann gibt es tatsächlich zwei Seiten einer Medaille, um nicht sogar zu sagen, einen Widerspruch. Wieso I-N-V-E-S-T, wenn meine Akzeptanzkriterien eigentlich eindeutig, widerspruchsfrei und nachweisbar sein sollen? Wieso ist eine Userstory SMALL, wenn es so viele Informationen darüber braucht? Könnte man die nicht alle gleich reinschreiben, dann muss man nicht mehr so viel fragen? Schaut man jedoch genauer hin, dann ist es kein Widerspruch, sondern zwingend erforderlich und auch durchaus handhabbar und sinnvoll.
David Holzer: Das müssen Sie mir erklären.
Akzeptanzkriterium: Eine User Story hat nie den Anspruch auf Vollständigkeit. Nie. Die Kürze dient dazu, ein Verständnis zu erlangen. Alles, was danach kommt ist ein kommunikativer Austausch über das, was zwischen den Zeilen steht, also, das was die Schlüsselwörter betrifft. Keine schriftliche Dokumentation dieser Welt wäre dazu in der Lage das zu leisten, was ein gutes, ausgiebiges Gespräch zwischen einem Product Owner, dem Verfasser der US und seinem Entwicklungsteam, den Umsetzern der Inhalte der US, schafft. Kommunikation ist essentiell und DER Erfolgsfaktor verständlicher, eindeutiger und vor allem widerspruchsfreier Akzeptanzkriterien. Natürlich erfordert das Übung und damit auch Zeit. Zeit, die wir eigentlich gar nicht haben. Allerdings zeigt sich eins und das nachhaltig: Wenn du dir für die Kommunikation von Akzeptanzkriterien nicht ausreichend Zeit nimmst und Fragezeichen akzeptierst, dann sparst du bei der Zeit am falschen Ende. Die Konsequenz ist fehlende Qualität. Fehlende Qualität bedeutet unzufriedene Kunden. Und das braucht ja nun wirklich niemand.
David Holzer: Der Meinung bin ich auch. Danke für das Gespräch!

Profil gewinnen – Selbstcoaching für eine souveräne Ausstrahlung

Wer beruflich viel mit Menschen arbeitet, ist immer wieder mit der Frage konfrontiert: “Wie kann ich möglichst elegant Einfluss nehmen, um etwas zu bewegen? Wie schaffe ich es, dass andere mir zuhören, sich entsprechend meiner Vorstellungen bewegen, Regeln akzeptieren, Commitments einhalten?” Tatsächlichen, wirkungsvollen Einfluss zu haben, ist eng mit souveräner Ausstrahlung (Charisma) verbunden. Wer führen, beraten, verkaufen, coachen will, ist gut beraten, an einer positiven Ausstrahlung zu arbeiten und sein Profil zu „schärfen“. Oft behindern einschränkende Glaubenssätze wie „Eigenlob stinkt“ oder „Schuster, bleib bei deinen Leisten“ ein glaubhaftes Standing. Weg damit! Wäre ein Franz Beckenbauer zum „Kaiser“, ja zu einer „Lichtgestalt“ geworden, hätte er so von sich gedacht? Ganz sicher nicht.
 
Man muss also an sich glauben, Präsenz zeigen und bei aller Bescheidenheit selbstbewusst mit sich und anderen umgehen. Dazu einige Hinweise, wie man im Sinne von „Coach yourself“ die individuelle Ausstrahlung stärken und sein Profil schärfen kann.
 
1) Prüfe Deine mentalen Programme, identifiziere Blockierer (siehe oben) und flexibilisiere sie gezielt. Blockierer sind in der Regel als wahrnehmbare (Glaubens) Sätze gespeichert. Anstatt „Eigenlob stinkt“ kann ein Satz wie „ich kann mich offen und angemessen loben, wenn ich etwas beherrsche und meine Kompetenz zeige“. Auch ein Satz wie „ ich kann, was ich kann und brauche mich nicht zu verstecken“, kann hilfreich sein. Visualisiere Deinen Satz und trainiere ihn, bis er für Dich selbstverständlich wird. Erkenne es bewusst an, wenn Dir etwas besonders gut gelungen ist, wen Du erfolgreich bist oder warst. Du kannst Dich ruhig selbst loben.
 
2)  Bewege Dich in kniffligen Situationen ganz bewusst so entspannt wie möglich. Atme tief durch, in der Ruhe liegt die Kraft und sie strahlt positiv auf andere aus. Vermeide hektische verbale und nonverbale Signale und vermittle Deinem Gegenüber, dass Du Dir, auch wenn es kritisch wird, die Zeit nimmst, die Du brauchst. Identifiziere solche Situationen und programmiere Dich im Vorfeld darauf, möglichst locker und entspannt zu sein.
 
3) Nutze Deinen Körper, um Dich mental sicher, stabil und souverän zu machen. Jeder hat Gesten, Bewegungen, Haltungen gespeichert, die ein gutes, starkes Gefühl vermitteln. Achte darauf, was sich positiv verändert, sich gut anfühlt, wenn Du die Hände so oder so hälst, wenn Du Deine Füße fest auf den Boden stellst, wenn die Arme verschränkst usw. Du kannst mit dem bewussten Aktivieren solcher „somatischer Marker“ Dein Denken, Fühlen und Handeln direkt und situativ stärkend beeinflussen. Finde heraus, welche Deine positiven „somatischen Marker“ sind, und trainiere ihren Einsatz.
 
4) Finde visuelle oder materielle Ressourcenanker in Deinem unmittelbaren Umfeld (Arbeitsplatz), die eine positive und stärkende Botschaft für Dich haben und auf die Du jederzeit zugreifen kannst. Bilder, Farben, ein besonderer Stift, ein Schmuckstück, ein Song, ein Stein oder eine Muschel etc. Diese positiv besetzten Anker können die mentale und  emotionale Befindlichkeit unterstützen und sichern Deine gute Ausstrahlung. Je häufiger Dein Resssourcenanker für Dich im Einsatz ist, umso sicherer wirkt er in Deinem Sinne.
 
5) Nutze die drei „magischen“ Sätze bei ganz  besonderen Herausforderungen, in denen Deine Souveränität „in Gefahr“ ist.
„Ich will…..“,
„Ich kann…“
„Ich darf….“
Diese Sätze stärken Deinen Willen, zu bestehen und vorwärts zu gehen, fokussieren auf Deine Fähigkeiten, es zu können und zu schaffen und Du gibst Dir damit die Erlaubnis, gut zu sein und Standing zu zeigen. Sage Dir ganz bewusst in obiger Reihenfolge langsam und fokussiert diese Sätze, nimm wahr, was Du dabei siehst und erfährst, baue auf ihre Wirkung. Sie sind eine Art Trance zur Selbststärkung, die ganz natürlich ist und die z.B. im Leistungsport seit langem genutzt werden.
 
6) Zeige Humor, wann immer es passt, Andere zum Schmunzeln oder Lachen zu bringen, wird in allen Aussagen zum Thema Ausstrahlung als besonders wertvoll betrachtet. Auch ein Schuss Selbstironie beweist Standing und Souveränität. Humor kann trainiert und entwickelt werden, wenn Du bewusst witzige Impulse bei Dir wahrnimmst und artikulierst.
 
7) Halte zu Deinen Gegenübern sicheren Blickkontakt, ohne Sie zu fixieren. Schwinge Dich auf Sie ein und sorge für eine möglichst gleiche „Wellenlänge“. Deine Gesprächspartner akzeptieren Dich eher, wenn Sie, meist völlig unbewusst, eine verbale, mentale oder körperliche Übereinstimmung wahrnehmen. Motto: “Wen ich als relativ ähnlich erlebe, kann nicht mein Feind sein“ Das stärkt den sozialen Kontakt und öffnet den anderen für Deine Ausstrahlung.
 
DIe Neurowissenschaft hat sich in den letzten Jahren intensiv mit den Themen der genetischen Prägung versus Lern- und Entwicklungsmöglichkeiten befasst. Sie ist aktuell zu der Erkenntnis gekommen, dass wir zu ca. 50% von mentalen Mustern geprägt und 50% biographisch erlernt sind. Das heißt, dass auch solche individuellen Persönlichkeitselemente wie Ausstrahlung (Charisma) gezielt in jedem Alter beeinflussbar sind und weiterentwickelt werden können. Das erfordert Selbstreflexion, eine klare Zielsetzung und immer wieder Training, d.h. Wiederholung. Eine strake und positive Ausstrahlung ist sicher ein Schlüssel für Erfolg, sei es beruflich oder privat.
 
Tipp: Trainings mit Dieter Rösner für souveränes Auftreten und Handeln. Alle Termine hier.

Interview mit einem Akzeptanzkriterium (Teil 1)

Das Konzept der User Story als Werkzeug für die Beschreibung und das Management von Anforderungen in agilen Softwareprojekten ist überwiegend anerkannt,  weit verbreitet und hat sich erfolgreich etabliert. Verglichen mit traditionellen Mitteln des Anforderungsmanagements geben User Stories Raum für Änderungen und unterstützen dabei, ein System entstehen zu lassen, das der Kunde tatsächlich will. Und eben keines, das zwar vor einem Jahr „in“ war und spezifiziert wurde, heute aber bereits von den dynamischen Entwicklungen eines schnelllebigen Marktes überholt und schon wieder „out“ ist.
Leider gibt es diesbezüglich noch kein kongruentes Meinungsbild. Denn auch wenn die Unschärfe einer User Story wesentlicher Teil ihrer Erfolgsgeschichte ist, so ist es eben genau diese Unvollständigkeit, die von vielen Entwicklungsteams noch nicht ausreichend als Einladung zur Konversation verstanden wurde. Um die Kluft zwischen Offenheit auf der einen und Konkretheit auf der anderen Seite zu überwinden, muss das Entwicklungsteam seinem Product Owner etwas versprechen: Dass es sich nämlich detailliert über die jeweilige User Story unterhält und im gemeinsamen Dialog kleine Feedbackschleifen etabliert, die zu einem gemeinsamen Verständnis führen sollen, wann eine Userstory tatsächlich vollständig umgesetzt und auf der Basis der Definition of Done „fertig“ ist.
bor!sgloger-Reporter David Holzer hat sich zu diesem Thema auf den Weg nach Backlogsen gemacht, um sich mit der Person zu treffen, die für viele Entwickler zu den wichtigsten Anhaltspunkten dafür gehört, was denn eigentlich beim Umsetzen von User Stories zu tun ist. Dieser Jemand konkretisiert im Sinne einer Leitplanke das Ziel einer User Story und ist für Tester und Product Owner ein wichtiges Hinweisschild für die Durchführung von Akzeptanztests, nachdem die Story (fertig) entwickelt und integriert wurde: das Akzeptanzkriterium.
David Holzer: Hallo, es ist schön, dass Sie meiner Einladung gefolgt sind. Für unsere Leser würde ich Sie kurz bitten, sich vorzustellen und zu umreißen, wer Sie eigentlich sind.
Akzeptanzkriterium: Ja, erst mal vielen Dank. Und es tut gut, dass Sie sich die Zeit für mich nehmen. Wissen Sie, ich werde nämlich ziemlich oft übergangen oder komme zu kurz oder oder … Stellen Sie sich vor: Manchmal werde ich sogar vergessen! Fast immer nehmen sich die Leute viel zu wenig Zeit für mich und reden immer nur sehr oberflächlich über mich. Dabei bin ich doch die Geschäftsregel, die eine User Story konkretisiert! Ich beschreibe doch das Verhalten einer User Story aus Sicht des zugrundeliegenden Geschäftsmodells! Aber irgendwie geht das im Eifer des Gefechts häufig unter (seufzt tief).
David Holzer: Vielleicht kann ich Ihnen mit meinen Fragen ja dabei helfen, dass dieser Missstand in Zukunft nicht mehr auftritt. Was tun sie außerdem?
Akzeptanzkriterium: Ich beschreibe außerdem eine konkrete Eigenschaft einer User Story. Damit gebe ich die Grenzen der User Story vor. Kurzum: Ich sage an, ob etwas „in scope“ oder „out of scope“ ist. Ich bin ja nicht so streng: Ich lasse bei den Inhalten doch mit mir verhandeln. Ehrlich gesagt liebe ich den Dialog, das finde ich einfach super, wenn die Menschen in einem Team miteinander reden. Mit diesem Dialog helfe ich bei der Antwort auf die Frage, wann eine User Story „fertig“ ist.
David Holzer: Das klingt nach einer sehr verantwortungsvollen Funktion, die Sie da haben. Ich wette, das ist noch nicht alles?
Akzeptanzkriterium: Na und ob das noch nicht alles ist! Stellen Sie sich vor, ich bin auch noch ein Bindeglied zwischen User Stories und Testfällen. Dazu werde ich Ihnen aber später noch was erzählen. Recht oft werde ich als Hilfsmittel zum Schneiden von User Stories genutzt. Also, gut … ich gebe zu: Da kann ich manchmal schon recht zickig sein. In diesem Bereich ist der Umgang mit mir nicht ganz so leicht, weil das die Fähigkeit erfordert, die richtigen Fragen zu stellen. Aber ich denke, ich greife schon etwas voraus.
David Holzer: Das ist eine ganze Menge und ich denke, dass diejenigen, die Sie erarbeiten sollen, keine einfache Aufgabe vor sich haben. Wer tut das? Wer erarbeitet Sie?
Akzeptanzkriterium: Kurze Frage, kurze Antwort. Der Product Owner erarbeitet mich hoffentlich gemeinsam und in Abstimmung mit bzw. inspiriert durch die Fragen seines Entwicklungsteams.
David Holzer: Product Owner – ein gutes Stichwort. Ich habe in meiner Recherche für dieses Interview gelesen, dass Akzeptanzkriterien die Erwartungen des Product Owners an eine User Story beschreiben. Stimmt das und wenn ja, was genau ist damit gemeint?
Akzeptanzkriterium: Wer auch immer das geschrieben hat, der trifft den Nagel auf den Kopf: Ich beschreibe die Erwartungen des Product Owners an eine User Story. Das Aufschreiben dieser Erwartungen geschieht aus zwei Gründen: Erstens ist der PO gezwungen, gut darüber nachzudenken, bevor er seine Erwartungshaltungen präzise formulieren kann und wird auf diese Weise zu einer intensiven Vorbereitung gezwungen. Zweitens unterstützen klar formulierte Erwartungen das Entwicklungsteam, den Inhalt der Story wirklich zu verstehen.
David Holzer: Und wann…
Akzeptanzkriterium (unterbricht den Reporter): Entschuldigen Sie bitte, aber das möchte ich noch hinzufügen. Ich bin ein wirklich ruhiger Zeitgenosse und es gibt kaum etwas, was mich aus der Haut fahren lässt. Aber lassen Sie mich noch etwas dazu sagen, weil mir das schon so so so lange auf dem Herzen liegt. Liebe POs da draußen in der Agilen Welt: Ich bin NICHT die Kür! Ich bin die Pflicht, eure Pflicht! Wenn eure Teams mich nicht vorliegen haben, dann ist eure Story unzureichend vorbereitet und kann vom Team abgelehnt werden. Das heißt WAS? Dass eure Priorisierung hinfällig ist und das, meine lieben POs, kostet wiederum Zeit und Kraft und stiftet nur Verwirrung. Niemand verlangt von euch, dass ihr euer Backlog komplett alleine füllen müsst. Ich weiß ja gar nicht, wieso ihr das tut. Um relevante Inhalte über mich zu erhalten, müssen ALLE Beteiligten zusammenarbeiten. Alle! Und das bedeutet, dass man auch über die Story mit allen spricht! So, jetzt geht es mir ein wenig besser.
David Holzer: Kein Problem. Ich denke, dass es wichtig war, dass Sie das noch mal betont haben. Jetzt zu meiner Frage: Wann genau passiert das dann – das Erarbeiten von Akzeptanzkriterien?
Akzeptanzkriterium: Zu zwei unterschiedlichen Zeitpunkten. Die erste gemeinsame Erarbeitung findet im Estimation Meeting statt oder zumindest dann, wenn über User Stories, die dem Entwicklungsteam noch nicht so ganz klar sind, verhandelt wird. Häufig führen die Gespräche über mich dazu, dass User Stories kleiner geschnitten und damit verständlicher für alle werden. Ein tolles Gefühl. (Akzeptanzkriterium strahlt)
David Holzer: Und wann noch? Sie haben von zwei Zeitpunkten gesprochen.
Akzeptanzkriterium: Da ist aber einer ungeduldig (kopfschüttelnd). In den Sprint Plannings natürlich. Im Sprint Planning I komme ich zur Sprache, wenn das Was verhandelt wird. Ich tauche gerne in den Anforderungen auf, aber auch in Constraints oder den Kriterien, die der Product Owner dafür definiert hat, unter welchen Bedingungen er eine Story abnimmt. Und bevor Sie weiter fragen, komme ich natürlich auch im SP2 zur Sprache. Wie sage ich immer: Design ohne Fragen zum Akzeptanzkriterium ist wie Fußball ohne Tor – langweilig und sinnlos. Gut, es soll Leute geben, die finden auch Fußball mit Tor langweilig. Sie nicht auch?
David Holzer: Ich bin eigentlich eher ein Handball-Fan, aber ja, stimmt: Weder Handball noch Fußball sind ohne Tore sonderlich spannend. Aber zurück zu Ihnen: Ich stelle mir das allerdings nicht so einfach vor. WIE geht die Erarbeitung vonstatten?
Akzeptanzkriterium: DAS ist ein wirklich gute Frage. Hier trennt sich die Spreu vom Weizen, was ein gut erarbeitetes Akzeptanzkriterium ist und was eines ist, das keiner versteht oder falsch versteht und dann auch noch falsch umsetzt: Das A und O ist die Vorbereitung des Product Owners. Wenn ich allerdings von guter Vorbereitung spreche, dann meine ich nicht, dass Mr. Product Backlog seinen Katalog an Akzeptanzkriterien im stillen Kämmerlein definiert, dokumentiert und schließlich der Weltöffentlichkeit präsentiert, sondern: Wenn ich eines in den letzten Produktentwicklungsprozessen gelernt habe, dann, dass keine  schriftliche Dokumentation den Wert der verbalen Kommunikation ersetzt. Und damit meine ich NICHT Selbstgespräche, sondern die Kommunikation des PO mit seinem Entwicklungsteam und anderen Product Ownern und Fachleuten und und und. Wenn man mich fragt, WIE man mich am Besten gut und nachvollziehbar erarbeitet, dann sage ich nur drei Worte: Feedback, Feedback, Feedback.
 
Seien Sie auch nächstes Mal wieder dabei, wenn David Holzer das Akzeptanzkriterium fragt:
Wie und womit werden Akzeptanzkriterien erarbeitet?
Welche Fragen muss ich mir als Product Owner und Entwicklungsteam dabei stellen?
Was sind die Merkmale „guter“ Akzeptanzkriterien?


Hier geht es zu Teil 2 des Interviews.

Der Sinn des Dilettantismus in der agilen Produktentwicklungswelt

“Für sinnkonstituierende Systeme hat alles Sinn.“ (N. Luhmann)
Soll heißen: Auch der scheinbare Unsinn besitzt eine sinnstiftende Funktion.
In dem Artikel “Dem Amateur ist nichts zu schwör” aus dem Magazin der Süddeutschen Zeitung (Nummer 24/ 20120615), wird der Scheinwerfer auf die Dilettanten in der Politik, Wirtschaft und Wissenschaft gerichtet und auf das Faktum, dass nervige und zunächst substanzlos wirkende Fragen oftmals zum Nach- und Neudenken bewegen.
Berichtet wird unter anderem über das in New York beheimatete “Genspace”. Dabei handelt es sich um ein Labor, dessen Team aus Künstlern, Programmierern und einem einzigen Biologen besteht, das an zunächst sinnfrei erscheinenden Themen/Produkten forscht/entwickelt. Zum Beispiel möchte man, dass Zellen das tun, was man ihnen befiehlt oder dass Bakterien bei Schwarzlicht bunt leuchten. Zur Vorbereitung bekommen die Laien einen Einführungskurs in Genforschung und dann … werden sie losgelassen.
Es existieren nicht viele Gesetze, best practices, Rituale (auch verhaltensbasiert) dazu, was und wie man “es” tut. Dadurch existieren auch die in der Vergangenheit von den “ausgebildeten Experten” aufgestellten Denkblockaden – oder nennen wir es “creative thinking in a jail” (Kreativität des Denken in einer Gefängniszelle) – nicht. Einen Beweis, dass ein Dilettantenteam etwas Gehaltvolles liefert, ist am Anfang nicht möglich. Es braucht Pioniere mit Mut, Courage und Verstand die es: einfach mal machen.
Naja die Süddeutsche würde aber nur ungern so etwas ohne Bewies veröffentlichen und hat bis heute gewartet, um ihre Leser mit Sicherheit einzulullen:
Vor Zwei Jahren wurde ein Artikel in Nature, dem wichtigsten Wissenschaftsmagazin der Welt, veröffentlicht, dessen Ergebnisse teilweise von Amateuren stammten, die in einer Art Computerspiel die Struktur von Proteinsträngen analysiert hatten.”

Tipps vom Dilettanten?

Ich erlebe in meiner Arbeit häufig Meetings, bei denen vermeintliche Dilettanten Feedback und Verbesserungstipps zu einem hochkomplexen Produkt geben, das soeben von – zumindest für dieses Produkt – gestandenen Professionellen gebaut wurde. Es sind die Reviews, in denen das Scrum-Team auf die User und Stakeholder trifft, um aus dem Meeting Input & Improvements mitzunehmen. Nun erlebe ich im Anschluss der Vorstellung eines ProduktInkrements öfters, wie Wünsche, Fragen, und Feature-Ideen aus dem Dilettantenkreis auftauchen, an die die Entwickler keinen Gedanken “verschwenden” und direkt abwinken: “absurd”, “unmöglich”, “epic lol”…
Warum?
Sie bedienen sich des manifestiert Erlernten, bewegen sich somit in ihrem “creative thinking in a jail”, das genug Gesetze, Rituale, best practices kennt, um diese Ideen lebenslänglich in Einzelhaft zu nehmen. Mit viel Glück bekommt man noch ein “Jaaaa, in 10 Jahren vielleicht…” und sofort darf ich eine Frage stellen: “Was müsste denn bis dahin geschehen?” Das ist eine typische Frage, die in Startup-Unternehmen der Trigger ist, um innovative Produkte mit kreativen Lösungen für die Welt zu finden. Es ist die Freiheit, den Sinn der Gegebenheiten einmal zu ignorieren und seiner Kreativität dabei zu helfen, auszubrechen. Lösungen tatsächlich “out of the box” finden zu müssen.

Dilettanten sind Erneuerer

Die Süddeutsche erinnert an folgende Tatsache: “In der Kulturgeschichte galten Dilettanten lange Zeit als Erneurer.” Es ist nicht einfach, die Sinnfreiheit und den Dilettantismus zu nutzen, aber damit wir bei agiler Produktentwicklung wirklich etwas Neues schaffen, sollten wir es einfach mal machen.
Es war ja auch schon immer sinnfrei Jazz und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Electromusic-Dilettanten Klaus Waldeck.
Es war ja auch schon immer sinnfrei, Klassik und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Klassik-Dilettanten Henrik Schwarz.
Oder hört einfach mal in eure Produkte hinein. Um der Süddeutschen zu huldigen: Die beiden haben sich heute schon bewiesen und ihre Produktionen werden teilweise auf den wichtigsten Labels der Welt veröffentlicht.

Trau, schau, wem – vom Umgang mit Vertrauen in Teams

„Seit ich ScrumMaster bin, vertrauen mir meine Kollegen weniger als vorher. Was kann ich tun?“ Diese Aussage einer Trainingsteilnehmerin taucht so oder so ähnlich immer wieder mal auf. ScrumMaster  wünschen sich in der Regel „doppeltes Vertrauen“: Zum einen als Person und zum anderen in ihre neue Rolle. Vertrauen ist in der Teamarbeit äußerst wichtig, es ist eines von drei Einflusselementen lateraler Führung, neben Macht und Verständigung. Vertrauen reduziert Komplexität, macht salopp gesagt das Leben und Arbeiten einfacher, z.B bei Entscheidungsprozessen.
Wollt ihr als ScrumMaster Vertrauen aufbauen und pflegen, können euch die 8 K´s des Vertrauensaufbaus sehr behilflich sein.

„Man darf nicht unterstellen, dass Vertrauen im Lernprozess kontinuierlich wachsen und sich bruchlos auf immer wichtigere, folgenreichere Angelegenheiten ausdehnen kann.“ (N.Luhmann, „Vertrauen“ Enke Verlag, 1989). Der Aufbau und die Pflege von Vertrauen ist ein permanenter Prozess. Nimm Dein persönliches Vertrauensmanagement bewusst in die Hand, achte auf die besagten 8 K´s, die in engem Zusammenhang zueinander stehen. Lass den anderen in Deinem Scrum-Umfeld die Zeit, die sie brauchen, um Dir angemessen vertrauen zu können.
TIPP: Die Werkzeugkästen für laterale Führung und gute Teamarbeit – die ScrumMaster Pro Trainings
Neu im Programm: KonfliktManagement – Soziale Konflikte erfolgreich bewältigen und moderieren

Practice what you preach – warum es so wichtig ist, das scheinbar Offensichtliche auszusprechen

Zu meinem Geburtstag hatte ich extra Kuchen gebacken und in Anbetracht der Umstände (ich backe ca. ein Mal im Jahr) war der sogar so gut geworden, dass ich ihn meinen Kunden zumuten konnte. Direkt nach dem Daily und Estimation Meeting schnitt ich den Kuchen also auf, und stellte meinem Team genau 5 Stücke ins Büro. Erst dann versorgte ich den erweiterten Kreis, und gab den Rest in der Küche zur freien Verfügung frei. Da ich niemandem Platz rauben wollte, hatte ich den Kuchen samt ausreichend Teller und Besteck auf meinem Schreibtisch platziert. Zu Mittag nahm ich mir ein Stück, da ich den Kuchen der Kantine oder dem Bäcker vorzug und wunderte mich noch, warum sonst niemand zugriff.
 
 
Als ich dann um 15 Uhr von einem Termin wieder zurück ins Büro kam, und der Kuchen so wie zwei Stunden zuvor unangetastet auf meinem Platz stand, fragte ich etwas beleidigt, warum sie denn meinen Kuchen so verschmähen würden. Die verblüffende Antwort: „Wir wussten nicht, dass der Kuchen für uns gedacht war und haben uns schon gewundert, warum Du so viele Stücke für Dich alleine haben wolltest.“  Eines der Teammitglieder hatte sich sogar ein Stück von dem „Rest“ aus der Küche genommen, da es für ihn dort offensichtlich war, dass der Kuchen zur Selbstbedienung bereitgestellt war.
 
Nach der ersten überwundenen Enttäuschung “Die denken wirklich von mir, dass ich ihnen keinen Kuchen geben würde und lieber 5 Stücke alleine esse”, habe ich mich daran erinnert, wie oft ich schon Product Ownern, Managern aber auch Teammitgliedern gesagt habe, wie wichtig es ist, Dinge auszusprechen. Und nun war ich selbst in die Selbstverständlichkeits-Falle getappt.
Ja, es ist verdammt schwer über den Schatten seiner eigenen Realität zu springen aber es lohnt sich jedes Mal. Viel Spaß beim sich Verstehen.

Hey PO, estimate your roadmap!

Über die “Cone of Uncertainty” hat Boris Gloger ja schon mehr als ein Mal geschrieben. Zum Beispiel hier und hier. Aber schauen wir sie uns einfach noch einmal an.
Die Y-Achse definiert den Faktor Schätzungsvarianz bzw. Eintrittswahrscheinlichkeit bzgl. Einhaltung des geschätzten Projektziels/ -ende. Die X-Achse stellt die Timeline /Lifeline des Projekts dar. Der Iceberg, als metaphorische Visualisierung zur Granularität des Product Backlog, wurde in  “Succeeding with Agile: Software Development Using Scrum” (2009, Mike Cohn, Addison-Wesley Longman, Amsterdam) beschrieben.
 
 
An der Oberfläche, über dem Wasser, liegt die Spitze des Eisbergs, die sich aus klar ersichtlichen User Stories (US) zusammensetzt.

Was bedeutet “klar ersichtliche User Stories”?

Die User Stories sind jeweils sprintgerecht geschnitten und somit für den Product Owner genau einkalkulierbar. Sie enthalten kleine Features/Funktionalitäten, Raffinessen und Risiken sind bekannt und wurden gemeinsam mit dem Team besprochen. Trennt man diese Eisbergspitze, erhält man einen growler (deutsch: Minieisberg), der für sich die nächsten 6-8 Wochen klar identifizierbare, priorisierte und somit der Reihenfolge nach getaktete Produktinkremente enthält.  Als PO sollte es mir leicht fallen “denen da oben” (deutsch: dem Management), einen Forecast (Zeitpunkt, Risiko, Ressourcenbedarf) bzgl. der Fertigstellung der Features/Produktinkremente für die nächsten 3 – 4 Sprints zu liefern. D.h. der PO kann mit gutem Gewissen einen Report über den nächsten growler erstellen und in die Managementssphäre senden.

Nun bricht die Realität die romantische Literatur der leidenschaftlich agilen Autoren.

Auf der Managementebene wird dieser growler nicht als US-Bundle voller schöner und/oder innovativer Features wahrgenommen, bei dem sogar der CFO jauchzend das Budget um die nächste X-Stelle aufstockt. Das Riskmanagement erhält die Eiswürfel der einkalkulierten Risiken, das Controlling gleicht den Kosten-Eiszapfen mit der Länge und Breite des im Kennzahlenkatalog erstellten Abbilds ab und das Releasemanagement tippelt nervös über den growler, um zu schauen, wie weit (Zeit) und wie sicher (uncertainty, probability) sie ihn betreten können. Sie bezeichnet den growler als: milestone.
Hat der PO einen guten Job gemacht (hier ist Voraussetzung, dass er von der gesamten Company grenzenlosen Informationszugang erhält; auch von Sales und Marketing), werden die oben genannten Managementebenen bis zum Ende des growlers bzw. bis zum milestone, bestmöglich informiert sein.

Es wird aber nicht reichen.

Das Management möchte nun mehr als den growler. Das große Ganze, das Projektziel mit Themes & Epics soll an einer Timeline entlang zu ihrer Deadline finden, wobei die eine Argumentation zum Progress durch Meilensteine definiert werden soll. Anforderung an diesen Plan: 100% Eintrittswahrscheinlichkeit. An dieser Stelle wäre es einfach zu sagen: “Werte Führungsprominenz “da oben” – realisiert die romantische Literatur der leidenschaftlich agilen Autoren, und lasst es gut sein.”
Aber aus der Frage wird eine Bitte und aus der Bitte noch viel schneller eine Anweisung mit Deadline, einen Releaseplan zu kreieren.
CUT. 
Please, think out of the box. 
If you can`t create a foolproof releaseplan, go ahead foolproof and freeze the rocky future by estimating an icecold roadmap.

Die unfassbare Ausweitung am Fuße des monumentalen “Eisbergs” ist analog zum Beginn des “Cone of Uncertainty”. Die unaufgeschlüsselten Epics befinden sich auf dem Level des “initial concepts”. Die Spitze des “Eisbergs” ist analog mit dem Ende des “Cone of Uncertainty”. Mit den sprintgerechten US entwickelt das Dev-Team funktionierende Software und erreicht den Level “software (increment) complete”.  Demnach kann die bestehende Schätzung des Titanic-Icebergs mit einer Schätzungsvarianz von Faktor 4/ -0,25 berechnet werden. D.h. dass “(…) das Budget um ca. 200% bis 400% überschritten und durch das Projekt in der Regel nur 25% bis 50% des erwarteten Nutzens entsteht (…)”  (Boris Gloger, http://borisgloger.com/2011/10/24/schatzen-lassen-wir-es-einfach/)
Nun bitte, dann stoßen wir den gesamten Titanic-Iceberg um und lassen die Welt auf Zehen humpeln … Die iterative Aufschlüsselung der Epics liegt soweit in der Zukunft, bis der Zeitpunkt erreicht ist, zu dem Sicherheit herrscht “ob” bzw. “was” (Themes) und wiederum später “was genau” (US) der PO umgesetzt haben möchte. Somit liegt der umgestoßene “Eisberg” auf der “Cone of Uncertainty”.
Der PO setzt nun den growler bzw. den milestone (Skizze: growler = blaue “Spitzen” ; milestone = grüne “Balken” ) und schätzt seine Roadmap, die ebenso dynamisch ist wie die bisherigen MS-Project-Pläne (mit der Ausnahme, das nun eine absichtliche Dynamik zu erkennen ist). Die Dynamik des Eisbergs ist ein Strom, angetrieben von der Kommunikation des PO und Dev-Teams, bei dem die unten liegenden EPICs auf ihrem Weg zur Spitze in immer feineren, schärferen Inkrementen aufbrechen.
Dadurch entwickelt sich immer wieder eine neue Spitze, die wieder als milestone gesetzt und umgesetzt wird.
Mit diesem iterativem Projektfortschritt wird der gesamte Eisberg kleiner, durchsichtiger und die Schätzungsvarianz des “cone of uncertainty” nähert sich analog dazu dem Faktor 1.

Scrum oder die Kunst, mit Komplexität umzugehen

Ameisen und Software

Was haben Ameisenkolonien mit Scrum-Teams gemeinsam? Ameisenkolonien sind hochproduktiv, selbstorganisiert und cross-funktional: 50% beschaffen Nahrung, 25% bewachen die Kolonie, und 25% entfernen Dreck. Jede Ameise kann jede Aufgabe machen. Es gibt keine zentrale Vorgabe oder Planung, aus der die Ameisen ihre Aufgaben ablesen könnten. Sie erkennen anhand von chemischen Botenstoffen, was ihre Kollegen im unmittelbaren Umfeld machen – und passen sich entsprechend an. Gibt es schon genug Nahrungsbeschaffer, kann eine solche Ameise zum Wächter umsatteln.
Es gibt noch mehr Parallelen: Ameisenkolonien sind komplexe Systeme, weil ihre Struktur nicht in Form von Ursache-Wirkung oder Vorgabe-Umsetzung verstanden werden kann. Sie entsteht vielmehr durch die Aggregation von vielen einzelnen, individuell getroffenen Entscheidungen (wer sich in die Ameisenwelt vertiefen will: hier eine sehr spannende Dokumentation).
http://www.youtube.com/watch?v=z3qz84yqwds&feature=youtu.be
Softwareentwicklung ist ebenfalls komplex. Stellt ein Expertengremium zusammen, bestehend aus den besten Entwicklern, Testern und Fachleuten der Welt. Sperrt das Gremium drei Monate ein mit der Aufgabe, eine detaillierte Bauanleitung für ein mäßig anspruchsvolles Softwareprodukt zu entwerfen. Ich bin überzeugt: Die Experten würden grandios scheitern.
Denn jede kleine Veränderung im technischen Entwicklungsprozess, jede minimale Abweichung von den fachlichen Anforderungen, jede noch so geringe Modifikation in den rechtlichen Rahmenbedingungen, kann eine Lawine an Veränderungen lostreten.
Vor einem halben Jahr genau so erlebt: Das Entwicklungsteam versteht eine User Story ein wenig anders als vom Product Owner gewollt, setzt sie folglich mit Abweichungen um, stößt dabei auf einen bis dahin unbekannten Fehler in einer Kalenderfunktion, und entdeckt im Zuge des darauf folgenden Bugfixing eine neue Implementationsmöglichkeit für Timestamps, die auch fachlich höchst interessant ist, weil sie für den Kunden mehr Komfort bei der Bearbeitung von Personalfällen bietet. In der Folge wird das Product Backlog in wesentlichen Zügen umgeschrieben, um von dieser neu entdeckten Möglichkeit Gebrauch zu machen.
Übrigens muss nicht alles, was schwierig zu verstehen ist, deshalb auch gleich komplex sein. Ein mechanisches Uhrwerk mit ewigem Kalender ist ein hochkompliziertes Gebilde – es braucht jede Menge Wissen, um seine Funktionsweise zu verstehen. Haben wir jedoch das Wissen, können wir das Verhalten des Uhrwerks und seiner Teile durch Beschreibung von Ursache-Wirkung sehr genau vorhersagen und eine taugliche, reproduzierbare Bauanleitung schreiben.

Planung ade?

Die Erkenntnis, dass es für Softwareprodukte keine solche Schritt-für-Schritt-Bauanleitung geben kann, wird bisweilen als Vorwand für eine “anything goes”-Philosophie verwendet. Dort heißt es dann, planmäßiges Arbeiten mache keinen Sinn, weil wir eben keinerlei Gewissheiten mehr haben. Das aber ist ein Trugschluss. Wenn ich keine sicheren Voraussagen machen kann, heißt das noch lange nicht, dass ich im Dunkeln tappe. Es bedeutet nur, dass meine Annahmen oder Hypothesen mit einer (nicht unbeträchtlichen) Wahrscheinlichkeit falsch sein können.
Wie ist damit umzugehen? Indem Hypothesen so konstruiert werden, dass sie sich in möglichst kurzen Zeitintervallen durch die Praxis verifizieren und validieren lassen. Und indem wir dazu bereit sind, unsere Annahmen über Bord zu werfen, sobald sie sich als unhaltbar erweisen. In Scrum nennen wir solche Annahmen User Stories. Wir gehen davon aus, dass der Nutzer des Produktes eine Funktionalität haben will, weil er davon einen bestimmten Nutzen haben wird. Und fragen ihn regelmäßig, indem wir ihn die neue Funktionalität zum Ausprobieren geben, ob dieser Nutzen tatsächlich eintritt.
Neulich herrschte bei einem unserer Projekte große Aufregung: Verbunden mit einem neuen Großkunden hatten sich die Anfragen auf eine Datenbank  vervielfacht und zu erheblichen Performance-Problemen geführt, die der Kunde deutlich zu spüren bekommen hatte. Infolgedessen wurde das zuständige Scrum-Team zusammengetrommelt und gefragt, was es innerhalb des nächsten, zweiwöchigen Sprints an Lösungen bereitstellen könne. Manche Teammitglieder empfanden diesen Auftrag als Zumutung, denn es gab zu jenem Zeitpunkt keine produktionsnahe Testumgebung, auf der die Fehler auf der Datenbank zuverlässig hätten reproduziert werden können. “Wir können so nichts beweisen, sondern müssen wild vermuten, was die Performance-Probleme verursacht”, lautete der Einwand.
Aus den wilden Vermutungen entstand ein gemeinsames Brainstorming, und daraus wiederum ergaben sich Arbeitshypothesen in Form von kurzfristigen Lösungsansätzen. Das Team setzte sich für die Dauer eines zweiwöchigen Sprints zusammen, probierte seine Hypothese durch Umsetzung aus. Am Ende der zwei Wochen gab es eine Review: Was hatte funktioniert, was nicht, worauf sollte aufgebaut werden? Die akuten Probleme konnten in diesen zwei Wochen tatsächlich gelöst werden – der Kunde bekam von den Performance-Problemen nichts mehr zu spüren. Zugleich hatte die beinahe-Katastrophe das Bewusstsein für ein vorbeugendes Handeln geweckt. Am Ende dieses Reviews hingen über 100 weitere Lösungsansätze an der Wand. Auch hier galt es zu klären: Was davon wollen wir in den nächsten Wochen umsetzen und was lassen wir erstmal stehen?
Softwareentwicklung ist in der Tat eine Zumutung. Es geht immer wieder um das Gleiche: Die Unwägbarkeiten des Alltags irgendwie in den Griff zu bekommen. Wer versucht, alles im Vorhinein zu klären, der investiert viel Zeit und Denken in etwas, das am Ende sowieso anders kommen wird. Wer im Gegenteil ganz auf das Planen verzichtet und unreflektiert loslegt, der wird am Ende überall ankommen – nur nicht dort, wo er sein möchte. Der gangbare Weg liegt dazwischen: Planen ja, aber in Form von klar formulierten, verifizierbaren Annahmen, die in kurzen Intervallen bestätigt oder eben enttäuscht werden. Das, zusammen mit der Bereitschaft zum ständigen Überdenken des eigenen Standpunktes, macht den Umgang mit Komplexität beherrschbar. Nicht nur für Ameisen.

Der Product Designer als rechte Hand des Product Owner?

Die Anforderungen an den Product Owner sind immens hoch. Je nach Produkt und Zuständigkeit übernimmt er eine große Verantwortung: Einerseits aus der Sicht des Business Value und der Steigerung der Produktattraktivität für den Kunden, anderseits aus der organisatorischen Sicht. Er muss den Überblick über die Termine mit Kunden halten, Kundenkontakt halten, um Anforderungen entgegenzunehmen und entsprechend im Backlog zu verorten. Schon allein die Pflege des Backlogs und der dazugehörigen Formierung der Anforderungen an das Team ist eine hohe Belastung. So fangen immer mehr Unternehmen damit an, ihre „ehemaligen“ Product Designer (PD) als „rechte Hand“ des PO einzusetzen. Die PDs schreiben Feinkonzepte, halten den Kontakt zum Kunden und arbeiten dem PO zu.
 
Vom Gedankengang her gar nicht so falsch. Der PD als Sparring Partner – als jemand, der mitdenkt, überprüft und gestaltet. Gleichzusetzen mit der Zusammenarbeit, die wir ja auch in den ScrumTeams finden. Aber kritisch zu sehen: Durch das Zuarbeiten des PD führen wir eine unnötige Hierarchieebene ein.
Die Verantwortlichkeit des PO verändert sich: Er ist „nur noch“ derjenige, der auf dem Backlog sitzt und die Zuarbeiten kontrolliert. Wie könnte eine Lösung aussehen? Beispielsweise kann man darüber nachdenken, wie man das Produkt in einzelne Komponenten oder Projekte aufteilt, um die Arbeit für einen PO „mundgerecht“ zu machen. Dabei bleibt unbestritten, dass die Verantwortlichkeit des PO hoch ist und er auch mit dem Abspecken seiner Rolle ein Workaholic ist und bleibt.
 
Wir reden von Selbstorganisation und Emanzipation der Teams: Also auch Teammitglieder können Storys schreiben. Eine große Entlastung für den PO.

Schleppst du noch oder surfst du schon?

Neulich habe ich bei einem großen Einrichtungshaus eine Kommode gekauft. Online. Nach der Bestellung kam eine E-Mail mit der Auftragsbestätigung und dem voraussichtlichen Lieferdatum. Dann habe ich eine Woche lang nichts mehr gehört. Nach acht Tagen (zwei vor dem voraussichtlichen Lieferdatum) lag plötzlich ein Zettel in unserem Briefkasten: Die Sendung konnte leider nicht zugestellt werden. Abholung am nächsten Tag in einer Filiale der Deutschen Post. Dort durfte ich dann das kolossale Paket in Empfang nehmen und den Preis in bar begleichen. Im Webshop selbst gab es keine Bezahlfunktionalität.

Einkaufen kann mühsam sein.

Zunächst waren es nur Bücher und Nischenprodukte, mittlerweile lässt sich (fast) alles über Webshops verkaufen. Der Einzelhandel hat längst verstanden, wie wichtig das Internet als Verkaufsplattform ist. Allerdings machen viele Händler einen entscheidenden Fehler: Sie gehen ins Internet, um dort auch mal vertreten zu sein. Sie sehen im Aufbau eines Webshops ein wertvolles Add-On,eine funktionale Ergänzung zu ihrer bestehenden Verkaufsstrategie, aber kein eigenständiges Produkt.
Dieser Denkfehler kommt nicht von ungefähr. Das Produkt des klassische Einzelhändlers besteht ja darin, das Einkaufen in reellen Räumen zu einem einzigartigen Erlebnis zu machen. Von der Konzeption des Gebäudes über die Einrichtung der Ausstellungsräume bis hin zur Beratung und Nachbetreuung – es gehört so vieles dazu! Ein Webshop ist da ungleich leichter zu bauen. Einen anständigen Katalog, ein funktionierendes Bestellsystem und irgendwie noch die Zahlungsabwicklung. Mehr braucht es doch nicht. Oder?

Einkaufserlebnisse sind auch online möglich.

Marty Cagan hat uns mit Inspired gezeigt, dass und wie großartige Produkte in der Software möglich sind. Für umsonst gibt es die freilich nicht – vielmehr gilt es, gewisse Prinzipien zu beherzigen.
Teste deine Produktideen – möglichst früh und immer wieder – am Kunden! Hol dir einen Produktmanager, der das Produkt, die neuesten technischen Möglichkeiten und den Markt versteht! Und, vor allem: Sieh zu, dass Produktmanagement und Entwicklung Schulter an Schulter arbeiten, damit das richtige Produkt auch richtig gebaut wird!
Wir nennen den Produktmanager Product Owner, weil er letzlich für die Gestaltung des Produkts verantwortlich ist. Der Product Owner bildet zusammen mit seinen Entwicklern, Testern, und weiteren Spezialisten ein Scrum-Team. So ist nicht nur der ständige Austausch gewährleistet, sondern auch die Ausrichtung hin auf ein gemeinsames Ziel: Die Lieferung eines Produkts, das die Kunden lieben werden.
Der Erfolg oder Misserfolg des Produkts zeigt sich dann nicht mehr am Ende, sondern schon während der Produktentwicklung. Am Ende eines jeden, in der Regel zweiwöchigen Sprints, können fertige Funktionalitäten dem Kunden und Benutzer vorgestellt werden.
Welches Feedback hättet ihr gegeben, wenn ihr schon nach drei oder vier Sprints mit einem Prototypen des oben genannten Bestellprozesses zu tun gehabt hättet? Vielleicht hättet ihr euch die Möglichkeit gewünscht, per Bankeinzug oder Rechnung zu bezahlen. Ich bin mir über meine Top-Prio ziemlich sicher: Eine Versandbestätigung mit Liefernummer, damit ich nie wieder am Samstag Morgen mit einem 30 Kilo schweren Paket durch die Stadt ächzen muss!
Marty Cagan: Inspired. How to Create Products Customers Love
 

Flighty Estimation – "schwereloses" Schätzen

14:00 Uhr – Estimation Meeting in Scrum. “Please focus your estimates and put your courage in the upright postion!” Noch nie gehört? Schade!
Vielen Teams fällt es anfänglich schwer, agil zu schätzen. Das wirkt sich auf den Schätzprozess als solches aus und das Erlernen des Prozesses wird langsamer. Vieles, was bei diesem Prozess passiert, hat mit Vertrauen zu tun. Genauer gesagt: mit dem Zurückerlernen des Vertrauens. Soll heißen, das Team empfindet das Schätzen oftmals als emotionale Belastung, weil in der Organisation Fehler nicht gerne gesehen werden. Bei Ungenauigkeiten und Abweichungen werden dann auch entsprechende Rechtfertigungen verlangt.

Wie durchbricht man das alte Muster? Wie bekommt man das Team dazu, schwerelos den Prozess zu erlernen?

Am besten spielerisch! Nehmt ein Beispiel, zu dem alle Teammitglieder einen neutralen Bezug haben. Etwas, das weder mit dem Status der einzelnen Teammitglieder zu tun hat, noch direkt mit der Arbeitswelt der Beteiligten in Verbindung steht. Nehmt einfach mal was anderes: Zum Beispiel Papierflieger.
Es irritiert euch, einen Papierflieger zu schätzen? Gut, denn genau das birgt die Chance, etwas zu lernen. Irritation ist einer der wichtigsten Bestandteile, um einen Lernprozess zu starten.
 
Zurück zu den Papierfliegern: Prinzipiell handelt es sich um einfache Dinge. Ein paar Mal in die eine Richtung gefaltet, dann in die andere und am Ende kommt ein Flieger heraus, der leichtgewichtig seine Bahnen zieht. Baut ein paar Papierflieger zusammen und lasst sie das Team analog zu User Stories schätzen: Wie gut verstehe ich den einzelnen Flieger im Aufbau und wie “groß” schätze ich den Bauplan des Fliegers? Schon haben wir die wichtigsten Komponenten für das Schätzen beisammen. Jetzt könnt ihr schwerelos den Schätzprozess starten und anhand eines Experiments leichtfüßig lernen.
Viel Spaß mit den Papierfliegern und unterschätzt den Bauplan nicht! Es ist gar nicht mal so leicht, sie zu bauen.
Wer Bauanleitungen für Papierflieger braucht, hier findet ihr welche: http://www.funpaperairplanes.com/Plane%20Downloads.html
Hier noch zwei sehr empfehlenswerte Blogeinträge von meinen Kollegen Mathis und Kristina zum Thema “Schätzen”:
http://borisgloger.com/2012/06/06/schatztauchen/
http://borisgloger.com/2012/06/05/ich-schatze-was-das-du-nicht-schatzt/

Schätztauchen

In dem Boot auf dem Roten Meer in Ägypten, kurz vor meinem allerersten Tauchgang, habe ich nicht mit meinem Tauchlehrer diskutiert, ob es die richtige Methode ist, auf die Innenseite der Taucherbrille zu spucken und meinen Speichel zu verteilen. Damit sie nicht beschlägt, während ich mich in 25 m Tiefe befinde und ich dann blind herumschwimme. Mein Tauchlehrer hat lediglich die kurze Anleitung gegeben, ist abgetaucht und … ich habs einfach gemacht.

Warum?

Er ist der Profi, also könnte es funktionieren. Der potentielle Diskussionspartner schwieg sowieso unter der Wasseroberfläche und Zeichensprache kann ich nicht so besonders gut. Die Zeit war knapp und ich beschloss, eben diese für den eigentlichen Tauchgang zu nutzen und ihn später zur Rechenschaft zu ziehen.
Zehn Jahre später befinde ich mich als Consultant von bor!sgloger auf einem anderen Schiff, in einer interessanten Projektsituation:
Wir haben 15 Minuten pro Scrum-Team, um mit ihnen ihr erstes Estimation Meeting durchzuführen. In Anbetracht der Zeit(-Not) bat ich das Team, mir zu vertrauen und in den nächsten 13 Minuten (2 Minuten waren schon aufgrund einer knappen, aber herzlichen Begrüßung und Vorstellung vergangen) zu schweigen und sich auf das Magic Estimation Meeting einzulassen.
“Ich verspreche, euch nach dem Meeting, in den kommenden Tagen zu JEDER Frage, JEDER Skepsis, JEDER Kritik bzgl. unserer Art und Weise zu schätzen, Rede und Antwort zu stehen. Wenn wir uns in den nächsten 12 Minuten einfach darauf einlassen und… einfach machen.
1 heißt User Story ist klein
2 User Story ist doppelt so groß
3 User Story ist wie 1 & 2
Fibonacci eben.
Die 13 sollte quasi euer Sprint-Limit darstellen und bei der 20 ist die User Story nicht “Sprint-Ready”, sprich zu groß und/oder komplex und/oder hat zu viele Features etc.
Euer Product Owner verteilt nun die User Stories, jeder schätzt die User Story, die er soeben erhalten hat und legt sie an die entsprechenden Storypoints.
Im Anschluss seht ihr euch die von euren Teamkollegen geschätzte User Stories an und schätzt ab, ob sie mit eurem Bauchgefühl d’accord gehen. Wenn ja – einfach liegen lassen und falls nein – einfach umlegen. Er darf es selbstverständlich zurücklegen. Nach dem dritten Mal wird die User Story aus dieser Runde herausgenommen und ist somit JETZT nicht mehr relevant.
Vielleicht wisst ihr von einem Teamkollegen, dass er mit dem Feature bzw. dem Thema einer User Story Erfahrung hat, und vertraut ihm bei seiner Schätzung.    
Das einzige Instrument, das ihr nun braucht, ist euer Bauch. Beruhigt ihn damit, dass ihr mich in den nächsten Tagen auf ein heißen Stuhl setzen dürft.
Wir haben nun noch 10 Minuten – also: Ab geht`s!
Grinsen, Stirnrunzeln und ein letztes “der ganz heiße Stuhl… hihi” – und es wird geschätzt.
Bei allen drei Teams, die ich in den nächsten 45 Minuten betreut habe, hat es tatsächlich ohne Probleme funktioniert. Aber warum? Warum wird das Schätzen immer wieder thematisiert und so gern stundenlang diskutiert?
Weil die Zeit dafür “da” ist.
Selbstverständlich habe ich in den nächsten Tagen viele Gespräche geführt und Erklärungen geliefert. Sehr oft habe ich dasselbe in verschiedenen Formulierungen und Beispielen beschrieben, den hervorragenden Blog meiner Kollegin Klessmann verteilt, und habe sogar mit Müll geschätzt. (Die Putzkolonne hatte aufgeräumt, es standen verschiedene volle, blaue Müllsäcke und diverse Pappkartons herum … Doing as a way of recycling. True story.) Wenn wir keine Zeit haben, uns mit etwas genauer zu beschäftigen, fällt es uns Menschen doch wesentlich einfacher zu vertrauen, intuitiv Entscheidungen zu fällen und unseren Bauch gewähren zu lassen.

Natürlich werde ich weiterhin Erklärungen und Fragen zu unseren Methoden liefern. Die erste Erkenntnis hinkt jedoch oft dem Vertrauen und dem Tun hinterher. Die kleinen Verbesserungen kommen dann ganz von allein:

Ich schätze was, das du nicht schätzt …

… und das ist …

zumindest mal ein Dauerbrenner in der agilen Softwareentwicklung.

… zählbar

Oft stehe ich vor Teams und Entwicklern, die in ihrer Vergangenheit nicht die besten Erfahrungen mit dem Schätzen gemacht haben. Noch immer hat aber die Verknüpfung von Implementierung und zeitlichem Aufwand die Vorherrschaft. Meistens versuche ich zunächst, diese Verknüpfung in Frage zu stellen. Und zwar indem ich ihnen anbiete, nicht die Zeit für die Implementierung oder die Komplexität der Umsetzung, sondern einfach nur die Funktionalitäten zu schätzen, die in einer Story stecken. Ohne dabei die Dimension Zeit zu betrachten. Sie sollen die Story so nehmen, wie sie gerade ist – mit allen Unsicherheiten und sie sollen einfach mal betrachten, was nach ihrem Verständnis für den User an Funktionalität geboten wird.
Um es deutlicher zu machen, greife ich als Beispiel eine Story heraus, die in einem der nächsten Sprints umgesetzt werden soll und daher schon relativ detailliert beschrieben und verstanden ist. Dann lasse ich jemanden aus dem Team aufzählen, welche Funktionalität für ihn in der Story steckt und zähle mit den Fingern mit. Dann frage ich die anderen – wenn sie nicht schon selbst eingegriffen haben -, ob sie noch weitere oder weniger sehen. Daraus ergibt sich die erste Diskussion darüber, was das Team als Funktionalität bezeichnet.

… objektiv

Zumindest ist die Schätzung von Funktionalität objektiver als Komplexität und Aufwand. Zugegeben, um zu einer gewissen Objektivität zu kommen, muss das Team sich darauf einigen, was eine Funktionalität ist – zum Beispiel wie detailliert man sie aufsplittet. Das kann etwas dauern, mit der Zeit wird es aber selbstverständlicher und immer ähnlicher. Dieser Prozess ist jedoch „endlich“ und muss nicht für jede Story wieder durchgemacht werden, wie es bei der Diskussion um Aufwände und die Implementierung der Fall ist.
Objektiver also aus dem Grund, da wir nicht versuchen etwas vorherzusagen, das man nicht vorhersagen kann.

… unabhängig

Oft wird die Implementierung von Funktionalität durch die Ergebnisse vorheriger Implementierungen einfacher (oder beeinflusst). Diese Auswirkungen spielen jedoch bei der Schätzung mit Funktionalität keine Rolle, denn diese bleibt gleich. Außerdem liefert es ganz nebenbei den besten Anreiz, um bereits Implementiertes wieder zu verwenden.

… vergangenheitsbezogen

Obwohl die Schätzungen erstmal unabhängig von Zeit passieren können und sollten, spielt in die strategische Planung natürlich eine zeitliche Komponente hinein, die sich in der Release-Planung wiederfindet. Mir hat es geholfen, die Releaseplanung nicht als Zukunftsbetrachtung, sondern als Vergangenheitsbetrachtung zu sehen. Dabei sehen wir uns nur an, wieviel Funktionalität das Team in der Vergangenheit geliefert hat. Wir ziehen für unsere Planung also tatsächliche Lieferungen und nicht Schätzungen heran.

… Funktionalität

Zusammengefasst schätzen wir also nicht in die Zukunft gerichtet, sondern lediglich, was wir hier und heute an Funktionalität in einer Story erkennen können. Wir sagen nur voraus, was wir machen – was man später „sehen“ kann. Wir sagen aber nicht voraus, wie lange es dauert, um da hinzukommen und wie wir hinkommen. Bei der zeitlichen Betrachtung vertrauen wir auf das Gesetz der großen Zahl und sagen, dass es mal lange und mal kurz dauert, eine Funktionalität zu implementieren. Daraus bilden wir dann einfach den Durchschnitt und behaupten, dass es auch in der Zukunft im Durchschnitt so lange dauern wird, eine Funktionalität umzusetzen.
Und nachdem ich euch jetzt erklärt habe, wie ich meinen Teams das Schätzen erkläre, lasse ich doch einfach mal die Praxis sprechen. Hier ist eine Mail, die ich einem meiner Teams zu diesem Thema geschrieben habe:

Dear Team,

although there were quite some experiments already in this sprint I would like to add one more 😉 Tomorrow in the Estimation Meeting I would like to pick up the idea of estimating functionality instead of time, effort or complexity.
BUT independently from what we are doing: I need you to look into the stories beforehand and prepare questions and feedback for XY! Please really do so because the meeting will be a lot more fun if we can discuss all together 😉 and after reading my description below please also try to think in functionality that is in the stories. Write down what you think is the functionality the END USER ACTUALLY GETS (and for the beginning: try to count the functionalities).
Concerning the estimation in functionality:
We already introduced the shirt-sizes but we can just as well take the numbers for the estimation. Nevertheless keep in mind that the numbers cannot be taken in an absolute manner but rather relatively to each other. Meaning, if you estimate a 13 it does not automatically mean that the stories contain exactly 13 functionalities for the User.
Let me give a little example to make clear what I mean by functionality (and yes I know that your domain is not a baby toy by all means but just to get the idea across I will try it like this, ok?)
Here are the User Stories:

Estimating the time would probably mean that you would have to discuss the solution on how to implement it. After this discussion you could try and say: We need about 2 hours to implement it because we think that. While implementing it however, you find out, that you need much longer due to some impediment reason we could not foresee.
Also the two user stories are very similar so you could argue and say: Well, if we had already implemented the first story, the second would be doable in 5 minutes. If we have not yet implemented the first one, it would take about 2 hours. So what estimate to pick?
From a functionality perspective you would estimate the two stories exactly the same.
Lets say we have two functionalities:

  1. the sound
  2. the color change

But one might also argue that we have 4 functionalities:

  1. the button without sound in red
  2. the button in green
  3. the button without sound
  4. the button with sound

Although the second approach of counting might not seem logical I want to make clear that there can be different levels of granularity in estimating functionality. THE TEAM has to figure out a common understanding of what a bucket of lets say xxxs or 1 functionality means or a bucket of L/20 function points means. I call them buckets because as I described above they are not absolute numbers for functionality (as I also did it in the example to clarify) but they are kind of placeholders for a certain amount of functionality. And this amount is always relative to the other stories. So we only say: this s/13 is bigger than the xs/8 but smaller than the l/20 … it does not mean, that we can exactly count 13 functionalities. If we could always count it to the last bit, we would not have to estimate anymore anyway 😉
Also this approach forces us to actually understand WHAT functionality the product owner wants to get because we want to estimate the functionality the end user gets! Thus this approach can also be more objective because it does not depend on the solution and the implementation.
One might now argue, that it still takes different time to implement the Stories as I also pointed out before. In that case we just say that sometimes it takes long to implement and sometimes you can implement very fast due to maybe implementation you did before. Nevertheless – the functionality that is delivered to the customer does not change (if you needed 10 days or only 1 day). So we take the function points delivered in the last 3 sprints and take the average – so we cover also for the cases where it takes long to implement and the ones where it takes little time. And yes, we cannot predict this average of story points for the future. We have to wait 3 sprints until we can actually calculate it!!! But after the three sprints we can take this average and only say – if we assume this average will continue, we can deliver the following functionality at that point of time.. –> Release Plan for the customer!
(by the way: questions for the PO in this case could be: Do you want a round button or a square one? Does the button reactivate itself after some time? Can I configure the sound it makes? etc. … these questions might be too detailed already for an estimation meeting but are great for a sprint planning 1)
I hope this helps a little to understand the concept of estimating with function points.
Talk to you tomorrow – AND: be prepared!!!
Looking forward to it.

Führung, Selbstorganisation und Legitimation

Immer wieder taucht in den ScrumMaster Pro Trainings das Thema Rollenunsicherheit und Rollenunklarheit als ScrumMaster oder PO auf. Neue Rollenkonstruktionen wie der ScrumMaster brauchen per se Zeit, um sich zu etablieren und eine definierte Akzeptanz zu bekommen. Wenn ich nachfrage, kommen als konkrete Praxiserfahrungen Aussagen, dass zu wenig Energie und Durchschlagskraft in der Funktion nach oben und unten spüren sei. Man weiß nicht genau, was man darf oder auch nicht, wohin man sich wenden kann, wie viel Augenhöhe besonders zum Management erlaubt und erwünscht ist usw. Gerade in der Lösung von Impediments zeigt sich häufig diese Problematik, aber auch im Umgang mit Schnittstellen, ja, auch mit dem eigenen Team. Was hier häufig fehlt, ist schlicht und ergreifend ausreichende und klare Legitimation.

Was ist Legitimation?

Es ist also sinnvoll, die Frage nach der Bedeutung von Legitimation in der Rolle und Funktion als ScrumMaster (PO Teamleiter, Projektleiter) zu stellen. Legitimation ist ein wesentliches formales Element von Führung, ob disziplinarisch oder lateral.
Legitimation (aus lat.: lex, legis = „Gesetz“, „Rechtfertigung) bedeutet im heutigen Sinne Ermächtigung, Beglaubigung. Legitimation ist die Rechtfertigung faktisch bestehender Ordnungen, Regeln, Strukturen und somit ein handlungsrelevantes Element von Führungspositionen und funktionaler Macht. Legitimation in diesem Sinne unterstützt Standing, Entscheidungsfähigkeit und Einflussenergie von Führung.
Wichtig ist dabei zu sehen, dass Legitimation dreidimensional gesehen werden muss:

Systemlegitimation bedeutet, dass von den Verantwortungsträgern im Unternehmen dem Rollenträger ein klar definiertes Rollenprofil zugeschrieben und formell vereinbart wird. Verantwortungen und Kompetenzen müssen konkret festgelegt werden und die entsprechenden Konsequenzen in der Praxis reflektiert und bewusst gemacht werden. Darf zum Beispiel der ScrumMaster bei Kontext-Impediments auf Augenhöhe mit dem Management kommunizieren, darf er Personalentwicklungsanstöße geben, kann/muss er bei Konflikten eskalieren, usw. Wichtig ist dabei, dass das Commitment zur Legitimation von oben gegenüber den Teams und auch zu Schnittstellen im System klar und eindeutig kommuniziert werden muss.
Teamlegitimation erarbeitet sich der Rollenträger über Verständigung und Vertrauensaufbau im intensiven Kontakt mit dem Team. Dies geschieht indirekt durch entsprechendes Handeln in der Führungsrolle und äußert sich in Akzeptanz des hierarchischen Unterschieds und des spezifischen Beitrags zur Selbstorganisation durch alle Teammitglieder. Teamlegitimation kann aber auch direkt und gezielt thematisiert und zum Beispiel über Erwartungsklärung und Abgrenzung von Kompetenzen und Verantwortlichkeiten aktiv angestoßen werden.
Selbstlegitimation ist die eigene Zuschreibung, eine besondere (andere) Funktion im Selbstorganisations- und Arbeitsprozess des Teams inne zu haben. Sie bedeutet, überzeugt davon zu sein, dass die eigene Rolle funktional und für das Ganze wertvoll ist und dies auch selbstbewusst zu vertreten. Selbstlegitimation heißt, die eigenen Fähigkeiten für die kompetente Ausübung (inkl. Ausbildung und Zertifikat) meiner Rolle ohne Überheblichkeit wertzuschätzen, auch wenn ich vielleicht manches noch lernen und mich entwickeln muss. Im Idealfall heißt das auch, seine Rolle zu „schätzen“. Nur wer gerne führt, führt wirklich gut.
Gerade ScrumMaster als noch nicht gefestigtes und standardisiertes Rollenmuster in Unternehmen, sollten von Anfang an dafür sorgen, dass sie gut und ausreichend „dreifach“ legitimiert sind, um ihre Schlüsselfunktion im Scrumprozess gut und effektiv leben zu können. Das geht nicht immer von allein und ist auch durch ein Zertifikat nicht gesichert, sondern braucht bewussten Mut, Anstrengungen und Zähigkeit, um dahin zu kommen.

Was der Berliner Flughafen mit agilen Werten zu tun hat

Die Schlagzeile des heutigen Tages, die Deutschland, Airlines und Passagiere weltweit nervös macht: Die Eröffnung des neuen Berliner Flughafens wird  auf unbestimmte Zeit verschoben. Der 3. Juni als Eröffnungstermin ist Geschichte. Niemand kann sagen, wann der Willy Brandt-Flughafen bereit sein wird, sich den Reisenden zu stellen. Man hört von sechs Wochen Verschiebung. Der Prestige- und Vorzeigebau wird nicht fertig. Deutschland ist (mehr oder weniger) schockiert. Und eine der Fragen, die sich die Medien stellen, lautet: „Warum hat niemand früher gesagt, dass es länger dauert?“ Denn drei Wochen vor Start wird doch schon abzusehen gewesen sein, dass dieses nicht kleine Bauvorhaben nicht fertig wird …
So die momentane Situation – zumindest soweit sie aus der Informationsflut, die uns zu diesem Thema derzeit umspült, nachvollziehbar ist. Aber mal ehrlich: Kennen wir das aus unserem Berufsalltag nicht auch? Projekte die nicht fertig werden? Ampeln, die den aktuellen Projektstand darstellen sollen und die dann doch ausgehebelt werden, wenn das Ende näher rückt?
In vielen Unternehmen reißen Projekt-Deadlines und es muss nachgearbeitet werden. Eigentlich ist es eher die Regel, dass die geplanten Zeiten nicht eingehalten werden. So weit nicht schlimm. Denn wir sind Menschen und können nicht in die Zukunft gucken. Das gilt auch für den Bau des Willy Brandt-Flughafens. Ein Projekt in dieser Größenordnung ist nur schwer zu greifen – irgendwas vergisst man immer …  Um auf Veränderungen schnell reagieren zu können und Gefahren wie eine Nicht-Fertigstellung möglichst früh erkennen zu können, machen wir Scrum. Iterative und überschaubare Zeiten, in denen man genauer planen kann. Ich möchte mich nicht zu weit aus dem Fenster hängen  und sagen: Berlin hätte sein Bauvorhaben mit Scrum machen sollen. Aber ist doch eine spannende Fantasie … erste Ansätze waren mit dem Passagier-Testbetrieb auch schon da.

Offen kommunizieren!

Ich möchte an unsere Offenheit appellieren. In Scrum bemühen wir uns, offen zu kommunizieren.
Wenn es länger dauert, können wir (je länger das Projekt läuft, desto genauer) bestimmen, wann wir fertig sind. Dass das in der Realität oft schwierig ist, will ich nicht verleugnen. Das Team in Berlin, das den Flughafenbau steuert und den Termin nicht geschafft hat: Verständlich, dass es erst drei Wochen vor Start mit der unangenehmen Wahrheit rausrückt, die Situation ist ärgerlich und die Reaktion der Medien und der Öffentlichkeit schwierig. Wir sollten an dieser Stelle nachsichtig sein, uns an der eigenen Nase nehmen und es in Zukunft besser machen. Wenn wir offen kommunizieren, dass wir etwas nicht schaffen, hat das nichts mit Versagen zu tun. Es hat damit zu tun,  dass wir nicht detailliert in die Zukunft sehen können. Dass es jetzt Konsequenzen für den  Flugverkehr hat, ist ärgerlich und kostenintensiv. Nicht jeder von uns setzt gleich einen ganzen Flughafen in den Sand, klar. Aber Verzögerungen und Schwierigkeiten treten nun mal auf. Es sollte nicht passieren, aber es kann passieren – uns allen, in den unterschiedlichsten Größenordnungen.

Spielerisch für Veränderungen sorgen

Um einen Tisch sitzen sechs Product Owner und ein ScrumMaster. Die POs sind mit Post-its und Stiften bewaffnet. In der Mitte des Tisches liegt eine Spielkarte. Sie ist verdeckt. Der ScrumMaster dreht die verdeckte Karte um. Darauf ist eine Kreidetafel mit folgendem Inhalt zu sehen: „Wegen Zu geschlossen! Neueröffnung März 2007“. Der ScrumMaster gibt die kurze Anweisung: „2 Minuten Zeit. An die Stifte, fertig, los!“ – und die Product Owner beginnen mit dem Schreiben.
Ihr fragt euch, was hier gerade passiert? Hier spielt ein Product Owner Team „Happy Aua“. Das ursprünglich von Bastian Sick entwickelte Bilderspiel aus dem „Irrgarten der deutschen Sprache“ dient leicht abgewandelt als Kreativitätswerkzeug und soll Product Owner auf spielerische Weise dabei unterstützen, das Formulieren von Produktvisionen zu üben. Je origineller und lustiger der Kommentar zur Karte formuliert ist, umso besser. Die Abstimmung, welcher der Kommentare der jeweils Beste ist, erfolgt gemeinsam.

Spiele bei der Arbeit?

Führen und spielen? Veränderung und Spaß? Schließt das eine das andere nicht aus? Aus meiner Sicht sollten Arbeiten, Lernen und Spielen nicht voneinander getrennt werden. Spielen steht für eine Interventionsform, die Menschen in eine Welt entführt, in der alles passieren kann. Auch, wenn noch immer überwiegend die Meinung in der Arbeitswelt vorherrscht, dass Spiele für die Freizeit reserviert oder lediglich Kindern gestattet sind, finden Menschen wie Arne Gillert, Autor des Buches „Der Spielfaktor. Warum wir besser arbeiten, wenn wir spielen“, in Unternehmen immer stärker Gehör. Er behauptet: „Wer spielerisch an die Arbeit geht, gelangt ernsthaft zu neuen Lösungen.“ Trockene Arbeitsthemen oder schier unlösbare Situationen bekommen durch spielerisches Denken und Handeln neue Impulse, weil dabei eine Quelle (fast) vergessener Ressourcen angezapft wird.
Wann habt ihr das letzte Mal Kindern beim Spielen zugesehen?  Kinder lernen in ihrer frühen Entwicklung so viel und so schnell – und seid euch sicher:  Lernen ist Arbeit – wie nie mehr wieder in eurem Leben. Wie tun sie das? Sie spielen. Sie spielen den ganzen Tag lang. Dabei befinden sie sich in einer Welt, in der ihr Geist fokussiert, hochkonzentriert und 100% aufnahmefähig ist. Die gewonnenen Erkenntnisse und Erfahrungen, das Neue, werden so wirksam im Gedankengut verankert. So sind sie für den Rest des Lebens abrufbar und es kann wiederum Neues damit assoziiert werden.
Bürotätigkeiten, Meetings, Seminare, Schulungen, Workshops oder Vorträge – all das ist Arbeit. Und allzu oft beschäftigt sich diese Arbeit nur mit Begriffen von Dingen und eben nicht mit den Dingen selbst und ihren Beziehungen zur Umwelt. Der Mensch aber braucht Entfaltungsmöglichkeiten seines individuellen Lern- und Arbeitsstils. Um dabei jedem auf seine eigene Weise gerecht zu werden und gleichzeitig für den zu vermittelnden Lernstoff Aufmerksamkeit zu bekommen, müssen Möglichkeiten geschaffen werden, die Information in die jeweilige Individualsprache, die Assoziationswelt jedes Einzelnen zu transferieren.

Spielen kann das.
Spielen erhöht nicht nur die Aufnahme- und Lernbereitschaft. Spielen ist uns allen vor allem vertraut. Schließlich waren wir alle mal spielende Kinder. Und Vertrautes schenkt uns die Freude des Wiedererkennens. Freude steuert wiederum Aufmerksamkeit, öffnet unsere Bereitschaft, (Lern-)Energien zu mobilisieren und ein Gefühl zu erleben, das uns im Kontinuum des Arbeitsalltags häufig verloren geht, nämlich die kindliche Gier nach neuen Erfahrungen: die Neugier. Neugierde kompensiert nicht nur die Angst vor Fremdem, sondern ist der Schlüssel zu in uns schlummernden Handlungsräumen wie Kreativität, Experimentierfreude, Freigeist oder Spontaneität.

Spielen braucht Handlungsräume

Spielen findet überall dort statt, wo die Folgen des eigenen Handelns begrenzt sind – also dort, wo ein Fehlverhalten keine Katastrophen oder Repressalien nach sich zieht. Schon die Bereitstellung eines sicheren Rahmens (z.B. Hier darf heute wirklich alles passieren) sorgt dafür, dass Menschen Neues ausprobieren wollen/werden.
Das schönste Spiel im Rahmen eines Sprints ist die Retrospektive. Sicher fragt ihr euch jetzt, ob ich die gleiche Retrospektive meine wie ihr. Ja und nein. Fragt doch mal euer Team: „Was lief gut?“ und fragt es ebenso „Was könnte verbessert werden?“ Allerdings probiert  zum Einstieg mal das „Spinnennetz“ aus (vermutlich kein Scrum-Team, aber hier gibt es ein kurzes Video zu einer Outdoor-Variante):

Sorgt für (Spiel-)Räume, die eine ungestörte Erarbeitung individueller Lösungen ermöglicht und ihr werdet sehen, dass die Teammitglieder dabei bereitwillig Verantwortung übernehmen.

Spielen ist Handeln, Spielen ist nicht Planen

Vor kurzem habe ich ein Kind beim LEGO-Spiel gefragt: „Was wirst du jetzt bauen?“ Ohne aufzusehen, zuckte es mit den Schultern und murmelte: „Das weiß ich nicht.“ Eine halbe Stunde später stand dort ein kleines Kunstwerk. Ich hätte das SO niemals hinbekommen! Das Kind hatte keinen Planungsworkshop belegt, bevor es mit dem Bauen anfing, sondern legte einfach los.
Natürlich ist es wichtig, einen Plan in der Tasche zu haben, weil die Ausrichtung unseres Handelns auf ein größeres Ziel nun mal dazugehört, um so den besten Weg zu diesem Ziel herauszufinden. Aber wie gut sind Pläne wirklich? Eigentlich sollten wir es aus den Erfahrungen der abertausend gescheiterten Projekte, denen scheinbar wasserdichte Pläne zugrunde lagen, besser wissen.
Versteht mich nicht falsch! Spielen bedeutet nicht, dass Planen überflüssig ist. Es ist sogar essentiell. Allerdings geht es darum, über das Maß nachzudenken. Wie viel Planung ist tatsächlich nötig, um anfangen zu können. Nicht selten ist weniger wirklich mehr. Erfolgreiche Beispiele dafür sind die Schätzspiele „Magic Estimation“ und „Planning Poker“. Traditionelle Aufwandsschätzungen funktionieren nun mal nicht und verschwenden nicht nur Zeit, sondern sind relativ zu ihrem Effekt gesehen vollkommen übertrieben. Deshalb traut euch und spielt!

Spielen fängt im Kopf an

Wenn ich in meinen Trainings mit den Lerngruppen spiele, stelle ich – zwar in unterschiedlichen Ausprägungen – aber trotzdem immer wieder das Gleiche fest: Ist das Spiel erstmal angefangen, dann machen die Spielenden kaum bis keinen keinen Unterschied zwischen der Realität und dem, was Spiel ist. Wer spielt, der stellt sich etwas vor und taucht ab in seine (Spiel-)Welt. Die Vorstellungskraft gehört mitunter zu den mächtigsten Denkwerkzeugen des Menschen.
Nehmt das Daily Scrum als Versuchsballon. Schenkt jedem Teammitglied ein Überraschungsei. Die Schokolade ist euer Geschenk an jeden aus eurem Team. Der jeweilige Ü-Ei-Inhalt definiert das individuelles Motto des Tages oder der Woche oder des aktuellen Sprints. Lasst das Team immer wieder einen Bezug herstellen. Analogien, Metaphern, Geschichten lockern die Stimmung im Team auf und sorgen für ein Mehr an Leichtigkeit im Tun.
David Holzer, Trainer & Scrum Consultant

Es muss schnell gehen, heute machen wir kein Scrum

Zu meiner großen Freude führen immer mehr Unternehmen Scrum ein und beginnen diesen Produktentwicklungszyklus auch wirklich zu leben. Besonders gelobt werden die Planbarkeit und der Umgang mit dem Commitment. Und dennoch: Immer wieder schleicht sich ein altbekanntes Phänomen ein, das absolut im Widerspruch zu Scrum steht und auch konträr zu den eben erwähnten positiven Aussagen ist.
Folgende Situation: Eine vergessene Ausschreibung trudelt auf dem Tisch eines Mitarbeiters ein. Plötzlich müssen Kundenwünsche „schnell“ oder „mal kurz“ vom Entwicklungsteam umgesetzt werden. Untermalt von der Aussage: [quote author = “Ein Gehetzter”]”Leute, es muss schnell gehen, heute machen wir kein Scrum!”[/quote]  Und dann setzt man sich (im besten Fall) noch einmal zusammen und bespricht im Schnellverfahren, was zu tun ist. Dann hauen alle in die Tasten und die Abstimmung, die in Scrum eigentlich mehr Raum hat und sonst so gelobt wird und zum gewünschten Erfolg führt, wird ausgesetzt, weil sie angeblich zu lange dauert. Was bedeutet das? Dass Scrum nur toll ist, wenn man lange Planungsphasen hat? Wenn es aber schnell gehen muss, gibt es keine Zeit für eine richtige Abstimmung?

Was will Scrum?

Scrum möchte weg vom schnellen Dazwischenschieben von Aufgaben, hin zu einem strategischen Agieren und Planen. Dazu ist ein Product Owner nötig, der alle Termine im Blick hat und auch einmal Nein zu unerwarteten Kundenanforderungen sagen kann. Und hier spreche ich nicht vom Stillstand beim Kunden – dass es hier eine Ausnahmesituation braucht, ist selbstredend. Hier sind wir schnell bei den Verantwortlichkeiten und Aufgaben des PO: Er oder sie muss die Kundentermine im Blick behalten, sie priorisiert in das Backlog bringen und die Kundenanforderungen dann von den Entwicklern abarbeiten  lassen. Keine leichte Aufgabe, denn meist ist es ja nicht nur ein Kunde, dessen Wünsche und Bedürfnisse gestillt werden müssen. Einen guten Product Owner zeichnet ein gutes Organisationstalent aus. Und nicht nur das: Er hält den Kontakt zum Kunden, um rechtzeitig Anforderungen einzusammeln und den Entwicklern periodisiert zur Verfügung zu stellen.
Gelingt das dem Product Owner gut, dann ist es eine Arbeitserleichterung für die Entwickler. Sie müssen dann nicht mehr im letzten Moment auf den Plan gerufen werden, um das Feuer am Dach zu löschen.
Gilda Feller, Scrum Consultant bei bor!sgloger

Scrum ist überall … sogar in einer katholischen Messe

Sonntag war ich in einer katholischen Sonntagsmesse. Eine ganz normale Messe. Die kleine Kirche im Speckgürtel von Wien, offenbar in den 1960ern erbaut, ist nichts Besonderes. Es gibt kaum Schmuck und das große Kreuz dominiert die Wand hinter dem Altar. Die 100 bis 150 Menschen, die an diesem Sonntagmorgen in die Kirche gekommen waren, kamen um eines verstorbenem Priesters zu gedenken und um die Musik zu genießen, die deshalb besonders schön sein würde.
Der Pfarrer hielt sich zurück, blieb unscheinbar. In seiner Predigt machte er nur eine Sache deutlich: Jesus wurde einmal von zwei Jüngern aufgehalten. Er fragte: „Was wollt ihr?“ Der Pfarrer erklärte, dass Jesus  nicht fragte: “Was wollt ihr vom Leben? Was strebt ihr an? Was verlangt ihr?” Die korrekte Übersetzung aus dem griechischen Original lautet vielmehr: Was sucht ihr?“
Mit wenigen Worten machte der Pfarrer deutlich, dass es tatsächlich nicht um das „Wollen“, sondern um das Suchen geht. Das Erkennen der eigenen Wünsche, Sehnsüchte und Bedürfnisse, das “Mit-sich-selbst-auseinandersetzen”, um freizulegen, was da ist und gefunden werden will. Als Jesus dann weiter von den Jüngern gefragt wurde „Wo wohnst du?“, was soviel bedeutete wie „Wer bist du, was tust du, wie denkst du?“, da soll Jesus gesagt haben: „Kommt mit, dann werdet ihr sehen!“  [1] Wieder erklärte der Pfarrer, dass die Jünger ein Lehrgespräch erwartet hatten. Jesus erklärte aber nicht, sondern lud sie ein, es selbst zu sehen und mit ihm zu erfahren.
Die Kälte kroch durch meine Jeans und ich zog den Reißverschluss der Jacke noch weiter zu, aber ich konnte nicht anders: Während die Gemeinde zu „Amazing Grace“ anstimmte, begann ich darüber nachzudenken, wie dieses Gleichnis wohl auf die Situation des Sprint Planning 1 umzudeuten ist. Wir sagen immer, der Product Owner soll dem Team sagen, was er will. Er soll wissen, was er sich vorstellt.
Jürgen Margetich, einer unserer Consultants, hat aber als eine der Innovationen zu unserer Art und Weise Scrum zu lehren, klar gemacht, dass die User Stories im Grunde genommen Hypothesen sind. Wir sind der Meinung, dass auch der Product Owner nur vermuten kann, was der User brauchen könnte. Sicher – er muss zumindest sicher genug sein, dass er diese Hypothese und keine andere prüfen lassen will. Aber es bleibt nur ein Hypothese. Ganz im Geiste von Guy Kawasaki [2]: „Gebe den Leuten was sie wollen, bevor sie es in Worte fassen können.“

Die Suche des Product Owners

Wenn wir das Gleichnis der Lehrsituation von Jesus nun in diesem Lichte betrachten, dann wäre doch die Frage an den Product Owner: „Was suchst du? Welche Dinge versuchst du mit deiner Idee zu verändern? Was verlangt es dich, für den User zu verbessern?”
Damit würden wir den Product Owner nicht mehr in ein Kreuzverhör stellen. Ihm nicht mehr zumuten, dass er es ja wissen muss. Er wäre nicht mehr das „single-neck“, wie es Ken und Jeff immer beschrieben haben und wie es auf vielen Webblogs immer und immer wieder nacherzählt wird. [3] Wir würden vielmehr im Sinne von Eric Ries [4] beginnen zu akzeptieren, dass er zwar sagt, was er will, aber dass sich natürlich auch der Product Owner auf der Suche befindet. Dass die gesamte Produktentwicklung mit Scrum eine Suchbewegung hin zu dem ist, den Kunden zufrieden zu stellen – oder besser noch: zu begeistern.
Ich muss den Product Owner und das Development-Team gemeinsam so coachen, dass sie diese Suchbewegung als einen Dialog sehen, der nur miteinander geführt werden kann. In diesem Dialog ist der Product Owner dazu eingeladen, die Welt des Teams kennenzulernen, um zu verstehen, wie das geht, was es tut. Dann entsteht ein Scrum-Team, das auf gegenseitigem Verständnis und nicht auf einer Polarität, einer Spannung, basiert. Hat der Product Owner verstanden, was das Team tut und wie es ihm dabei helfen kann, sich zu verbessern, dann ist eine echte Gegenseitigkeit, ein gemeinsames Suchen entstanden.
Die Kirchengemeinde verstummt, Amazing Grace ist gesungen – es ist noch immer kalt … und doch hat sich der Besuch dieser Messe ganz unerwartet gelohnt.
[1] Ich habe die Stelle nachgeschlagen: „Die zwei Jünger hörten das und gingen Jesus nach. 38 Jesus drehte sich um und sah, dass sie ihm folgten. Da fragte er: “Was sucht ihr?” – “Rabbi, wo wohnst du?”, entgegneten sie. Rabbi heißt übrigens “Lehrer”. 39 “Kommt mit”, erwiderte er, “dann werdet ihr es sehen.” So kamen sie mit. Das war nachmittags gegen vier Uhr. Sie sahen, wo er sich aufhielt und blieben den Tag über bei ihm.“ (Evangelium nach Johannes 1,35)
[2] Guy Kawasaki arbeitete in den 90er Jahre als fest angestellter „Technologie-Prediger“ bei Apple und hat unter anderem das Buch „Enchantment: The Art of Changing Hearts, Minds and Actions“ geschrieben (geklaut bei GQ: http://www.gq-magazin.de/unterhaltung/stars/steve-jobs-diplom-steve-jobs-in-fuenf-lektionen/steve-jobs-diplom-interpretation-statt-imitation-eine-warnung
[3] zum Beispiel hier: http://www.scrumhw.org/agile-product-development-and-the-scrum-product-owner-role/
[4] Eric Ries: Lean Start Up, auch in unserer Bücherliste für 2012 zu finden

Der Product Owner und das Team: Anatomie einer Beziehung

Zur Rolle des Product Owners gehört eine ganze Menge. Der Product Owner soll eine mitreißende Produktvision haben, sein Backlog immer schön pflegen und darüber hinaus den Business Value nicht aus den Augen verlieren. Das allein kann es jedoch nicht gewesen sein. Es gibt genügend Product Owner, die all diese Tätigkeiten gut bis sehr gut beherrschen – und dennoch nicht wirklich in ihrer Rolle angekommen sind, mit ihrem neuen Amtsverständnis hadern und fremdeln. Oftmals liegt das daran, dass der Product Owner nicht im Scrum-Team angekommen ist.
Ein klassischer Projektleiter weiß, in welcher Beziehung er zu seinem Team steht. Er führt seine Mitarbeiter direkt oder indirekt, teilt ihnen Aufgaben und Verantwortlichkeiten zu. Dem Product Owner ist diese Form des Zugangs zum Team verwehrt. Das Entwicklungsteam soll ja selber entscheiden, wie viel es schafft und wer die Aufgaben erledigt. Die so verstandene Autonomie des Entwicklungsteams kann abschreckend wirken – ein Product Owner, der mit seinen Wünschen und Vorstellungen immer wieder abprallt, zieht sich gerne in seine Ecke zurück.

Scrum-Fernbeziehungen sind gefährlich

Wenn wir von Scrum-Teams reden, denken wir immer noch viel zu oft nur an das Entwicklungsteam. Das ist auch irgendwie logisch. Schließlich ist es das Entwicklungsteam, das Stories bearbeitet und am Ende des Sprints liefert. Der Product Owner wird dabei gerne in eine externe Rolle gedrängt: Nach diesem Verständnis beschränken sich seine Aufgaben auf die Versorgung mit Stories und die Abnahme an Ende des Sprints.

copyright Gerhard Peyrer

Das sieht dann so aus: Der Product Owner macht seine Arbeit. Das Entwicklungsteam macht seine Arbeit. Man trifft sich zu den Plannings und Estimation Meetings, und damit soll es gut sein.
Partnerschaften funktionieren so nicht. Scrum auch nicht. Der ganze Sinn und Zweck von Scrum besteht ja darin, das Abteilungsdenken aufzulockern, die Grenzen durchlässiger zu machen und die interdisziplinäre Kommunikation zu verdichten. In klassisch geführten Projekten brütet der Produktmanager im stillen Kämmerlein seine Produkte aus, schreibt dutzende Seiten zusammen – und mutet dann seinen Entwicklern zwei Dinge zu: Erstens das ganze Dokument zu lesen und zweitens die Produktidee dann auch noch so umzusetzen, wie er sich das gedacht hat.

Krieg der Welten, neu inszeniert

Dass das nicht funktionieren kann, weiß jeder Schüler, der sich mit Textinterpretation beschäftigt hat. Sobald die Tinte trocken ist, lösen sich die Gedanken vom Autor und entwickeln ein eigenes Leben. Dinge können so oder so ausgelegt werden – und was für die Fachseite völlig klar zu sein schien, kann für die Entwickler etwas komplett anderes bedeuten. Gregor Gramlich, agiler Entwickler, hat in einem köstlichen Theaterstück mal einen Auftraggeber gespielt, der von einem Entwickler eine App zum Verwalten von Basketball-Spielen haben wollte. Das ging dann ungefähr so:
Auftraggeber:  […] Ja, und dann sollen die Spieler mit ihren Rückennummern aufgeführt werden.
Entwickler: Ja, klar. Jeder Spieler soll anhand einer Nummer identifiziert werden. Wollte ich sowieso so machen. Was für Nummern sind das denn?
Auftraggeber: Puh, das können alle einstelligen und zweistelligen Nummern sein.
Entwickler: Gut. Aber zwei Spieler können nicht die gleiche Nummer haben – oder?
Auftraggeber: Wie meinst du das – im gleichen Team?
Entwickler: Ja, genau.
Auftraggeber: Doch, die Nummern können im Laufe einer Saison durchaus geändert werden.
Entwickler: Und wie ist es mit der Null? Kann ein Spieler eine Null haben?
Auftraggeber: Ja, der kann eine einfache oder eine eine doppelte Null bekommen.
Entwickler: Eine doppelte Null? Das ist aber schlecht. Die gibt es als Zahl doch gar nicht!
Auftraggeber: Wie – die gibt es nicht?
Und so weiter.
Die Aufführung zeigt sehr schön, wie zwei Welten aufeinanderprallen. Der Auftraggeber sitzt gedanklich schon im Spiel. Für ihn sind Nummern schlicht und einfach die Zahlen, die einem Spieler für die Dauer des Spieles zugewiesen werden. Der Entwickler ist hingegen schon bei der technischen Umsetzung: Er denkt an seine Datenbank  – und wie dort ein Spieler anhand einer eindeutigen und dauerhaften ID identifiziert werden kann.

Gemeinsame Perspektiven durch offene Kommunikation

In Scrum geht es darum, Perspektiven auf einen Nenner zu bringen. Ein Product Owner hat zwangsläufig andere Interessen und auch ein anderes Produktverständnis als ein Entwickler. Das bedeutet aber nicht, dass beide aneinander vorbei reden müssen. Durch offene und mutige Kommunikation können sich beide Seiten ein Stück weit in die Rolle des anderen hinein versetzen – und sich auf dieser Grundlage ein gemeinsames Verständnis erarbeiten. Wenn der Entwickler aus unserem Theaterstück wüsste, dass der Auftraggeber unter Spielernummern etwas komplett anderes versteht als er selbst, könnten einige Missverständnisse erspart bleiben.

copyright Gerhard Peyrer

Missverständnisse entstehen dann, wenn Aussagen ungeprüft übernommen werden. E-Mails und sonstige schriftliche Kommunikation sind ein herrlicher Nährboden für Missverständnisse. Deshalb ist es so wichtig, den Product Owner nicht als externen Zulieferer des Scrum-Teams zu verstehen,  sondern ihn ganz bewusst in dessen Mitte zu platzieren. Wenn der Product Owner nicht nur am Anfang und Ende, sondern auch während des Sprints im Team ist, dann muss sich keiner zweimal überlegen, was denn eigentlich mit dieser einen Anforderung gewollt war – oder warum diese andere Story nicht besser in zwei Stories geteilt wird.

Fragen statt vermuten

Anstatt wild zu vermuten, was der Product Owner wohl mit seinen Stories gemeint hat, kann man einfach zu ihm gehen und fragen. Die Macht solcher informellen Kommunikationswege (“hast du mal eben Zeit?”) kann man gar nicht hoch genug schätzen.  Wer die Themen aus dem Tagesgeschäft sofort bespricht, kommt schneller auf die wesentlichen Punkte. Auch der Product Owner profitiert davon, wenn er mitten im Team lebt: Gut verstandene User Stories sind das A und O eines funktionierenden Product Backlogs. Kürzlich wurde meinem Team durch ein scheinbar nebensächliches Gespräch klar, dass eine hoch priorisierte Story in der damaligen Form nicht umsetzbar war.
Die Rolle des Product Owners ist sicher keine einfache. Manchmal erschweren wir sie uns aber unnötig, indem wir etwa den Product Owner zum genialen und einsamen Visionär hochstilisieren. Dabei wird gerne vergessen, dass der Product Owner und sein Team  auf ein und dasselbe Ziel hinarbeiten: erfolgreich zu liefern. Und das gelingt – wie so vieles im Leben – zusammen leichter als allein.
Dr. Bernd Krehoff, Scrum Consultant bei bor!sgloger

Kreativität und Intuition

Wo kommen neue Produktideen her? Kann man sie einfach so aus sich heraus kreieren? Ich denke schon. Allerdings benötigt es dazu eine Form von Achtsamkeit, die nach innen schaut. Was beobachte ich in mir, welche Stimmen und Stimmungen wollen mir etwas sagen? Welche Träume habe ich, was mache ich aus diesen Träumen? Welche Einfälle habe ich gerade jetzt? Oft muss man diesen Strömungen dann einfach nachgehen und alles andere vergessen.
In diesem Video kommen Autoren zu Wort, die das viel besser ausdrücken können als ich.

Auch Zahnärzte haben Visionen

Letztens habe ich mit meinem Zahnarzt über die Software gesprochen, die er in seiner Praxis einsetzt. Die wurde ursprünglich von einem seiner Kollegen gemeinsam mit einem Programmierer entwickelt und zunächst nur in dessen eigener Praxis verwendet. Meinem Zahnarzt hat der visionäre Kollege die Software seinerzeit am Dachboden mit einer solchen Begeisterung vorgeführt, dass für meinen Zahnarzt sofort klar war, dass er auch in seiner Praxis damit arbeiten möchte. In der Zwischenzeit, bis mein Zahnarzt sich die Software leisten konnte, hatte sich der andere Zahnarzt völlig auf das Produkt fokussiert und war nur noch als Geschäftsführer seiner neu gegründeten Software-Firma tätig.
In dieser Position lud er alle Nutzer der Software ein Mal pro Jahr zu einem kleinen, kostenpflichtigen Kongress ein. Dort gab es zahnmedizinische Fachvorträge, aber auch völlig „artfremde“ Vorträge. Außerdem hielt er jedes Mal eine Session ab, an der die Entwickler teilnahmen, die Nutzer ihre Wünsche äußern und Feedback geben konnten. Über die einzelnen Vorschläge wurde dann in großer Runde diskutiert. Das jeweils folgende Jahr wurde dazu genutzt, die Vorschläge einzuarbeiten und das Produkt aktualisiert zur Verfügung zu stellen.
Ein guter Product Owner versteht seine Kunden

Für mich ist der ehemalige Zahnarzt, der zum Geschäftsführer der eigenen Software-Firma wurde, ein tolles Beispiel für einen Product Owner, der Kundennutzen und Wirtschaftlichkeit gleichermaßen im Blick haben muss, um erfolgreich zu sein. Die Software integrierte alle nötigen Anwendungen, um eine Praxis und ihre Patienten mit einem hohen Qualitätsanspruch zu managen und ließ mehr Zeit für das Wesentliche: Für das Verständnis, WAS dem Patienten fehlt und WIE der Arzt am besten helfen kann. Man konnte in diesem Produkt das Verständnis für die Probleme und Anforderungen der User spüren. Alle bürokratischen und verwaltungstechnischen Aufgaben waren weitgehend auf Knopfdruck zu erledigen. Dafür gab es mehr Möglichkeiten, die Informationen zu den individuellen Behandlungen umfangreich zu dokumentieren, um stets einen aktuellen Überblick zu bekommen.
Ich denke, der Software-Zahnarzt hätte sich selbst wahrscheinlich gar nicht als Product Owner bezeichnet, aber er hatte all das, was ein Product Owner braucht. Hat er doch eine Vision gelebt und es geschafft, seinen Kollegen einen Mehrwert bei ihrer täglichen Arbeit zu liefern, den niemand, der die Software einsetzt, heute noch missen möchte. Er hat es außerdem geschafft, die Kundenbedürfnisse so abzufragen, dass alle gerne zu den Veranstaltungen gekommen sind, auch weil es dabei nicht nur um Software und Zahnärzte ging, sondern vielmehr um einen ehrlichen, offenen Austausch zwischen den Kollegen. Es wurde eine Plattform geschaffen, bei denen man Gleichgesinnte getroffen hat, die laut meinem Zahnarzt auch heute noch seine ersten Ansprechpartner für den kollegialen Austausch sind.
Allerdings hat sich der Zahnarzt-PO dann aus der Geschäftsführung zurückgezogen. Seitdem bemerkt mein Zahnarzt, wie sich die Qualität des Produktes verändert. Fehlerhafte Updates werden ausgeliefert, auf das Feedback von Kunden wird schwerfällig reagiert, und das persönliche Einholen von Feedback wurde komplett eingestellt.
Oder wie es mein Zahnarzt ausdrückte: „Ich habe damals eine Philosophie gekauft. Heute ist es leider nur noch ein Produkt.“
Kristina Kleßmann, Scrum Consultant

Führung ist?

“Führung ist, wenn du vorausgehst und die anderen folgen dir!” Dieser Spruch ist in keiner Situation so deutlich wahrnehmbar wie beim Trainieren eines Pferdes. Ein Pferd hat den angeborenen Trieb, hinter dem Leitpferd zu laufen. Dieses Leitpferd muss vom nachfolgenden Pferd allerdings in seiner Rolle als “Anführer” akzeptiert werden. Auch ein Mensch kann so ein Leitpferd sein, allerdings muss dazu zwischen Mensch und Pferd ein klares Führungsverhältlnis aufgebaut werden.
Ist das einmal geschafft, läuft das Pferd ruhig im exakt gleichen Tempo dem Menschen hinterher. Aber jetzt wird es faszinierend: Ist der Mensch unsicher und dreht sich ständig nach dem Pferd um, bleibt das Pferd stehen. Ich muss also darauf vertrauen, dass mir mein Pferd folgen wird. Drehe ich mich um, werde ich enttäuscht und glaube vielleicht auch noch, dass ich das Pferd am Strick ziehen muss (Gewalteinwirkung), damit es mir folgt. Manchmal bleibt ein Pferd, das eigentlich folgt, dennoch stehen. Meistens ist das der Fall, wenn das Pferd etwas gesehen hat und das – anders als ich – als Bedrohung wahrnimmt. Meistens wartet es dann, bis ich vorausgehe und deutlich mache, dass keine Gefahr droht – dann folgt es mir mutig weiter.
Für mich war das sehr sehr lehrreich, gerade in der Frage, wie Führung funktioniert. Führung funktioniert sicher nie ohne Vertrauen in die eigene Rolle und ohne Vertrauen in das Team. Es wird folgen, wenn der Weg, den ich gehe, für das Team sicher genug ist.

Wir haben zu wenig gute Product Owner

In unserer täglichen Arbeit als Berater erleben wir einen Mangel an ausgebildeten Product Ownern. Leute, die ein Team führen können um ein großartiges Produkt zu bauen. Eine Person mit den Ideen und Werzeugen von Scrum zu trainieren, macht nicht einen guten Product Owner aus. Er könnte sich nur sehr zu fürchten beginnen, weil man ihm sagt, dass er jetzt eine riesige Veranwortung trägt. Auf meiner Suche nach dem wahren Verständnis von Product Ownership fand ich einige Hinweise in einem Buch von Marty Cagen namens “Inspired“. Cagen hat als Senior Vice President des Product Management bei eBay, AOL und Netscape Communication gearbeitet und als Software Ingenieur bei HP Laboratories. Also weiß er ziemlich viel über Product Management. Was mir am besten an Cagen’s Buch gefällt, ist die Klarheit seiner Vorstellungen darüber, was ein Product Manager braucht, um gute Arbeit zu leisten:

  1. Persönliche Merkmale und Einstellung
    1. Leidenschaft fürs Produkt
    2. Kundenempathie
    3. Intelligenz: “Es gibt eigentlich keinen Ersatz für angeborene Intelligenz. Product Management bedeutet Einsichten und Beurteilungen, und beides verlangt einen wachen Geist.”
    4. Arbeitsethik: “Nicht jede Rolle im Product Team verlangt das selbe Niveau an Hingabe und Anstrengung. Aber die Rolle des Product Managers ist nichts für jemanden, der sich vor harter Arbeit fürchtet.
    5. Integrität: “Von allen Mitgliedern des Product Teams, muss der Product Manager am meisten die Werte der Firma und des Produkts reflektieren.
    6. Vertrauen: “Vertrauen ist ein wichitger Zug, weil das ganze Team, das Leitungsteam und Sales schaut auf den Product Manager, der sie überzeugt, dass das, worin sie ihre Zeit, ihr Geld und ihre Karrieren investieren, ein Erfolg wird, und dass die Vision gut ist!
    7. Einstellung: Der erfolgreiche Product Manager ist der CEO des Produkts. Er übernimmt die volle Verantwortung für das Produkt und sucht keine Ausflüchte.
  2. Fertigkeiten
    1. Technologie anwenden – er muss die Technologie verstehen
    2. Fokus. Wie man so schön sagt, “Die Hauptsache ist, die Hauptsache Hauptsache zu halten”.
    3. Zeitmanagement
    4. Kommunikationsfähigkeit
    5. Business skills

Ich unterschreibe die obige Liste sofort. Bei Scrum nennen wir Marty Cagen’s Product Manager den Product Owner.
In Beratung, Coaching und Training müssen wir den Product Managern in allen Organisationen zeigen, wie sich sich zu Product Ownern machen können. Zu Leuten, die ihren wahren Wert in der Organisation kennen. ScrumMasters müssen mit den Product Owners/ Product Managern zusammenarbeiten, damit sie verstehen, dass sie viel angestrengter arbeiten müssen, um diese Fähigkeiten zu erlangen.
Product Ownership hat nichts damit zu tun User Stories zu schreiben oder sie in einem Backlog zu ordnen, es ist nicht dasselbe wie Story Mapping zu benutzen um eine Übersicht zu bekommen. Product Ownership heißt, eine coole Idee zu haben und Menschen dahin zu führen, diese coolen Produkte zu schaffen.

Der größte Product Owner aller Zeiten

[quote author=”Wikipedia: Carl Gustav Jung” link=”http://de.wikipedia.org/wiki/Carl_Gustav_Jung#Archetypen”]„Nach Jung sind Archetypen universell vorhandene Urbilder in der Seele aller Menschen, unabhängig von ihrer Geschichte und Kultur.“[/quote]
Ein solches Urbild haben wir alle diese Woche mit Steve Jobs verloren. Steve Jobs war für mich einerseits zunächst der begnadete Unternehmer, der Apple zu dem gemacht hat, was es heute ist. Ich war immer vom Apfel fasziniert. Sogar, als ich damals in Wien einen kaufen wollte und die Verkäufer zu snobistisch waren, um sich mit mir zu beschäftigen.
Es ist schon sehr interessant, dass dieser Mann im Leben von so vielen Menschen spezifische Spuren hinterlassen hat. Wer er war und was er geleistet hat, wird dieser Tage aus sämtlichen Facetten beleuchtet werden. Ich kann nur sagen, welche spezifische Rolle er für mich, im Bezug auf meine tägliche Arbeit gespielt hat und sicher noch sehr lange spielen wird.
Über die Jahre habe ich mich wenig aber doch mit dem Mann und Mensch Steve Jobs beschäftigt und obwohl es sehr laienhaft ist, was ich für mich zusammen getragen habe, muss ich sagen: Er war in meinen Augen der Archetyp des Product Owners. Steve soll Apple so aufgebaut haben, dass er als Einziger die wirklich wichtigen Entscheidungen getroffen hat. Er hat selbst als User und als PO fungiert.
Er hat Apple über die Produkte erfolgreich gemacht. Was natürlich nicht heißt, dass er sie alle selbst erfunden hätte. Er hat sie aber so sehr geliebt, dass er hinter jedem einzelnen Aspekt seiner Produkte stand. Mal beiseite gestellt, dass er in seinen Produktpräsentationen unvergleichlich war … man hat ihm immer angesehen, warum gerade dieses Produkt einzigartig für ihn ist.
Für uns Scrummies wird es Zeit, an diesem Archetypen zu lernen. Product Owner müssen in den Unternehmen die Chance bekommen sich durchzusetzen. Sie müssen Ahnung von Usability haben, sie brauchen ein Gespür für ihre Kunden und für sich selbst als Kunden: Was würde ihnen denn selbst Spaß machen? Sie müssen super kreativ sein – ja sie sind etwas besonderes. Das habe ich mir nicht selbst ausgedacht. Nein, das findet man bei Marty Cagen in „Inspired“.
Wie man als Product Owner ständig in Reviews sitzen kann – auch das soll Steve getan haben – ist mir ein Rätsel. Aber so soll es laut diesem Artikel gewesen sein:
[quote author=”Alain Breillatt, The Pragmatic Marketer” link=”http://www.pragmaticmarketing.com/publications/magazine/6/4/you_cant_innovate_like_apple”]„Paired design meetings. Every week, the teams of engineers and designers get together for two complementary meetings.
Brainstorm meeting. Leave your hang-ups at the door and go crazy in developing various approaches to solving particular problems or enhancing existing designs. This meeting involves free thinking with absolutely no rules.
Production meeting. The absolute opposite of the brainstorm meeting, where the aim is to put structure around the crazy ideas and define the how to, why, and when.
These two meetings continue throughout the development of any application. If you have heard stories of Jobs discarding finished concepts at the very last minute, you understand why the team operates in this manner. It’s part of their corporate DNA of grueling perfection. But the balance does shift away from free thinking and more toward a production mindset as the application progresses – even while they keep the door open for creative thought at the latest stages.
Pony meetings. These meetings are scheduled every two weeks with the internal clients to educate the decision-makers on the design directions being explored and influence their perception of what the final product should be.
They’re called “pony” meetings because they correspond to Lopp’s description of the experience of senior managers dispensing their wisdom and wants to the development team when discussing the early specifications for the product.“[/quote]
Das alles klingt doch sogar noch mehr nach Scrum, als ich es immer vermutet hatte.
Ohne es bewusst zu verfolgen, hat Steve wahrscheinlich die prominenteste Scrum-Organisation geschaffen. Fokus, gab es auf jeden Fall. Courage, oh ja, definitiv. Offenheit, ich denke weniger. Respekt, das kommt wohl darauf an. Commitment, definitiv. Drei Treffer aus 5 sind nicht so schlecht.
Mein tiefes Bedauern über seinen viel zu frühen Tod kann ich damit leider nur ein wenig zum Ausdruck bringen. Die Welt hat einen großen Mann verloren.