Archiv der Kategorie: Organisation

Organisation beschreibt nicht nur definierte Prozesse und strukturelle Rahmen, sondern auch die sozialen Strukturen eines Unternehmens. Während die klassische Organisationslehre aus Top-Down Perspektive argumentiert, wird im agilen Kontext stärker auf Selbstorganisation gesetzt. Die Vor- und Nachteile, die Voraussetzungen hierfür und die Möglichkeiten, die sich daraus ergeben, sollen hier diskutiert werden.

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

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

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

Lean Startup – eine Kritik

Nach meinem Vortrag auf der ‚manage agile‘ zum Thema Lean Startup im Unternehmen, möchte ich an dieser Stelle über zwei Kritikpunkte an Lean Startup schreiben, die auch in der Diskussionsrunde angesprochen wurden. An dieser Stelle nochmals vielen Dank an alle Zuhörer und die angeregten Diskussionen!

Eine zentrale Kritik muss an dem Wunsch nach Wissenschaftlichkeit ansetzen. Split Tests sind eine gute Möglichkeit bestimmte Fragen nicht selber, sondern vom Kunden klären zu lassen, keine Frage. Je umfangreicher aber die Fragestellung, desto schwieriger der dafür notwendige Test. Da Lean Startup nicht dafür da ist, verschiedene Layouts gegeneinander zu testen, sondern auf Ebene des Geschäftsmodells ansetzt, sind die zu klärenden Fragen per se schwierig bis komplex. Viele Fragestellungen werden sich kaum bis gar nicht testen lassen. Bzw. würde ein statistisch valider Test oft eine Größenordnung erreichen, der ein Lean Startup weder von der notwendigen Kundenbasis noch von der eigenen Ressourcenstärke her gewachsen sein dürfte.

Nun kann man entgegen, dass man ja nicht wissenschaftlich aber zumindest Fakten basiert, d.h. empirisch gestützt vorgehen kann. Die gesammelten Daten halten dann nicht unbedingt einer wissenschaftlichen Prüfung stand, aber zumindest liegen Daten vor und Entscheidungen müssen somit nicht aus dem Bauch getroffen werden. Jedoch vergrößert dies in gewissem Sinne die Problemstellung noch weiter. Denn so könnte jedes gesammelte Datum direkt als Beleg für oder wider eine Entscheidung eingesetzt werden. Dies kommt im schlimmsten Fall Willkür gleich, jedoch im Glauben die Wahrheit zu kennen und danach zu handeln. Auf der anderen Seite kann diese Sichtweise aber natürlich tatsächlich sehr hilfreich sein und muss auch ihre Berechtigung haben. Wenn man richtig einschätzt, dass die vorliegenden Daten keine wissenschaftliche Wahrheit sind, aber sehr wohl gedeutet werden können, dann können die daraufhin getroffenen Entscheidungen diskutiert und in den richtigen Kontext gesetzt werden. Die endgültige Wahrheit werden wir an vielen Stellen nie erfahren, deshalb dürfen wir aber nicht davor zurückschrecken uns an sinnvollen Daten zu orientieren.

Ein zweiter zentralen Kritikpunkt wird auch von Peter Thiel in dem Buch „Zero to One“ erwähnt. Er führt aus, dass für großen Entwicklungen eine große, klare Vision nötig ist. Man solle deshalb ein „minimum viable product“ (MVP) vergessen, da die Konzentration auf die kleinen Schritte die Entstehung von etwas Großem verhindert. Dem muss ich aus eigener Erfahrung zumindest teilweise zustimmen. Das schnelle Lernen und Ausprobieren kann tatsächlich davon Ablenken, eine größere Vision zu entwickeln. Problematisch wird dies natürlich erst dann, wenn die Startup Phase abgeschlossen ist und man das Produkt skalieren will. Fehlt dann die Vision, so wird das Produkt und damit auch das Geschäft vermutlich in sehr kleinem Rahmen bleiben.

