Somebody Else’s Problem im Produktmanagement

Somebody Else’s Problem

SEP – Somebody Else’s Problem – ist eines dieser wundervollen Konzepte aus Douglas Adams „The Hitchhiker’s Guide to the Galaxy“, das in seiner vermeintlich überzogenen Darstellung exakt die Wahrheit widerspiegelt:
„The Somebody Else’s Problem field… relies on people’s natural predisposition not to see anything they don’t want to, weren’t expecting, or can’t explain.“
In dem Buch wird ein riesiges Raumschiff für die Besucher eines Cricket Spiels unsichtbar. Das Phänomen lässt sich aber auch in unserer Galaxy beobachten. In dem bekannten ‚the invisible gorilla‚ Experiment wird die Aufmerksamkeit während des Ansehens eines Videos so stark auf einen einzelnen Aspekt fokussiert, dass die Hälfte der Beobachter einen durch das Bild tanzenden Gorilla nicht wahrnimmt. Der Gorilla wird zum Somebody Else’s Problem. Der eigene Fokus darauf, die Pässe der weißen Mannschaft zu zählen, lässt alles andere unsichtbar werden.

SEP im Produktmanagement

Das SEP ist insbesondere auch im Produktmanagement ein maximal relevantes Problem. Eine zentrale Aufgabe des Produktmanagements ist es, Kundenprobleme zu identifizieren und zu lösen. Sowohl Design Thinking Ansätze als auch das Lean Product Playbook unterscheiden daher den Problem Space und den Solution Space. Der Problem Space beschreibt die Kundenperspektive und wie der Name schon sagt das zu lösende Problem. Erst wenn für diesen Bereich eine ausreichend klare Hypothese vorliegt, wird der Solution Space bearbeitet, d.h. eine Lösung erarbeitet. Die Lösung wird dann am Ende wieder mit dem Problem abgeglichen. So kann über mehrere Iterationen eine für das Problem passende Lösung erarbeitet werden. Dies folgt der Devise:
Verliebe Dich nicht in die Lösung, sondern in das Problem!
Lösungen wirken aber leider wie das oben zitierte Somebody Else’s Problem field für den Problem Space. Sobald wir eine Lösung im Kopf haben, vergessen wir das Problem. Das Kundenproblem wird zu Somebody Else’s Problem, der Kunde zu Somebody Else. Damit ist die Gefahr groß, dass wir an dem Kunden als eigentlichem Adressat unsere Produkte vorbei arbeiten und damit keinen Wert schaffen. Wir beschäftigen uns mit der Lösung, in die wir uns verliebt haben, das Problem verkommt zur Nebensache. Ohne das Problem können wir aber nicht mehr bewerten, ob unsere Lösung eine gute ist. Vielmehr tendieren werden wir dazu, die Fertigstellung der Lösung an sich zu feiern. Das ist der Grund, warum es soviel Produkte und Feature gibt, die nicht genutzt werden.

Hintergrund

Ein Ansatzpunkt für das SEP Phänomen lässt sich in „Thinking, Fast and Slow“ von Daniel Kahneman finden. Dieser unterscheidet (deutlich vereinfacht dargestellt) unseren Geist in ein System 1 und ein System 2. System 1 stellt die eher unterbewusst laufenden Prozesse da, System 2 die aktiven Denkprozesse, wobei beide Systeme nicht getrennt sind, sondern ein Gesamtgefüge darstellen. System 1 ist vor allem darauf ausgerichtet einen möglichst hohen Grad an Kongruenz zu erzeugen. Dabei ist System 1 anfällig dafür Lügen als Wahrheit zu akzeptieren, solange sie gut in den Gesamtzusammenhang passen. Um das zu verhindern, muss System 2 aktiv werden. Er schreibt dazu:

„System 1 is gullible and biased to believe, System 2 is in charge of doubting and unbelieving, but System 2 is sometimes busy, and often lazy.“

Wir tendieren also mit unserem System 1 dazu, unsere Lösung als die Lösung für ein Kundenproblem zu bewerten. Das Problem dabei immer wieder in den Vordergrund zu rücken und zu prüfen, ob Problem und Lösung wirklich übereinander passen, ist eine Anstrengung, die das grundsätzliche faule System 2 ausführen muss. Wenn wir das SEP Phänomen also bekämpfen wollen, um so wertvollere Produkte zu entwickeln, dann brauchen wir Tools, die unser System 2 immer wieder aufs neue aktivieren.

Lösungsansätze

User Stories sind ein geeignetes Format, um das SEP field zu durchbrechen. Das klassische Format einer User Story lautet:
Als <Benutzerolle>
will ich <das Ziel>,
so dass <Grund für das Ziel>.
Dabei kann die <Benutzerrolle> als Kunde betrachtet werden, der <Grund für das Ziel> als Problem. Beides zusammen bildet die Basis für den beschriebenen Problem Space. Das <Ziel> repräsentiert die Lösung bzw. den Solution Space. Der Trick ist nun, dass in agilen Methoden durch das Format der User Story vor allem die Lösung zur Diskussion gestellt wird. Agile Teams setzen nicht einfach die gefragte Lösung um. Sie hinterfragen, ob es basierend auf dem dargestellten Problem Space, nicht vielleicht noch eine bessere Lösung gibt. User Stories werden so zu einem Tools, das die Interaktion von Individuen unterstützt und sind damit voll im Einklang mit dem agilen Manifest.
Auch Minimum Viable Products (MVP) sind ein geeignetes Tool,  um sich auf Kundenprobleme zu fokussieren. Richtig angewendet zielen diese darauf ab, ein Produkt zu entwicklen, dass so gerade eben ausreicht, um die Problemlösungskompetenz eines neuen Produkts oder Feature vom Kunden einwerten zu lassen. Der Build-Measure-Learn Zyklus führt dabei die Erkenntnisse aus dem User Feedback immer wieder zurück auf die nächste Produkt-Iteration. Leider gilt aber sowohl beim MVP als auch beim Einsatz von User Stories: A fool with a tool is still a fool.

