Archiv der Kategorie: agiles Management

Agiles Management ist als Begriff (noch) nicht eindeutig belegt. Für mich steht auf jeden Fall mehr dahinter, als die Führung agiler Teams. Agiles Management muss sich auch mit agiler Unternehmensführung befassen. Nur so kann die Kraft der agilen Idee den maximalen Mehrwert liefern.

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

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

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.