Auf der anderen Seite muss aber gesagt werden, dass Lean Startup als Konzept nicht die Phase der Produktvision fokussiert, sondern die schlanke Verprobung einer bereits vorhandene Produktidee am Markt. Für jemanden, der Lean Startup einsetzen will, bedeutet dies also, dass parallel zum Lean Startup immer auch an der Vision gearbeitet werden muss. Jedes Geschäft braucht eine langfristige Perspektive, wenn es dem Gründer nicht nur Arbeit sondern auch Ertrag bringen soll. Ein MVP ist dabei eine sehr auf den Punkt gebrachte Entwicklung eines Proto- oder Basistypen. Und dies kann sicherlich auch dann helfen, wenn man eine größere Vision vor Augen hat.

Heißt dies also, das man besser die Hände von Lean Startup lassen sollte? Nein. Wenn die Organisation bzw. das Team ausreichend Erfahrung mit agilem Arbeiten und Lernen hat und wenn die zu klärende Fragestellung in den Kontext von Lean Startup passt, dann spricht nichts gegen dieses Konzept. Allerdings sollte man die Schwachstellen kennen und entsprechend berücksichtigen. Dann kann man auch mit kleinen Schritten zu etwas Großem kommen, ohne sich dabei die Wahrheit hinzubiegen, wie es einem gerade gefällt.

agiler Statusreport

Auf Paul Klee geht das Zitat zurück: „Kunst gibt nicht das Sichtbare wieder, sondern Kunst macht sichtbar.“ Ich muss gestehen, dass ich diese Zeile nicht kannte, als ich vor einiger Zeit – mal wieder – auf der Suche nach einer Möglichkeit war, den aktuellen Status des Produkts, das ich betreue, auf einen Blick sichtbar zu machen. Mir wurde – mal wieder – recht schnell klar, dass klassische Berater-Logik nicht funktioniert. Ein komplexes Produkt lässt sich nicht MECE (mutuale exclusive and collectively exhaustive) zerlegen; zumindest dann nicht, wenn man schnelle, operativ benutzbare Ergebnisse haben will. Es gibt auch nicht das eine Template, dass für jede Situation passt. Die Realität passt eben nicht auf einen standardisierten, vorstandstauglichen Einseiter.

Auf der Suche nach einem alternativen Ansatz bin ich auf die Idee gekommen, ein Bild zu malen. Wenn ich die Komplexität nicht in logische Strukturen gegossen bekommen (es wäre dann wohl auch keine Komplexität mehr!?), dann verzichte ich doch einfach auf diese Strukturen. Und wenn ich die Zusammenhänge ohnehin nicht übersichtlich und umfassend abbilden kann, dann kann ich auch gleich ganz darauf verzichten. Das Bild das ich gemalt habe war am Ende eine Landkarte des Produktes.

Projektreport_Karte

Eine solche Landkarte, unterliegt nicht der Notwendigkeit Themen nach Logik zu trennen. Einzelne Aspekte können mehrfach unter verschiedenen Namen auftauchen, die Namen und Bezeichnungen können doppeldeutig sein.  Auch ist es irrelevant, die Zusammenhänge abzubilden. Man kann bei Bedarf Themen durch geografische Nähe bewusst zusammenführen oder durch natürliche Grenzen Themenfelder trennen. Aber dies muss nicht sein. Diese künstlerische Freiheit ermöglicht es, einen wirklichen Überblick zu erarbeiten. Zudem kann man bei der Gestaltung nach Belieben (schwarzen) Humor walten zu lassen, was insbesondere dann hilft, wenn es dem Land mal gerade nicht so rosig geht. Und wie bei echten Karten ändert sich auch diese Produkt-Landkarte im Laufe der Zeit, was dann im Zeitraffer betrachtet schon viel über die Entwicklung des Produkts verrät.

Eine solche Karte kann als Grundlage für eine Wetterkarte dienen, die für den betrachteten Zeitraum aufzeigt, wie es um das Land / Produkt steht. Ein Statusreport besteht dann z.B. aus Sonne, Regen, Blitzen etc., die über die Karte verteilt werden. Ebenso lässt sich über eine farbige Legende der Status in die Karte einzeichnen. Die Aussage einer solchen Momentaufnahme ist nicht schlechter als ein „ordentlicher“ Statusreport im Berater konformen Template. Allerdings erfordert ein solche Darstellung eine gemeinsame Diskussion bzw. Interpretation und fördert damit die Kommunikation und Interaktion.