Fazit

Der Kampf gegen das Somebody Else Problem im Produktmanagement ist ebenso schwierig wie notwendig, wenn wir wertvolle Produkte erstellen wollen. Menschen neigen dazu, sich in Lösungen zu ergehen. Gegen diesen Drang müssen wir sehr aktiv ankämpfen. Selbst Leute vom Fach, die Agilität und Kundenzentrierung im Grundsatz verstanden haben, müssen immer wieder auf das Problem fokussiert werden. Vielleicht hilft es ja ein Handtuch griffbereit zu haben, das mit der Aufschrift „don’t panic and mind the problem“ versehen ist.

Wie steht es aktuell um die Agilität in unseren Unternehmen?

Duale Studenten sind ein guter Gradmesser für den Status einer Organisation. Sie lernen gleichzeitig Theorie und Unternehmenspraxis kennen. Zudem erhalten Sie einen guten Gesamtüberblick über ihren Ausbildungsbetrieb. Ich halte es damit für legitim aus dem Feedback dieser Studenten auf den Stand der unternehmerischen Praxis zu schließen. Das Feedback, das ich über meine Seminare regelmäßig erhalte, deckt sich mit dem, was ich auf Konferenzen und in direktem fachlichen Austausch erlebe:

  • Agilität ist im unternehmerischen Mainstream angekommen
  • Top Down Perspektive: „wir müssen agiler werden“
  • Bottom Up Perspektive: „wir wollen gerne agiler sein“
  • Top Down meets Bottom Up: „der Coach wird’s schon richten“

Die Top Down Perspektive

Hier kommen zwei Strömungen zusammen, die den Ruf nach Agilität lauter werden lassen: Druck von unten und von außen sowie akute Buzzword-Tauglichkeit. Es geht mehr ums agil sein müssen als ums agil sein wollen. Damit geht ein mangelndes Verständnis für das einher, was Agiltität sein kann. Es spricht für sich, wenn in wirklich namhaften Unternehmen per Diskret der tägliche Standup Flächen deckend angeordnet wird. Das wirkt fast schon kindlich trotzig. Ganz wunderbar lässt sich das Dilemma bei Skalierungsansätzen wie SAFe erkennen. Dort tauchen bildlich die agilen Teams ganz unten auf dem Schaubild auf, das Top Management bleibt ganz oben, durch mehrere Grenzen sauber abgetrennt. Frei nach dem Motto: „Dusch mich und mach mich nicht nass!“ bzw. „Mach uns agiler aber lass bitte alles beim Alten“. Dass Berater genau in diese Kerbe schlagen, ist inhaltlich schade, betriebswirtschaftlich aber vollkommen nachvollziehbar.

Die Bottom Up Perspektive

Der Wunsch nach agilerem Arbeiten ist hier genau so groß, wie die Skepsis gegenüber den angeordneten Verfahren. Das Verständnis für Agilität erscheint hier intuitiver, aber leider ebenso wenig fundiert. Es werden eher Mythen als Wissen verbreitet. Kürzlich erzählte man mir, dass eine Abteilung ihr Kanban Board bewusst nicht physisch an einer Wand darstellt, damit – Achtung! – die anderen Abteilungen nicht darüber lachen. Ein anderes Beispiel ist das Gantt Chart voller Micro Management Zielen und nicht haltbarer Zeitschienen, das voller Überzeugung als hoch agile Methode verkauft wird.

Top Down meets Bottom Up

Bottom Up und Top Down treffen unweigerlich aufeinander und sind dabei verbal konform: agiler werden, agile Werte und Methoden, Vertrauenskultur etc. Beide Ebenen benutzen das selbe Vokabular, meinen aber unterschiedliche Dinge. Das Zusammentreffen der beiden Perspektiven lässt sich auch an dem Kampf Autonomy vs. Allignment beobachten. Agile Teams können die Tendenz entwicklen, die eigene Autonomie zu stark in den Vordergrund zu setzen und dabei die Ausrichtung auf die Unternehmensziele, das Alignment,  aus den Augen zu verlieren. Auf der anderen Seite können zu strikte Vorgaben die notwendige Autonomie der Teams zerstören.

Agile Coaches

Die agile Industrie hat genau für diese Herausforderungen die Rolle des Agile Coaches ins Spiel gebracht. Für mich sind Agile Coaches / Scrum Master aber vor allem ein Symptom für missverstandene Agilität. Sehr gut hat mir in diesem Zusammenhang der Vortrag von Frank Schlesinger gefallen:

„Wir haben als Scrum-Company den ScrumMaster abgeschafft und die Linienführung gestärkt.“
Eigentlich sollte diese Aussage gar nicht verwundern. Die Scrum Master Rolle ist so angelegt, dass nach der Vollzeit-Einführung der Methode, die Aufgaben von dem Team übernommen werden können. Die Abschaffung des Scrum Master ist somit ein Beleg für das tiefe Verständnis der Organisation im Umgang mit der Methode. Dies ist für mich auch der Hauptgrund, warum ich den Einsatz von Agile Coaches in Festanstellung für keinen Ansatz halte. Den Ast auf dem man sitzt abzusägen, ist ein hoher Anspruch an sich selbst, im Prinzip aber die Kernaufgabe eines Agile Coaches.

Mangelnde Ausbildung

Dabei fehlt es vielen agilen Coaches aus meiner Sicht an einer ausreichend breit und tief angelegten Ausbildung. So saß ich kürzlich in einer Runde agiler Experten, die mit Organisationsentwicklung beauftragt sind. Aus dieser Runde mit fester Überzeugung zu hören, dass Scrum ja wirklich ausschließlich für Software-Entwicklung relevant sei und deshalb für einen Großteil der Organsation überhaupt keine Relevanz hätte, hat mich dann doch schockiert. Wenn das die Meinung der „Experten“ ist, dann verwundert es wenig, wenn operative Teams Agilität und ihre Coaches nicht ernst nehmen. Tun Sie es doch, entstehen die oben erwähnten Mythen.

