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

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.

Simply the Best? Agiles Management und Personalauswahl

„If you can only have 10 on the team, they’d better be the very best that you can find.“ Dies ist eine von 14 zenralen Aspekte für agiles Arbeiten, die Bob Warfield in seinem SmoothSpan Blog aufführt. Als ich mein erstes agiles Projekt erfolgreiche beendete, fragten mich viele Kollegen nach dem Erfolgsrezept bzw. den Erfolgskriterien, denn es war auch das erste agile Projekt für unseren Bereich. Scrum, damals die Basis für unser Projektvorgehen, war recht leicht zu erklären. Aber was braucht es, um dieses Vorgehen auch zum Erfolg werden zu lassen? Ich fragte mich das natürlich auch, denn es sollte nicht nur bei einem erfolgreichen agilen Projekt bleiben. Als das wesentlichste Erfolgskriterium kristallisierte sich für mich folgendes heraus: Arbeite mit Profis zusammen! Dies ist eine vielleicht abgeschwächte Form des oben genannten Zitats, meint im Kern aber etwas ähnliches.

Nun könnte man sagen: tolle Erkenntnisse, dass man mit guten Leute gute Ergebnisse erzielen kann! Aber so einfach ist das nicht. Agile Methoden bilden einen Rahmen, in dem Arbeit selbstorganisiert ablaufen soll. Das agile Manifest sagt, dass die Konzentration auf Individuen und Interaktion wichtiger sind als Werkzeuge und Methoden. Dies unterstreicht die Bedeutung der zusammenarbeitenden Menschen. Sich selbst organisieren zu können heißt aber auch, dass man sein Handwerk schon verstehen muss. Zudem arbeiten agile Teams in kleinen Gruppen, so dass kein Raum zum verstecken bleibt. All dies passt also zu der Bedeutung der Qualität agiler Arbeiter und zeigt, warum diese Qualität im agilen Kontext besonders wichtig ist.

Trotzdem würde ich heute das Erfolgskriterium anders formulieren: Bring den best möglichen Mix aus Menschen als ein Team zusammen. Ich will damit verdeutlichen, dass es nicht reicht, die zehn besten Individuen auszuwählen, für die dann, wie Bob Warfield schreibt, „pay what it takes“ gilt. Keine Frage, Qualität hat ihren Preis. Entscheidend ist aber das entstehende Team, das Gesamtgefüge. Neben der beruflichen Qualifikation muss dabei auch die Persönlichkeit betrachtet werden. Ein Team funktioniert dann, wenn sich sowohl die fachlichen als auch die persönlichen Merkmale der Teilnehmer gegenseitig so unterstützen, dass das Team mehr wird als die Summe seiner Einzelteile.

Bob Garfield gibt zusätzlich noch folgende Tipps, um das Team best möglich zu unterstützen, bzw. die besten Leute optimal ans Teams / Unternehmen zu binden:

  • Make engineering a first class part of the company.
  • Give them a high performance environment to work in.
  • Parallel Career Tracks for Pure Techies and Management.

All dies kann ich unterschreiben, wobei man den ersten und dritten Punkt verallgemeinern muss, denn man kann und sollte auch außerhalb des IT-Bereichs agil arbeiten. Eine der wichtigsten Aufgaben für agiles Management im Bereich Personalauswahl ist aus meiner Sicht aber die Zusammensetzung des Teams optimal zu unterstützen. Die Personalauswahl muss auf das entstehende Team abgestimmt werden und darf nicht nur isoliert betrachtete Superstars auswählen. Hilfreich ist es z.B. potenzielle Kandidaten auch mit dem Team reden zu lassen. Ich verlasse dafür mit dem HR-Manager den Raum und lasse den potenziellen Kollegen und Teile des Teams sich einfach mal beschnuppern. Dabei soll kein Team entstehen, wo sich alle auf anhieb perfekt verstehen. Ein gutes Team braucht auch Spannungspunkte. Diese zu erahnen ist Aufgabe von HR und Manager. Aber ein unverfängliches Kennenlernen gibt beiden Seite eine gute Chance, in die neue neue Konstellation hineinzufühlen.

Die zweite zentrale Aufgabe für agiles Management ist es dann, für dieses Team passende und gleichzeitig den Wert des Unternehmens steigernde Aufgaben auszuwählen. Das Team so gut verstehen lernen, dass man zu der Teamkompetenz passende Aufgaben auswählen kann, ist dafür die Voraussetzung. Natürlich muss dabei immer auch der Mehrwert für das Unternehmen betrachtet werden. Im Zweifel würde ich aber eine bestimmte Aufgabe runter priorisieren, wenn ich dadurch den Output des jeweils aktiven Teams optimieren kann. Dann können auch Personalwechsel nicht mehr nur als Gefahr gesehen werden, sondern auch als Chance mit einer neuen Teamkonstellation ganz neue Teamkompetenzen zu erreichen und andere Themenschwerpunkte setzen zu können, ohne dabei an Fahrt zu verlieren. Hat man mehrere Teams zur Verfügung, lohnt sich je nach aktuellen Themen also auch die Frage, ob die bestehenden Teams verändert bzw. durchmischt werden sollten. Starre Abteilungsgrenzen sind dabei wenig hilfreich. Agilität muss somit auch in der Organisation der Organisation ankommen.