Auf den ersten Blick mag die Idee ein Geschäft durch ein Bild zu steuern befremdlich erscheinen, doch damit kann genau das erreicht werden, was Paul Klee über Kunst sagt. Nicht das Sichtbare über Temples und Reports wieder zu geben, sondern Dinge durch gemeinsame Interpretation und Kommunikation sichtbar machen. Gerade im agilen Kontext ist dieses sichtbar machen zwingend, damit selbstorganisierte, interdisziplinäre Teams den notwendigen Gesamtblick auf das Produkt erhalten. Außerdem ist Interaktion ja bekanntlich einer der wesentlichen agilen Werte. Und die hier vorgestellte Form des agilen Statusreport fördert ebene diese Interaktion in besonderem Maße.

Wir nutzen diese Form des agiles Statusreports wöchentlich im Team, um gemeinsam die vergangene Arbeitswoche Revue passieren zu lassen. Anders als in aufpolierten Statusberichten, in denen nur die Top-Prio-Themen auftauchen, verschwinden auf einer Produktkarte keine Themen. Man kann dadurch z.B. erkennen, worum man sich, vielleicht schon viel zu lange, nicht gekümmert hat. Die Diskussion macht aber z.B. auch in anstrengenderen Phase die Sachen sichtbar, die richtig gelaufen sind.

Darüber hinaus nutzen wir die Wetterkarte als Einstieg in unser Sprint Review Meeting. Hier kann mit dem und für das gesamten Team den Status des Produkts diskutieren. Dadurch können die unterschiedlichen Perspektiven, die ein interdisziplinäre Team auf sein Produkt hat, beleuchtet werden, so dass eine Art 360° Blick entsteht.

Lean Startup im Unternehmen

Lean Startup im UnternehmenLean Startup ist in den Konzernen und etablierten Unternehmen dieser Welt angekommen. Dabei geht es nicht (nur) um Bullshit-Bingo und vorgetäuschten Zeitgeist, sondern zumindest auf operativer Ebene um die Hoffnung, den oftmals festgefahrenen Strukturen und Prozessen einen Ansatz mit sehr hoher Lerngeschwindigkeit und dem Fokus auf Umsetzung entgegenzusetzen. Ich habe Lean Startup im Unternehmen mit rechtlich nicht eigenständigen Produkten in seiner wohl extremstem Form im Unternehmen integriert kennen gelernt. Das muss natürlich nicht zwingend so sein, dürfte aber die Besonderheiten des Einsatzes von Lean Startup im Unternehmen am deutlichsten zu Tage bringen.

1. Entrepreneurs are everywhere

Agiert man im Unternehmen, so muss man das Everywhere-Entrepreneur-Prinzip insofern besonders behandeln, als das man statt von Entrepreneueren von Managern umzingelt ist. Manager werden nicht für ihren Unternehmergeist eingestellt, sondern um ein Unternehmen zu managen und arbeiten damit für und nicht als Unternehmer. Das Selbstverständnis vieler Manager sieht indes häufig anders aus. Und wenn dann auch noch jemand mit Lean Startup nicht nur die klassischen Managementweisheiten in Frage stellt, sondern auch noch Freiheiten eines Unternehmers einfordert, dann sind Probleme vorprogrammiert. Wer Lean Startup im Unternehmen betreiben will, der muss im Zweifel also bereit und fähig sein, die eigenen Ideen dem „Unternehmergeist“ des Management zu opfern. Wenn sich am Ende alle als Unternehmer fühlen, dann sind die Chance hoch, dass das Projekt auch mit der nötigen Hingabe von allen Seiten betrieben wird. Dafür erhält man im Gegenzug gute, Praxis erprobte Management-Ratschläge quasi umsonst. Andere müssen dafür entweder Berater bezahlen oder ihre Firma an VC-Geber verschachern.

2. Entrepreneurship is Management