Ein weiteres Problem im Kontext Ausbildung ist das fehlende Geschäftsverständnis. Nur wenige agile Coaches und Berater haben je Geschäftsverantwortung übernommen. Agilität ist kein Selbstzweck. Sie ist nur dann sinn- und wertvoll, wenn ihr Einsatz den Geschäftszweck selbst positiv unterstützt.

Der Ausweg

Einer der besten Vorträge, die ich zum Thema Scrum im Speziellen und agil im Allgemeinen gehört habe, war von Jeff Sutherland. Er betonte auf der einen Seite ganz klar die Bedeutung der agilen Werte und mahnte davor, sich zu stark auf die Prozesse und Rollen zu konzentrieren. Auf der anderen Seite richtete er den Fokus auf die ergebnisorientierte Seite des Ansatzes. Scrum wurde u.a. aus seinen Erfahrungen als Kampfpilot im Vietnam-Krieg heraus entwickelt. Der Anstoß zu einem der modernen agilen Klassiker beruht also mit Nichten nur auf einem neuen Wertesystem. Es ist essentiell zu verstehen, dass Scrum auch einen ganz klaren Zweck verfolgt. Wenn man nach einem Einsatz wieder heil auf seinem Flugzeugträger landen will, dann muss man zur richtigen Zeit wieder am verabredeten Ort ankommen. Genau das ist die Idee hinter einem Sprint.

Diese zwei Aspekte lassen sich frei nach Probst (aus: Selbstorganisation – Ordnungsprozesse in sozialen Systemen aus ganzheitlicher Sicht) als substantiell und symbolisch klassifizieren und in folgende Fragen übersetzen:
  1. substanziell: Welcher Zweck soll erreicht werden? Welche Methode ist am besten dafür geeignet diesen Zweck zu unterstützen?
  2. symbolisch: Wie soll sich die Arbeit anfühlen? Welchen Sinn soll die Arbeitsweise vermitteln?
Die substantielle Frage betrifft vor allem die betriebswirtschaftlichen Aspekte einer Unternehmung, während der symbolische Aspekt auf Kultur und Werte abzielt. Nur im Zusammenspiel beider ergibt sich ein stimmiges Ganzes. Das bedeutet aber auch, dass agiles Arbeiten nicht zwingend agile Methoden braucht. Auch ohne den Einsatz von Scrum, Kanban, Lean Startup oder sonstiger moderner agiler Methoden lässt sich eine agile Organisation aufbauen. Prof. Dr. Aulinger bringt dies in seinem Whitepaper sehr gut auf den Punkt – unbedingt lesen!

Fazit

Agilität droht in der unternehmerischen Praxis an der Bullshit Bingo Hürde zu scheitern. Wer sich ernsthaft mit der Thematik befassen will, der muss Agilität substantiell und symbolisch bewerten und auf dieser Grundlage seinen eigenen Weg finden. Dazu gehört auch eine entsprechende Ausbildung, die nicht nur tiefe Kenntnisse der Methoden und Werte vermittelt. Diese Ausbildung muss auch in die Breite gehen und Geschäftsverständnis prägen. Nur so kann eine sinnvolle Einordnung von Agilität in den jeweiligen Geschäftskontext vorgenommen werden.
Bild: coach_stop_SanFran von Johan Lange auf flickr, Verwendung unter CC

Agiler Wandel ganz einfach

Agiler Wandel und Star Wars

Allein die Einführung agiler Frameworks macht noch keine agile Kultur aus. Agiler Wandel ist nötig, um die Kultur des Unternehmens in Richtung Agilität zu bewegen.  Alles, was wir für einen Wandel brauchen – und das ist ggf. viel weniger, als man zunächst vermuten mag – finden wir in einer weit, weit entfernen Galaxis…

In der Einleitung zu „15 Zitate aus Star Wars für den Alltag“ steht:

„Star Wars strotzt ja geradezu vor wichtigen Themen und Lehren, die wir auf unser Leben übertragen können. Viele dieser großen Gedanken sind in wunderbar knappen und zitierfähigen Sätzen zusammengefasst.“

Agiler Wandel und die MachtWie schaffen es Filme, die vor allem auf Verkauf von Merchandising ausgerichtet sind, große Gedanken zu vermitteln? Die Antwort müsste eigentlich gar nicht lauten, denn die großen Gedanken entpuppen sich schnell als kurze Phrasen, die keinen wirklichen Sinnzusammenhang haben. Star Wars schafft es aber trotzdem im Kontext großer Gedanken genannt zu werden und dies funktioniert gerade nicht durch Inhaltsschwere. Die Filme vermitteln keine geschlossene Jedi-Religion, sie funktionieren über die perfekte Inszenierung. Einzelne Szenen mit authentischen Hauptfiguren schaffen einen Rahmen, in den der Zuschauer seine eigene Jedi-Religion in das Star Wars Universum hineindenken kann. „Möge die Macht mit Dir sein“ wird so von einem kleinen Satz zu einem großen Gedanken, auch wenn niemand so richtig weiß, was diese Macht denn nun sein soll und wie sie mit einem sein kann.

Unsere Galaxis funktioniert zum Glück genauso platt. Agiler Wandel bzw. Kulturwandel im allgemeinen braucht m.E. keine ausformulierte Kultur und Werte und kein aufgesetztes Change Projekt. Agiler Wandel braucht einige Schlüsselszenen, die von den Hauptfiguren authentisch vorgetragen werden. Hier ein Beispiel aus der Praxis:

Kulturwandel in der Praxis

Im Rahmen eines groß angelegten Kulturwandels duzt OTTO sich jetzt bekanntlich. Die Initiative ging vom Vorstand aus, was auf jeden Fall schon mal die richtigen Hauptpersonen sind. Inhaltlich finde ich das Du eine gelungene Aktion im oben genannten Sinne. Im Mittelpunkt steht eine ganz simple, losgelöste Geste, die aber eine sehr große Kraft entfalten kann – möge das Du mit uns sein. Leider wurde nur nicht an die richtige Inszenierung gedacht.

Die Info, dass der Vorstand allen das Du anbietet, wurde über das Intranet verbreitet. Ich vermute mal, dass die digitale Kommunikation die entsprechende Strategie unterstreichen sollte. Und die vielen #s sollten wohl einen modernen Social Media Kontext schaffen. Wer weiß…

Ganz ohne #, in einem öffentlichen Termin oder vielleicht sogar in guter alter Michael Otto Tradition, der zu Weihnachten persönlich über alle Flure ging, um jedem ein frohes Fest zu wünschen, wäre die Aktion ein Volltreffer gewesen. So aber bleibt, zumindest bei mir, der Beigeschmack einer akademisch fundierten Change-Initiative.

Agiler Wandel und die Rolle der Führung

Durch die geforderte authentische Inszenierung der Hauptpersonen kommt der Führung eine ganz besondere Rolle zu. Ähnlich stellt es auch Frederic Laloux  in Reinventing Organizations dar, der eine der zentralen Voraussetzung für eine selbstorganisierte Organisation darin sieht, dass der „CEO“ hinter dem Konzept steht und es lebt. Ich bin der Überzeugung, dass dies nicht nur für selbstorganisierte, sondern auch für agile Unternehmen gilt. Agil wird eine Organisation nicht durch zertifizierte Coaches, sondern durch die agile Einstellung und Vorbildfunktion der Führung. Agil werden, weil das Management es als vermeintliche Notwendigkeit erkannt hat, wird nicht funktionieren. Es werden dann ggf. agile Prozesse eingeführt, wobei die Betonung aber auf Prozesse und leider nicht auf Individuen und Interaktion liegt. Agiler Wandel ist das dann nicht, entsprechend wird keine agile Organisation entstehen.

Um mit einem Zitat aus Star Wars zu enden: „Tu es oder tu es nicht. Es gibt kein Versuchen.“

Bild: Day 190 von Pascal auf flickr, Verwendung unter CC0

Kanban Board – todo doing done

Kanban BoardEin Kanban Board soll den Fluss der Arbeit abbilden und dadurch die nötige Transparenz schaffen, auf deren Basis die Prozesse optimiert und übergreifend aufeinander abgestimmt werden können. Diese Boards können beliebig komplex aufgebaut werden. Die einfachste Form folgt dem Schema todo – doing – done. Was so trivial aussieht, deckt aber eine ganze Reihe von zentralen Fragestellungen ab.

Todo

In der Todo Spalte sind die Tasks aufgeführt, die erledigt werden sollen. Um diese Spalte zu befüllen, bedarf es also schon einer intensiven Auseinandersetzung mit der Aufgabe. Es geht um die Fragestellung, was man wirklich machen will bzw. was das wichtigste nächste Thema ist. Noch klarer wird es in der Negation: was will ich (aktuell) alles nicht machen? Eine Todo Spalte impliziert, ein klares Bekenntnis zu den darin befindlichen Aufgaben.

Damit ist die Todo Spalte auch nicht gleichzusetzen mit einem Backlog, d.h. einer nach Wert geordneten Liste aller anstehenden Arbeiten. Innerhalb eines Kanban Systems ist der Fluss der Aufgaben zentral, der über Durchlaufzeiten erfassbar gemacht werden kann. Dafür sollte die ToDo Spalte möglichst klein gehalten werden. Die zentrale Frage für die Befüllung dieser Spalte lautet: was soll als nächstes live gestellt werden? Der Backlog muss dann an anderer Stelle verwaltet werden. Nur so kann auch ein sinnvolles WIP Limit für die ToDos gesetzt werden. Den Backlog durch ein WIP Limit zu begrenzen erscheint wenig sinnvoll.

Doing

In der Doing Spalte wird das verwaltet, was gerade aktiv in Bearbeitung ist. Die Abgrenzung zu der Todo Spalte ist hier besonders wichtig. Nur weil man sich für ein Task entscheidet, hat man lange noch nicht begonnen daran zu arbeiten. Einzelne Tasks sollen schnell und berechenbar durch das Board fließen. Ein Task in der Doing Spalte bedeutet maximale Fokussierung auf die Umsetzung. Losgelöst von Service-Leveln o.ä. muss die Doing Spalte schon an sich ein treibendes Element für das Team darstellen. Entsprechend sollte insbesondere für die Doing Spalte eines Kanban Boards der work-in-progress limitiert werden.

Done

Wenn ein Task fertig gestellt, wird er in die Done Spalte verschoben. Dies setzt natürlich voraus, dass man weiß, wann ein Task fertig ist. Je konkreter die ToDos erfasst sind, desto besser kann deren Reifegrad beurteilt werden. Dabei geht es nicht nur um Akzeptanzkriterien. Es geht vor allem darum, die Arbeit in für das Produkt sinnvolle Teile zu schneiden. Ein Kanban Board zwingt insofern zu agilem Denken, als dass auf die häufige Auslieferung von Wert fokussiert wird. Enthält ein Kanban Board nur große Projekte und bleibt damit auf der Metaebene, gibt es nicht nur wenig Bewegung auf dem Board. Es gibt entsprechend auch keinen am Markt wirksamen Wert. Genau das soll agiles Arbeiten erreichen, die häufige Produktion von Wert, der schnell am Markt wirken kann.

Die Frage, wann ein Task done ist, muss schon gestellt werden, wenn der Task auf todo gesetzt wird. Die Sequenz todo – doing – done muss also als Ganzes verstanden und gelebt werden. Wenn ein Thema noch nicht ausreichend konkret für eine direkte Umsetzung beschrieben werden kann, so kann dies zunächst als Discovery über das Board wandern. Die Ergebnisse einer solchen Discovery können dann in neue, konkrete ToDos überführt werden. Auf diese Weise kann ein simples Kanban Board auch einen Kreislauf darstellen, wie man ihn mit build – measure – learn von Lean Startup kennt.