Im Bezug auf das Prinzip Management muss man beim Einsatz im Unternehmen insbesondere den Risikofaktor anders gewichten. Denn im schlimmsten Fall fällt das Risiko auf das Kerngeschäft zurück. Handelt man zwar konzeptionell als Lean Startup, rechtlich aber im Namen einer etablierten Marke, dann sollte man z.B. mit rechtlichen Grauzonen deutlich vorsichtiger umgehen. Für diesen Nachteil kauft man sich auf der anderen Seite  Vorteile in Form von Synergie ein, wenn man z.B. etablierte, verlässliche Prozesse sowohl zum Kunden als auch im Backoffice nutzen kann. Entscheidend ist es an dieser Stelle den richtigen Mix zwischen Draufgängertum und Null-Fehler-Mentalität zu finden. Das ist dann eine echte Managementaufgabe, denn weder darf die Mannschaft Angst haben Ideen auszuprobieren, noch darf an den falschen Stellen unachtsam gehandelt werden. Lean Startup im Unternehmen ist an dieser Stelle an Drahtseilakt.

3. Validated Learning

Wenn man Lean Startup im Unternehmen machen will, dann muss das Management des Unternehmens Willens sein, neues Wissen zu akzeptieren. Vor allem auch dann, wenn diese neue Wahrheit weh tut. Dabei muss man ganz klar sagen, dass dies nur den wenigsten wirklich gelingt. Schließlich arbeitet man ja mit erfahrenen Managern, die genau wissen wie das Geschäft zu laufen hat. Unerwartete oder unbequeme Testergebnisse werden dann in Frage gestellt oder im schlimmste Fall einfach mit der Management-Karte beiseite gewischt. Dies ist aus meiner Sicht der kritischste Punkt für Lean Startup im Unternehmen und gleichzeitig das größte Lernfeld für etablierte Manager.

Auf der anderen Seite muss anerkannt werden, dass man, nur weil man nach Lean Startup validated learning generiert hat, noch lange nicht die Wahrheit ans Tageslicht gebracht haben muss. Gerade wenn wirklich fundamentale Hypothesen des Geschäftsmodells getestet werden, sollte man im Zweifel lieber einen Testfall zu viel als zu wenig planen. Einige Fragestellungen lassen sich nur sehr schwer mit einem Test beantworten, das Aufsetzen einer wirklich neutralen Testanlage ist dabei mehr als nur anspruchsvoll. Gefragt ist am Ende also der „sweet spot“ zwischen Startup Wissenschaft, Management Weisheit und Unternehmerbauch.

4. Innovation Accounting

Mit dem Innovation Accounting tuen sich etablierte Unternehmen aus meiner Erfahrung sehr schwer, denn weder die actionable metrics noch das dazugehörige MVP passen so recht in das klassische Weltbild. Betreibt man ein Lean Startup im Unternehmen, dann ist man in einem bestimmten Grad dazu verpflichtet klassische Kennzahlen, Forecasts und Planungen zu liefern. Das ist zwar nicht immer sinnvoll möglich, doch sollte man dies nicht nur verfluchen. Die frühe Auseinandersetzung mit klassischem Controlling kann durchaus dabei helfen, einige nötige, wenn auch nervige Hausaufgaben zu machen, die viele gerne vergessen. Kostentransparenz z.B. hilft immer, wirklich immer.

Und klassische Unternehmen können wahnsinnig viel lernen, wenn sie begreifen was ein MVP ist. Dies ist nämlich nicht die Ausrede für halbfertige Produkte. Es ist das Produkt, das eben genau nur die zu klärende Frage beantwortet. Wie viel weniger Geld, Ressourcen, Liebe und Mitarbeiter hätte man bis dato opfern müssen, wenn man früher begriffen hätte, dass man mit einem MVP Testergebnisse mit wenig Entwicklungsaufwand und dabei mit Split-Tests auch noch ohne großes Risiko am Markt  erzielen kann?

5. Build-Measure-Learn

Build-Measure-Learn als Prinzip wird innerhalb eines Unternehmens dann speziell, wenn eine wirklich hohe Entwicklungsgeschwindigkeit entsteht, die deutlich über der der originären Organisation liegt. Durch die geringe Halbwertszeit des Wissens in einem Lean Startup kann es schnell zu einem Ungleichgewicht in der jeweils gefühlten Entscheidungssituation kommen. Wenn sich das Top-Management sagen wir quartalsweise mit dem Projekt befasst, dann kann dies für das Lean Startup selber eine gefühlte Ewigkeit sein. Hier besteht die Gefahr, dass die Beteiligten schlicht aneinander vorbeireden. Als Lean Startup tut man gut daran, sich möglichst vage Entscheidungen / Aussagen abzuholen, damit der eigene Gestaltungsspielraum groß genug bleibt und man nicht ständig nach dem Steuerungskreis rufen muss. Das Management wiederum tut gut daran mehr aus einer Coaching Rolle zu agieren, denn als strategische Steuermänner.