In den Prinzipien des agilen Manifest steht: „Einfachheit — die Kunst die Menge nicht getaner Arbeit zu maximieren — ist essentiell“. Ein ganz simples Kanban Board mit den Spalten todo, doing und done trägt bereits wesentlich zur Fokussierung auf sinnvolle Arbeitspakete und häufig ausgelieferten Wert bei. Vorausgesetzt natürlich, man ist sich bei jedem einzelnen Task klar darüber, warum und wie er durch die Spalten wandert. Ein Board alleine macht noch lange kein Kanban System aus. Aber agile Boards müssen auch nicht unbedingt komplex aussehen, um die zentralen agilen Werte zu unterstützen. Vielmehr sollte man gerade bei sehr komplexen Boards hinterfragen, welche der Spalten den Status von todo, doing und done repräsentieren und ob nicht eine Vereinfachung sinnvoll ist. Schließlich sollen die Boards nicht zeigen wie komplex die eigenen Prozesse sind, sondern dabei helfen die Prozesse zu verstehen und zu optimieren.

Bild: Simple personal Kanban Board von Kanban Tool auf flickr, Verwendung unter cc Lizenz

Agile Coach und Festanstellung

Die agile Industrie hat den Beruf des „Agile Coach“ hervorgebracht. Dieser ist normalerweise für ein bis wenige Teams zuständig. Ich selber habe auch mal kurz als Agile Coach für zwei Teams gearbeitet und mir dabei recht schnell die Frage gestellt, ob diese Rolle sinnvoll ist.Coach

Interpretiert man den Agile Coach aus der Scrum Perspektive, d.h. als Scrum Master, dann macht die Rolle als Job-Beschreibung nur bedingt Sinn. Der Scrum Master ist eine Vollzeitbeschäftigung nur während der Setup Phase, danach soll die Rolle bzw. Aufgabe aber aus dem (Entwickler-)Team übernommen werden kann. (Hier zeigt sich deutlich, wie durchdacht Scrum als Geschäftsmodell ist, denn die Scrum Rollen bringen direkt den Bedarf nach Zertifikaten und Beratern mit sich.) Scrum Master in Festanstellung passen also eigentlich nicht ins Konzept.

Aber wir reden ja nicht vom Scrum Master sondern vom Agile Coach. Und der kann nicht nur Scrum, sondern mindestens auch noch KANBAN. Ändert das den Sachverhalt? Nein.

Der Hauptgrund gegen Agile Coaches in Festanstellung, die nur für wenige Teams zuständig sind, ist die Selbstorganisation, die sie fördern sollen. Denn Selbstorganisation erfordert Freiraum. Bei aller guter Absicht, wird dieser Freiraum aber nicht dadurch gefördert, dass ein Agile Coach einen breiten Methodenkoffer auspackt und das Team in seinen eigenen Prozessen damit indirekt lenkt. Wenn ein Agile Coach in Festanstellung sagen wir für drei Teams verantwortlich ist, wird er darauf achten, 1/3 seiner Zeit für jedes Team einzusetzen. Der Coach versteht sich als Teil des Teams und will dieses aktiv entwickeln. Wie soll das Team da lernen selbstorganisiert zu arbeiten?

Bedeutet dies also, dass Agile Coaches an sich keine sinnvolle Rolle sind? Nein. Natürlich ist es sinnvoll auf Erfahrungen zurückgreifen zu können und nicht alle Fehler immer selber machen zu müssen. Es geht aber um die Aktivität bzw. Passivität der Rolle. Ein Agile Coach sollte dann aktiv werden, wenn das Team es anfragt. Die Grundeinstellung ist also passiv.

Buurtzorg als ein Paradebeispiel für ein Unternehmen, das auf Selbstorganisation aufbaut, hat für seine selbstorganisierten Teams „Regional Coaches“ installiert. Ein Coach betreut hier 40-50 Teams. Diese sind somit nie direkt Teil des Teams, sondern treten eher als externe Berater auf. Sie haben keine Weisungsbefugnis, sind nicht an die Performance der Teams gekoppelt. Dies zwingt die Teams zur Selbstorganisation, lässt sie gleichzeitig aber nicht alleine. Unterstützend gibt es ein sehr aktiv genutztes Intranet, über das sich Mitarbeiter schnell und direkt über aufkommende Fragen, Best Practices etc. austauschen können. Dies unterstützt Selbstorganisation im Tagesgeschäft, gänzlich ohne Coaches.

Ein Agile Coach ist dann sinnvoll, wenn er es Teams ermöglicht selbstorganisiert zu arbeiten. Dafür brauchen Teams vor allem Freiraum und nicht 24-7 Unterstützung und Beobachtung.

Bild: Coach Don Lear von Ed Uthman auf flickr, Verwendung unter cc Lizenz

Von der Timebox zur Valuebox

TimeboxEine der Kernideen von Scrum ist das Arbeiten in Timeboxes. In einer Timebox gibt es einen klar definierten Start- und Endzeitpunkt. Es geht also um Arbeiten nach der Stoppuhr? Das Bild der Stopp- oder Sanduhr trifft nicht wirklich den Kern von Timeboxing im agilen Kontext. Denn über der Timebox steht nach wie vor der Hauptauftrag der Werterzeugung. Eigentlich sollte man die Timebox also besser als Valuebox bezeichnen.

Das Verständnis der Timebox als Valuebox rückt das eigentliche Ziel in den Vordergrund und stellt auch klar, wieviel Organisation in agilen Methoden notwendig ist. Seine Zeit so zu planen, dass am Ende ein vorzeigbares Ergebnis entsteht, ist nicht einfach. Dabei hilft das hohe Engagement und das Commitment des Einzelnen. Wer will schon am Ende eines Sprints nichts zu präsentieren haben! Agile Arbeiter wollen wollen etwas bewegen, sie wollen Wert erzeugen und zwar in sinnvollen Zeiteinheiten.

Wenn die Zeit, die zur Verfügung steht, durch eine Timebox ein klar definiertes Ende hat und am Ende gleichzeitig einen sinnvollen Wert vorzeigbar sein soll, dann muss innerhalb der Timebox ggf. der Wert selber angepasst werden. Aus dem Projektmanagement kennen wir das Dreieck aus Time, Budget und Scope:

  • Die Dimension Zeit ist beim Timeboxing wie schon beschrieben fest. Der einzelne Sprint hat eine klar definierte Länge. Zeit wird damit nur verhandelbar, wenn zusätzliche Sprints geplant werden.
  • Das Budget ist normaler Weise auch klar begrenzt, wenn unter Budget vor allem Manpower gemeint ist. Natürlich kann man das Team kurzfristig erweitern, häufig jedoch ist dies aufgrund der hohen Initialkosten im Sinne der Anlernphase nicht sinnvoll.
  • Damit bleibt nur der Scope, also der geplante Umfang bzw. der abzuliefernde Wert, der innerhalb der Timebox angepasst werden kann. Wenn Komplikationen oder Aufwände sichtbar werden, die in der ersten Schätzung nicht erkennbar waren, dann muss darauf mit Anpassung des Scopes reagiert werden.

Product Owner und Stakeholder müssen dies akzeptieren bzw. fördern. Am Ende ist es für das Produkt und das Unternehmen wichtig, dass möglichst früh ein nutzbarer Wert entsteht, auch wenn dieser zunächst unter den ersten Erwartungen bleibt. Durch agile Methoden wollen wir verhindern, dass einzelne Arbeitspakete über Monate verzögert werden und somit auch über Monate kein Wert am Markt geschaffen wird. Wer schnell Wert produzieren will, der muss akzeptieren, dass dieser Wert in kleinen Einheiten erbracht wird. Ohne dieses Verständnis bleibt die Timebox als leere Methodik zurück. Erst durch das Verständnis der Timebox als Valuebox lassen sich agile Methoden mit Mehrwert praktizieren.

Bild: In Search Of Lost Time von Alexander Boden auf flickr, Verwendung unter cc Lizenz

Sprints sind keine Schleifen sondern eine Kette

Bei den Vorbereitungen zu einigen Seminaren bin ich mal wieder über eine der bildhaften Darstellungen von Scrum gestolpert. Je nach Umfang zeigen diese Bilder alle Aktivitäten, Artefakte, Rollen oder auch alles zusammen. Dabei wird der Sprint eigentlich immer als eine Schleife bzw. geschlossener Kreislauf dargestellt. Nach dem Sprint ist also vor dem Sprint!?

Nein, eben nicht! Denn nach dem Sprint hat sich unser Produkt verändert. Die Welt ist nicht mehr die gleiche wie noch vor 2-4 Wochen. Das ist so ähnlich wie mit der Jahresuhr, die wir schon im Kindergarten erklärt bekommen. Wenn der Winter vorbei ist, dann geht es mit dem Frühling wieder von vorne los. Nur, dass der nächste Frühling eben nicht der gleiche ist wie letztes Jahr. Die Jahresuhr suggeriert, dass sich alles immer wiederholt. Aber das stimmt nicht. Alles verändert sich ständig.

Und so ist es auch mit bzw. durch Scrum. Der Prozessrahmen mag der gleiche bleiben, aber das Team und vor allem das Produkt verändern sich. Scrum ist also nicht die eine Schleife, die immer wieder durchlaufen wird, Scrum ist eine Aneinanderreihung von Schleifen. Und das ist ein erheblicher Unterschied. Denn dies bedeutet, dass es nicht darum geht den Prozess zu wiederholen, sondern das Produkt basierend auf neuen Erkenntnissen zu entwickeln. Ein Backlog kann eigentlich einen Sprint nicht unbeschadet überleben. Wenn die Ergebnisse des letzten Sprints die Planung des nächsten nicht verändern, dann ist arbeiten in Iterationen sinnlos. Scrum soll nicht primär einen Prozess etablieren, Scrum soll Produktentwicklung unterstützen.

Lean Startup ist ein sehr gutes Beispiel für diesen zentralen Sinn von agilem ArbKettengliedereiten. Die Anwendung agiler Methoden wird hier vorausgesetzt. Lean Startup richtet den Fokus auf das Ergebnis und die Anpassbarkeit durch agiles Arbeiten. Und nach dem MVP ist definitiv nicht vor dem MVP. Das eine hat ohne das andere überhaupt keine Bedeutung. Erst die Verkettung von MVPs stellt eine sinnvolle Anwendung der agilen Ideen dar, um so im Sinne von Lean startup am Ende der Kette das für das Marktsegmente passende Produkt gefunden zu haben.

Deshalb ist es so wichtig den vermeintlichen Widerspruch zwischen dem agilen Manifest (Individuen und Interaktion sind wichtiger als Werkzeuge und Prozesse) und einem Framework wie Scrum (Prozess) klar aufzuzeigen. Bleibt man bei der Einführung agiler Prozesse stehen, hat dies absolut nichts mit Agilität zu tun. Erst wenn die Prozesse zur agilen Entwicklung des Produktes genutzt werden, kann man anfangen von agilem Management zu sprechen. Denn agiles Management darf nicht als Methode auf der operativen Ebene verstanden werden, agiles Management betrifft das gesamte Unternehmen, um so die Erkenntnisse und schnellen Ergebnisse auf operativer Ebene für die taktische und strategische Ausrichtung des Unternehmens nutzen zu können.

Bild: Chain Linkage von Max Klingensmith auf flickr, Verwendung unter cc Lizenz

Agilität ist eine Geschäftsentscheidung