Dem Build-Measure-Learn des Lean Startup steht im klassischen Management Plan-Do-Check-Act entgegen. Da beide Zyklen hinreichend generisch sind, kann man über die konkreten Unterschiede oder Gemeinsamkeiten sicher viel diskutieren. Build-Measure-Learn muss man dabei aber weniger als Prozess-Blaupause sondern viel mehr als KANBAN-Ansatz verstehen. Schließlich geht es darum, die Durchlaufzeit zu minimieren und möglichst wenig Verschwendung zu erzeugen. Der konkrete Prozess muss dabei als Variable angesehen werden, die Bestandteil der kontinuierlichen Verbesserung bzw. Ausrichtung auf das Ziel des Lean Startup ist: Wissen generieren.

Fazit

Es gibt eine ganze Reihe an Chancen für Unternehmen und Lean Startup voneinander zu lernen. Dazu ist es nötig zwischen den Welten zu wandeln, was auf beiden Seiten Toleranz und Lernbereitschaft erfordert. Die Gefahr dabei ist natürlich, dass man vor lauter hin und her weder die eine noch die andere Seite ausreichend bedient und am Ende gar nichts erreicht. Wenn es aber eine echte Bereitschaft gibt, den Ansatz im Unternehmen zu etablieren, bekommt man neben Geschwindigkeit auch eine agile Keimzelle geschenkt. Und wenn diese Keimzelle sich der Organisation öffnet, dann kann sie eine nachhaltige Transformation auslösen und gleichzeitig noch dazulernen.

Lean Startup – Build-Measure-Learn

lean_startup_build measure learnDer klassische Management-Zyklus wird häufig in der Form plan-do-check-act beschrieben. Das Lean Startup setzt diesem den build-measure-learn Zyklus entgegen. Man kann sicher vortrefflich darüber diskutieren, ob nun einzelne dieser Begriffe das gleiche meinen und ob sich nicht sogar der eine in den anderen Zyklus überführen ließe.

Was aber sicher ein Unterschied in der dahinter liegenden Philosophie ist, ist die Idee des Lean Startup den Zyklus möglichst schnell und effizient zu durchlaufen. Die Durchlaufzeit der einzelnen Entwicklungsschritte build, measure, learn soll optimiert werden. In dieser Idee wird der Bezug zum Lean Management deutlich. Die Steuerung des Lean Startup mit dem Prozess build-measure-learn kann man so auch als KANBAN Ansatz interpretieren. Dies ist ein ganz zentraler Gedanke, denn damit wird Lean Startup eben nicht nur zu einer Methode, die nach Schema F anzuwenden ist. Vielmehr wird Lean Startup damit zu einem sich selbst hinterfragenden Konzept, zu einer kontinuierlichen Verbesserung mit dem Ziel relevantes Wissen in unbekanntem Kontext zu sammeln. Build-Measure-Learn ist so generisch gehalten, dass die konkrete operative Ausgestaltung je nach Fall definiert werden muss. Damit ergibt sich auch die Chance diese operative Übersetzung kontinuierlich zu optimieren, ohne dabei den Fokus auf den Grundprozess zu verlieren.

Außerdem ist die Verwendung der Begriffe build, measure, learn insofern sinnvoll, als dass diese die Ziele des Lean Startup verdeutlichen und zusammenfassen. Es geht darum etwas zu lernen (learn), auf Basis von Kennzahlen (measure), mit einem Produkt, das genau dafür gebaut wird (build).

Lean Startup und das MVP

lean_startup_innovation accountingInnovation und Accounting scheinen eher Gegensätze zu sein. Da Lean Startup nach Eric Ries als wissenschaftliche Methode über Testverfahren lernen will, ist es nur plausibel, auch das Controlling und die Steuerung des Unternehmens an Kennzahlen auszurichten, die den Gegenstand des Lean Startup widerspiegeln. Im Kontext Lean Startup spricht man von actionable metrics. Es geht um solche Kennzahlen, die Handlung für die Organisation auslösen. Als begriffliches Gegenpaar wird der Begriff vanity metric verwendet, den ich als Golfplatz-Kennzahl bezeichnen würde. So wie einige Unternehmen Geschäft für die WuV statt für ihre Kunden zu machen scheinen, so beschäftigen sich viele mit Kennzahlen die zwar toll klingen, aber nur geringen Erklärungs- und Handlungsbedarf mit sich bringen.

Aus meiner Sicht sehr eng verbunden mit der Idee der actionable metric ist der Begriff des MVP, des minimum viable product. Es geht um den Umfang des Produktes, der so gerade eben den zu testenden Umstand testbar machen soll, aber auch nicht mehr. Anders formuliert sollte das MVP genau nur dazu geeignet sein, die relevante actionable metric testbar zu machen, um die es aktuell geht. MVP ist also keine Ausrede für halb fertige Produkte, die i.R. eines agilen Entwicklungsprozess entstehen. Wer den Begriff des MVP in solchem Kontext gebraucht, der hat das Prinzip schlicht nicht verstanden.

Wie kann eine actionable metric und das passende MVP aussehen? Das ist naturgemäß Kontext sensitiv und lässt sich somit nicht pauschal beantworten. Wollte man z.B. über Lean Startup ein neuartiges Feature testen, dann könnte die erste actionable metric ganz platt die Anzahl der Klicks auf eine entsprechende Fläche sein. Klicks als Indiz für das grundsätzliche Interesse der User. Das MVP wäre hier die klickbare Fläche, mehr nicht. Will sagen, ich brauche das Feature erst dann programmieren, wenn ich auch bewiesen habe, dass ich überhaupt hinreichend viele Leute motivieren kann sich in dem Kontext, in dem das Feature eingesetzt werden soll, damit zu befassen. Diesen ersten und experimentierfreudigen Usern kann ich dann natürlich noch kein laufendes Feature anbieten, aber ich könnte versuchen in die aktive Kommunikation und Befragung der User zu gehen. Da man solche Tests als Split-Tests aufsetzen kann, braucht man auch nicht befürchten, mit einem solchen Vorgehen Unmengen an Usern vor den Kopf zu stoßen und damit das Feature von vornherein kaputt zu machen. Die Betonung beim minimum viable product liegt also eindeutig auf dem minimum.

Lean Startup – Validated Learning

lean_startup_validated learningEin Lean Startup soll Wissen in einem hochgradig unbekanntem Umfeld sammeln und dies möglichst schnell und effizient. Aber wo hört Glauben auf und wo fängt Wissen an? In dem Beitrag „Wissen und Glauben“ bin ich bereits auf diese Problematik eingegangen und habe aufgezeigt, dass auch Split Tests (A/B- oder multivariate Tests), uns nicht zwingend und direkt Wissen oder gar die Wahrheit bringt. Hier muss aus meiner Sicht auch ein zentraler Kritikpunkt beim Lean Startup ansetzen, denn so wissenschaftlich die Methode auch wirken will, gerade in komplexen, unbekannten Umfeldern wird der Grad zwischen Wissen und Glauben immer ein schmaler bleiben.

Ich habe genau diesen Punkt in wirklich jedem einzelnen meiner Projekte (im negativem Sinne) intensiv erleben dürfen. Ich habe mehrfach erlebt, wie Testergebnisse schlicht ignoriert wurden. Wenn es an die eigene Wahrheit, die eigene Sicht auf die Welt geht, dann hört der Spaß bei vielen auf. Dies ist vermutlich auch der Grund, warum disruptive Innovation nicht selten durch Personen initiiert wird, die eigentlich Branchenfremd sind. Für diese ist es einfacher mit einem „neuen“ Weltbild zurecht zu kommen, weil sie kein altes kennen. Wenn man aber schon lange in einer Branche arbeitet und zumindest meint zu wissen, wie das Geschäft läuft, dann fällt es mitunter sehr schwer sich einer neuen Realität zu stellen.

Das Prinzip validated learning aus dem Lean Startup nach Eric Ries ist somit aus meiner Sicht vor allem ein sehr hoher Anspruch an den Umgang mit gesammelten Daten.