„Agility scales, Agile Doesn’t“, schreibt Jurgen Appelo . Demnach müssen wir zwischen agile mit „kleinem a“ und Agile mit „großem A“ unterscheiden, um die Skalierbarkeit des Ansatzes richtig einschätzen zu können. Kann eine Diskussion noch ernst genommen werden, die nur noch schriftlich abgehalten werden kann, weil Wörter ihre Bedeutung nur noch durch das richtige Schriftbild wiedergeben können? Wohl kaum!

Völlig zu recht ergeben sich aus derart akademischen Analysen von Agilität Anti-Haltungen wie z.B. programming motherfucker. Nicht, dass diese Haltung die Probleme lösen würden, vor denen Unternehmen stehen. Aber allzu verständlich ist diese Haltung vor oben dargestelltem Diskussionsniveau auf jeden Fall.

open_for_businessAgilität ist keine Sekte oder Metaphysik, Agilität ist eine Geschäftsentscheidung. Agil ist kein Selbstzweck, sondern soll den Zweck des Unternehmens best möglich unterstützen. Wenn agil sein dies unterstützt, dann ist es gut, egal ob groß, klein oder sonst wie geschrieben. Wenn es das aber nicht tut, dann hat es langfristig keine Berechtigung. Wir brauchen also nicht agile vs Agile vs Agility, wir brauchen – oder besser: haben die Chance auf – Unternehmen, die auf Basis agiler Prinzipien arbeiten, um so ein attraktives, verantwortungsvolles Arbeitsumfeld und ein sich entwickelndes Geschäft zu etablieren. Das bedeutet, dass Agilität nicht als akademisches Objekt verstanden werden darf, sondern immer nur im Kontext der konkreten Anwendung sinnvoll zu diskutieren ist.

Das agile Manifest kann dafür eine gute Grundlage, ein Ideengeber sein, egal wie groß das Unternehmen ist. Mehr oder weniger ist das agile Manifest aber eben nicht, egal ob groß oder klein geschrieben. Denn natürlich muss jeder für sich und sein Unternehmen selbst entscheiden, in welcher Übersetzung der ein oder andere Leitsatz relevant sein kann. Eine Standard-Lösung für ein agiles Unternehmen kann es nicht geben.

Bild: building an open source business von opensource.com auf flickr, Verwendung unter cc Lizenz

Wann ist Lean Startup eigentlich fertig?

Was Lean Startup bedeutet, habe ich hier in diversen Beiträgen bereits erläutert. Einen ganz relevanten Teil habe ich allerdings bis dato ausgelassen:

  • Wann ist man mit Lean Startup eigentlich fertig?
  • Wie kann eine Transformation in einen „nicht mehr“ Lean Startup ausssehen?

The road endsZunächst zu der Frage, wann man mit Lean Startup fertig ist. Gemäß dem Konzept ist man dann fertig, wenn man eine validierte Geschäftsidee hat. So weit so logisch, aber woran erkenne ich das? Es wird trotz aller Testerkenntnisse immer eine Art von Restunsicherheit bleiben. Nie werde ich 100%ige Sicherheit darüber haben, dass meine Geschäftsidee, nach Lean Startup untersucht, wirklich funktioniert oder es nicht vielleicht doch noch einen besseren Ansatz gibt. Definitiv wird aber der Punkt kommen, an dem die Finanzierung des Vorhabens in den Mittelpunkt rückt, einfach weil das Geld ausgeht. Hier muss man zwei Fälle unterscheiden, die mit der Frage zu tun haben, wer mein Kunde ist: der Endkunde oder der Investor?

Ist man im wesentlichen auf einen Exit oder reichlich Fremdkapital aus, dann landet in der Kasse nicht das, was mein Geschäft am Markt verursacht, sondern das, was die bisherigen Erkenntnisse bei den Investoren frei machen. Im Extremfall braucht man dabei die Lean Startup Phase gar nicht verlassen, weil das Geschäft verkauft wird, bevor eine andere Phasen relevant wird. Das gleiche Szenario ergibt sich, wenn man als Innovationsabteilung auf Lean Startup setzt. Der Kunde ist in dem Fall die Abteilung, an die man die Idee verkauft. Die Skalierung läuft in beiden Fällen in einer anderen Organisation unter anderer Führung. Lean Startup endet in diesem Szenario als mit dem Verkauf der Idee. Wenn sich die Idee rein über Lernerfolge verkaufen lässt, muss die Lean Startup Phase wie gesagt nie verlassen werden. Je wichtiger konkrete Markterfolge für den Verkauf werden, desto mehr muss man vom Lean Startup zum selbsttragenden Geschäft kommen.

Soll sich das Geschäft von selber tragen, reicht nicht die Phantasie der Geldgeber, es geht dann um Cashflow und Gewinne aus dem operativen Geschäft. Spätestens wenn vermehrt Geld in das Marketing fließt, sollte man die Lean Startup Phase zumindest modifizieren. Denn Lean Startup lebt direkt von der quasi Risiko freien Umgebung. Steigt aber mein Kapitaleinsatz, steigt auch mein Risiko. Und dann werde ich aus unternehmerischer Perspektive verstärkt auf Qualität statt auf Erkenntnisgewinn achten. Wie so oft im Leben, gibt es hier keine schwarz-weiße Welt. Den einen, klar definierten Punkt, an dem Lean Startup endet, gibt es nicht. Und genau das macht die Transformation gleichzeitig möglich und schwierig. Möglich, weil es eine Übergangsphase gibt, schwierig, weil man ggf. zu spät die Zeichen der Veränderung erkennt.

Dies führt uns zur zweiten Fragen, nämlich wie der Übergang aus der Lean Startup Phase aussehen kann. Ein Lean Startup will Lernen. Lernen tut man vor allem auch aus Misserfolgen, die in diesem Sinne keine Misserfolge sondern Lernerfolge sind. Ein Lean Startup probiert also möglichst viel aus. Ist aber diese Phase vorbei, dann brauchen wir nicht mehr alles ausprobieren, denn wir wissen dann ja, wie das Produkt aussieht und wer unser Kunde ist. Wir wollen nicht mehr nur lernen, sondern das bereits Gelernte in Umsatz, Cashflow oder ähnliches verwandeln. Der Entrepreneur des Lean Startup muss zum Manager der Skalierungsphase werden. Dies muss natürlich nicht bedeuten, dass aus dem „coolen“ Startup über Nacht eine Spießerbude werden soll, oder dass Lernen und Ausprobieren aus dem Unternehmensvokabular gestrichen werden sollen. Aber wenn viel Geld in die Bewerbung oder Produktion des Produktes fließt, dann sollte dies bitte kein MVP sondern ein Qualitätsprodukt sein. Schließlich haben wir es dann auch nicht mehr mit den First Modern zu tun, die noch beide Augen zu drücken, weil es ihnen vor allem um die Innovation an sich geht. Wir haben es dann mit den Kunden zu tun, die für ihr Geld vor allem auch entsprechenden Wert erhalten wollen.

Diese Transformation ist vor allem deshalb schwierig, weil hinter den unterschiedlichen Management-Ansätzen oft auch unterschiedliche Menschen stehen. Kaum jemand wird gleichzeitig der perfekte Entrepreneur wie auch Manager sein. Entweder man versucht also durch entsprechendes Staffing diese Transformation zu unterstützen, oder man setzt auf Erfahrungsaustausch und Coaching. In diesem Zusammenhang wird der Ansatz von Lean Startup im Unternehmen wieder sehr spannend, weil hier durch den permanenten Austauschen zwischen klassischem und Lean Startup Management die Übergangsphase optimal begleitet werden kann.

Bild: The road es….Uhh no it doesn’t von Nicholas Canup auf flickr, Verwendung unter cc Lizenz

Scrum ist auch nur ein Produkt

Scrum hat als leichtgewichtiges Framework für IT-Projekte eine Erfolgsgeschichte geschrieben, die mittlerweile deutlich über die Software-Branche hinaus geht. Dabei basiert der Ansatz im wesentlichen auf den Prinzipien des agilen Manifest. Dessen erster Leitsatz ist für mich dabei der zentralste:

  • Wir schätzen und Individuen und Interaktionen mehr als Prozesse und Werkzeuge.

Wenn man diesen Leitsatz ernst nimmt, dann schließt dies einen fest vorgegebenen prozessualen Rahmen für agiles Arbeiten aus. Statt sich auf Prozesse und Werkzeuge zu konzentrieren, sollte man auf die Individuen eingehen, die als Team zusammenarbeiten. Besucht man Konferenzen oder Workshops, stellt man aber schnell fest, wie sehr sich die agile Community über Tools und Prozesse unterhält. Es wird über Rollen diskutiert, es wird nach den Top 10 Ratschlägen für einzelne Artefakte und Routinen gesucht, aufgrund der Größe kaum noch druckbare Modelle sollen zeigen, wie man agil skalieren kann. Nur irgendwie fragt niemand nach den Menschen, um die es ja eigentlich gehen soll…

Das Aufwändige an der agilen Idee ist, dass sie zum selbständigen Denken und Handeln zwingt.

  • Das perfekte Board, das jeden Fluss und alle Probleme visualisiert
  • das eine Schema für die Retro, das in jeder Situation funktioniert
  • die 10 Grundregeln für Führung im agilen Kontext

Alles das gibt es nicht! Und deshalb ist es gefährlich Produkte wie Scrum mit Agilität zu verweKaufmannsladenchseln. Ja, Scrum ist ein Produkt! Scrum verkauft Zertifikate. Scrum will über Prozesse sprechen und Tools vermitteln, um Bücher und Beraterstunden an dem Mann zu bringen.

Bitte nicht falsch verstehen, ich halte Scrum für einen guten Ansatz. Aber wir dürfen nicht den Fehler machen, aus einem Produkt eine Art Religion zu machen. Seminare, Zertifikate und Weiterbildungsangebote sind sinnvoll, solange es um Hilfe zur Selbsthilfe geht. Zu schnell tappen wir aber in die Falle, uns an vorgegebene Fahrpläne zur agilen Transformation, an Prozess-Charts und Best Practices zu klammern. Dies ist natürlich auch entsprechend einfacher und verlockend. Aber solange gilt „Individuen und Interaktionen über Prozesse und Tools“, solange müssen wir uns mehr um die Menschen und die Zusammenarbeit in unserem Unternehmen kümmern, als um vorgegebene Prozesse und Tools.

Man baut agile Organisationen auf, um mit Hilfe von Selbstorganisation die wachsende Komplexität in den Griff zu bekommen. Wer sich selbst organisieren soll, der braucht dafür aber Freiheitsgrade und keine vorgefertigten Produkte. Bis zu einem gewissen Grad ist dieser Freiheitsgrad sogar in das Produkt Scrum selbst eingebaut. So soll sich z.B. der Scrum Master im Laufe der Zeit überflüssig machen. Dort, wo für jedes Team „Agile Coaches“ in Festanstellung gesucht werden, liegt somit der Verdacht nahe, dass die agile Idee nicht wirklich ernst genommen oder verstanden wird. Selbstverständlich ist es sinnvoll, erfahrene Scrum Master o.ä. im Unternehmen zu haben, wenn man eine agile Organisation aufbauen oder werden will. Aber weder ist es sinnvoll einfach alle alten Projektmanagement-Planstellen in agile umzuwandeln, noch ist es sinnvoll, Scrum oder andere Methoden / Produkte aus Prinzip einzufordern. Vielmehr muss es darum gehen, die individuellen Bedarfe der eigenen Organisation zu erkennen und zu bedienen.

Scrum ist nicht nur ein tolles Framework, es ist auch ein sehr erfolgreiches und durchdachtes Produkt. Bitte verwechselt es nicht mit Agilität. Um es mit den Worten von Dave Thomas zu sagen: Agile Is Dead (Long Live Agility)!.

Bild: Kaufmannsladen von Anja Leidel auf flickr, Verwendung unter cc Lizenz