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.

Finanzmarkt: mit Agilität gegen Komplexität

In der aktuellen Ausgabe von agora 42 (Ausagbe 03/2014) ist ein Artikel von Dirk Elster mit dem Titel „Frisbee mit den Märkten“. Es geht dort um die Komplexität der Finanzmärkte und wie mit dieser umzugehen ist, genauer gesagt um die ebenfalls komplexen Regelwerke, die für diese Märkte erdacht wurden. Zentral wird in dem Artikel auf eine Rede von Andrew Haldane eingegangen, in der am Beispiel „Frisbee fangen“ sehr anschaulich beschrieben wird, wie unterschiedlich man mit Komplexität umgehen kann. Auf den einen Seite kann zwar jeder Hund eine Frisbee fangen, auf der anderen Seite ist die notwendige Berechnung zum optimalen Fangvorgang äußerst komplex, weil eine Vielzahl miteinander verwobener Faktoren berücksichtigt werden müssen. Dies gilt Andrew Haldane als Beleg dafür, dass man, wie der Hund vermeintlich vorführt, Komplexität auch mit Einfachheit begegnen kann. Das entsprechend in dem Artikel extra herausgestellten Zitat dazu lautet: „As you do not fight fire with fire, you do not fight complexity with complexity“.

Ich kann mich dieser Schlussfolgerung nicht anschließen. Erstens ist für mich das Frisbee-Beispiel in erster Linie ein Beleg dafür, dass wir unsere Welt auf ganz unterschiedliche Weise verstehen können. Die wissenschaftlich fundierte Weltsicht und -erklärung ist dabei nur eine von vielen möglichen. Der Hund führt uns mit seinem Instinkt eine andere vor. Zweitens lehrt uns die Kybernetik: „Only Variety can destroy Variety“. Varietät stellt dabei die Anzahl der möglichen Zustände eines Systems dar und ist damit ein Maß für die Komplexität des Systems. Will man ein komplexes System mit der Varietät x regulieren, dann braucht man dafür eine System mit mindestens der gleichen Varietät.

Soll dies nun bedeuten, dass wir ein maximal komplexes Regelwerk für die Kapitalmärkte brauchen? Nein! Denn Varietät muss nicht bedeuten, dass die Regeln möglichst viele Zustände des Systems beschreiben bzw. regulieren können. Varietät kann auch bedeuten, dass interdisziplinäre Teams dafür Sorgen, die kommenden Herausforderungen aus möglichst vielen Perspektiven zu bewerten und möglichst viele Lösungsansätze zu entwickeln. Dann sind auch keine Regelwerke mit >1.000 Seiten notwendig. Interdisziplinäre Teams laufen zudem weniger Gefahr im absoluten Expertentum aufzugehen und sich von der Realität zu entkoppeln. Es ist wohl auch viel verlangt, wenn extrem gut verdienende Bankenexperten im Zweifel das eigene Portmonee regulieren sollen.

Natürlich ist dies kein Aufruf Laien die Finanzmärkte regeln zu lassen. Aber es ist ein Aufruf im Zweifel z.B. auch die Kunden zu Fragen, was Sie von den Finanzmärkten erwarten. Wenn wir die selbst geschaffene Komplexität der Finanzmärkte wieder in den Griff kriegen wollen, dann brauchen wir dafür interdisziplinäre Lösungsansätze, die das System der Finanzmärkte Stück für Stück vereinfachen. Eben so wenig wie man z.B. eine Feature geladene App braucht, die niemand bedienen kann, brauchen wir auch keine Finanzprodukte, die niemand versteht. Gesucht sind also die UXler, die Frontendentwickler, die Marketing-Fachleute, die Backendentwickler, die Admins und die Grafikdesigner der Finanzwelt, die als selbstorganisiertes, interdisziplinäres Team mit 360° Blick das Produkt Finanzmarkt so entwickeln, dass die metaphorische Frisbee wieder gefangen werden kann. Ein agiler Ansatz zur Regulierung der Finanzmärkte: Fighting Complexity with Agility!

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.

Das agile Manifest und die Aufklärung

1024px-FlammarionMeine wichtigste Lektion im Studium habe ich an einer Ampel gelernt. Genauer gesagt an einer ausgefallenen Ampelanlage an einer großen Kreuzung, die ich als Fußgänger überqueren wollte. Der Verkehr wurde von einem Straßenpolizisten geregelt, den ich erwartungsvoll in der Hoffnung auf ein Signal anstarrte, endlich die Straße überqueren zu dürfen. Es kam auch ein Signal, allerdings in etwas anderer Form als erwartet. Der Polizist schaute kurz zu mir rüber, sagte: „Selbständiges Denken ist hier erforderlich!“ und widmete sich wieder den Autos. Ich war also auf mich alleine gestellt. Ich durfte mich nicht weiter unmündig auf die Autorität von außen verlassen, ich musste meinen Verstand befreien und eigene Verantwortung übernehmen. Eine schwierige Aufgabe, aber ich es habe über die Kreuzung geschafft!

Ich gehe stark davon aus, dass besagter Verkehrspolizist überzeugter Anhänger der Aufklärung war. Wäre Emanuel Immanuel Kant Verkehrspolizist gewesen, dann hätte er im 18. Jahrhundert folgendes zu mir gesagt:

„Aufklärung ist der Ausgang des Menschen aus seiner selbst verschuldeten Unmündigkeit. Unmündigkeit ist das Unvermögen, sich seines Verstandes ohne Leitung eines anderen zu bedienen.“

Man kann dies auf so triviale Beispiele wie eine ausgefallene Ampelanlage beziehen, aber natürlich handelt es sich hierbei um eine grundsätzliche Einstellung zum Leben. Oben genanntes Beispiel schafft aber Bewusstsein dafür, dass wir nicht so aufgeklärt sind, wie wir es gerne wären. Was nehmen wir nicht alles hin, ohne uns eine eigene Meinung zu bilden. Wie bequem ist es doch, ein Leben in Unmündigkeit zu verbringen. Wenn wir z.B. eine BWL-Grundlagenvorlesung besuchen und man uns erzählt, dass es in der BWL um Zielerreichung nach dem Minimal- oder Maximal-Prinzip geht, wir dabei aber das Ziel an sich nicht bewerten, dann verführt das geradezu zum nicht selbständig denken. Es ist ja auch viel einfacher Ziele quasi als Befehl anzunehmen, ohne diese zu hinterfragen. Heerscharen junger Menschen werden so bereits vor Beginn der Karriere zur Unmündigkeit erzogen.

Selbständiges Denken ist hier erforderlich. Das sollten wir uns an den Bildschirm kleben. Und direkt daneben dann am besten noch das agile Manifest, das aus meiner Sicht aufklärerisch interpretiert werden will. Dieses Manifest kann man in verkürzter, verallgemeinerter Form mit folgenden Gleichungen beschreiben:

  • Individuen und Interaktion > Prozesse und Werkzeuge
  • Zusammenarbeit (mit dem Kunden) > Verträge
  • Reagieren auf Veränderung > Befolgen eines Plans

Natürlich brauchen wir Prozesse, natürlich sind Verträge als Basis oft notwendig und natürlich müssen wir davon ausgehen dürfen, das ein gemeinsam entworfener Plan nach Möglichkeit befolgt wird. Wäre all dies nie erfüllt, müssten wir unendliche Energien allein in die Verwaltung unseres Alltags stecken. Aber wir sollten die linke Seite der Gleichungen mehr schätzen. Im Zweifel ist die direkte Interaktion wichtiger als auf die aufgeschriebenen Regeln zu setzen. Und wir sollten nicht nur auf Prozesse und Werkzeuge setzen, die wir in BWL I gelernt haben. Wir sollten auf die Menschen achten mit und für die wir arbeiten. Damit das gelingt, müssen wir aber im ersten Schritt selbständig denken.

Natürlich ist dies eine aufklärerische Überinterpretation des agilen Manifest, das eindeutig auf die Organisation von Software-Projekten fokussiert. Ob gewollt oder nicht, das agile Manifest wurde so formuliert, dass man es in einem deutlich größeren Kontext interpretieren kann. Vom agilen Softwareprojektmanagement über agiles Arbeiten im Grundsatz bis hin zum aufgeklärten, agilen Unternehmen. Warum also nicht das agile Manifest in den BWL-Kanon aufnehmen? Wenn wir uns ernsthaft mit den Anforderungen der Zukunft und mit neuen Arbeitswelten beschäftigen wollen, dann kann dies auf jeden Fall nicht schaden. Es wird Zeit, dass wir zu aufgeklärten Arbeitern werden. Das agile Manifest ist dafür quasi eine Blaupause.

Bild: von Anonym, via Wikimedia Commons

Kriterien für agile Arbeiter: Sartre statt Zertifikate

Woran können wir erkennen, ob jemand in ein agiles Umfeld passt? Gerade dann, wenn wir auch außerhalb der IT-Abteilung agil arbeiten wollen, treffen wir sehr schnell auf einen Personenkreis, für den Scrum noch immer ein Fremdwort ist. Müssen wir uns bei der Personalauswahl also auf die wenigen beschränken, die agile Erfahrung haben oder zumindest wissen, was agil bedeutet? Und bedeutet ein Scrum-Zertifikat wirklich auch, dass jemand ein guter agiler Arbeiter ist? Meine These dazu lautet: Sartre statt Zertifikate.

Sartre ist einer der bekanntesten Vertreter des Existentialismus dessen Kernaspekte sich gut auf eine agile Kultur anwenden lassen. Der Existentialismus geht davon aus, dass der Mensch „sich sein Wesen selbst schafft“. „Der Existentialismus (…) hält daran fest, dass beim Menschen (…) die Existenz dem Wesen vorausgeht.“ Der Mensch ist also zunächst da, d.h. hat eine “effektive Anwesenheit in der Welt“ und schafft dann sein Wesen, d.h. „die Gesamtheit von Eigenschaften“ selbst. Der Mensch hat immer eine Wahl sich zu entscheiden. Am deutlichsten wird dies, wenn Sartre von der Hoffnungslosigkeit spricht. Hoffnungslosigkeit ist hier in dem Sinne zu verstehen, dass man nicht auf eine Änderung von außen, oben oder sonst wem zu hoffen braucht. „Es ist wahr, dass der Mensch unrecht hätte zu hoffen. Aber was heißt das anderes, als dass die Hoffnung das Schlimmste Hemmnis für das Handeln ist?“ Die einzige Hoffnung liegt im eigenen Handeln.

Aus dieser Freiheit ergibt sich aber gleichzeitig auch Verantwortung. Es gibt keine Ausreden, es gibt nur die eigenen Entscheidungen. „Wählen, dies oder das zu sein, heißt gleichzeitig, den Wert dessen, was wir wählen, zu bejahen (…).“ Diese Verantwortung gilt dabei nicht nur für einen selbst, sondern für alle: „.. selbst wenn wir es nicht wollen, schaffen wir durch jede unsere Taten eine allgemeine Werteskala.“ Und damit tragen wir eben auch mit jeder unserer Taten die Verantwortung für die gesamte Menschheit.

Diese Grundzüge des Existentialismus sind sehr passfähig zu den Anforderungen an agile Arbeiter. Agile Arbeiter müssen der Überzeugung sein, dass sie selbst aktiv einen Beitrag leisten können. Wir brauchen nicht die, die einfach nur Tickets abarbeiten wollen. Wir brauchen die  Hoffnungslosen, die den Anspruch haben, die Tickets aktiv mit zu gestalten. Wir brauchen die, die verstehen, dass sie einen Teil der Gesamtverantwortung für den Projekterfolg und das Team tragen. Gerade auch bei Scrum wird dies deutlich, denn die Erreichung des Sprint-Ziels hängt zwar auch vom Leistungsbeitrag jedes Einzelnen ab, ist aber gleichzeitig eine Teamleistung. Ebenso muss sich jedes Team-Mitglied bewusst sein, dass z.B. die rein körperliche Anwesenheit beim Daily Standup (‚meine Themen sind ja komplett isoliert‘) nicht nur inhaltlich fahrlässig ist, sondern diese Einstellung auch Auswirkung auf die Zusammenarbeit des Team an sich hat. Ein Scrum Team ist im Optimalfall wie das Team Justice League aufgestellt, eine Sammlung von Superhelden, die ihre Spezialkräfte im Sinne des Team einzusetzen wissen.

justice league

Aber wie finden jetzt heraus, ob wir einen solchen agilen Superhelden vor uns haben? Die Wahrscheinlichkeit, dass jemand eine dezidierte Meinung zum Existentialismus vorweisen und artikulieren kann, ist sicher eher noch geringer als die Wahrscheinlichkeit, dass jemand ein Scrum Zertifikat mitbringt. Aber zum Glück müssen wir auch nicht über Sartre diskutieren. Wir müssen über Verantwortungsbereitschaft reden. Wir müssen herausfinden, ob unser Gegenüber im positiven Sinne hoffnungslos ist. Die reine Methodik von Scrum lässt sich vergleichsweise leicht erlernen bzw. vermitteln, was ja gerade auch einer der Vorteile von Scrum ist. Die notwendige Einstellung zur Arbeit im Team, zur Verantwortung und dem eigenen Gestaltungswillen hingegen lässt sich nur äußerst schwer beeinflussen. Sollte ich jemals vor der Entscheidung stehen, bei sonst gleicher Datenlage, mich entweder für einen Existentialisten oder für einen Scrum-zertifizierten Kandidaten entscheiden zu müssen, würde ich mich für den Existentialisten entscheiden.

Bild von CarolMedina auf flickr, Verwendung unter cc Lizenz

Zitate aus „Der Existentialismus ist ein Humanismus“ von Jean-Paul Sartre

 

agile Praxis als Basis für scaling agile

Kürzlich habe ich folgendes Zitat von Richard Hundhausen gelesen: „An organization or team can not do Agile. They can only be agile. But, they can do many Agile practices and frameworks, such as Scrum. Agile is a state of being.“ Es ist extrem schwierig konkret zu beschreiben, was ein agiles Team oder eine agile Organisation ausmacht. Die reine Beschreibung der angewendeten Methoden und Routinen ist dafür nicht ausreichend. Aber wie können wir konkret erfassen, was es bedeutet agil zu sein? Wie können wir scaling agile so betreiben, dass eine wirklich agile Organisation entsteht und nicht nur eine Organisation, die agile Methoden anwendet? Meine These dazu lautet: wir brauchen eine agile Praxis.

Alasdair MacIntyre, ein zeitgenössischer Philosoph, hat den Begriff der Praxis in „Der Verlust der Tugend“ wie folgt definiert:

„Mit „Praxis“ meine ich jede kohärente und komplexe Form sozial begründeter, kooperativer menschlicher Tätigkeit, durch die dieser Form von Tätigkeit inhärente Güter im Verlauf des Versuchs verwirklicht werden, jene Maßstäbe der Vortrefflichkeit zu erreichen, die dieser Form von Tätigkeit angemessen und zum Teil durch sie definiert sind, mit dem Ergebnis, dass menschliche Kräfte zur Erlangung der Vortrefflichkeit und menschlichen Vorstellung der involvierten Vorstellung der involvierten Ziele und Güter systematisch erweitert werden.“

Zunächst einmal wird Praxis hier als kooperative menschliche Tätigkeit definiert. Hier drängt sich eine Parallele zum ersten Punkt des agilen Manifests auf, der Individuen und Interaktion mehr schätzt als Werkzeuge und Prozesse. Nicht Methoden, Werkzeuge oder Prozesse sollten im Zentrum unserer Bemühungen stehen, sondern Individuen und Interaktion. Damit wird dieser Aspekt des agilen Manifest als zentrale Säule einer agilen Praxis bestätigt. Ein zusätzlicher Beleg für die Kraft und den Wert des agilen Manifest, welches wir um so mehr als Grundlage unserer Praxis verstehen müssen.

Praxis zielt des weiteren auf die Verwirklichung inhärente Güter ab. Inhärente Güter sind solche, die nur durch die Ausübung der Tätigkeit selbst erreicht werden können. Man kann diese Güter nicht kaufen, man kann nicht damit handeln, man muss sie sich erarbeiten. Es geht hier um einen Aspekt, den wir im professionellen Kontext allzu gerne vergessen: etwas um seiner selbst willen zu tun, Spaß und Befriedigung an der Sache an sich zu haben. Und auch wenn wir inhärente weder kaufen noch verkaufen können, haben sie einen Wert. Dieser Wert kommt in erster Linie in der eigenen Organisation zu tragen, wo inhärente Güter als Motivationsfaktoren wirken. Dieser Wert kann aber durchaus auch Wirkung in Richtung unserer Kunden entfalten. Je nach dem, wie gut wie unsere Kunden in die agilen Prozesse einbinden.

Aber nicht jede menschliche Tätigkeit, die inhärente Güter mit sich bringt, ist gleich auch eine Praxis. Oder umgangssprachlicher formuliert, nur weil wir Spaß am agilen Arbeiten haben, haben wir auch gleich eine agile Praxis installiert. Eine Praxis definiert sich zusätzlich über Maßstäbe der Vortrefflichkeit. Eine Praxis verfügt über allgemein anerkannte Wertmaßstäbe. Es besteht innerhalb einer Praxis also ein common sense darüber, was eine gute Praxis ist. Dabei steht weiterhin die Tätigkeit im Mittelpunkt. Es geht nicht darum, diese Maßstäbe auf dem Reißbrett zu entwerfen. Es geht darum, sie durch die Tätigkeit zu erreichen und auch zu verändern. Scrum z.B. können wir als allgemein anerkannte Best Practice ansehen, als einen Maßstab der Vortrefflichkeit für agiles Arbeiten. Dabei müssen wir im Kontext einer Praxis aber verstehen, dass wir diesen Maßstab durch unser Tun verändern können. Scrum wird somit zu einem geeigneten Startpunkt, darf aber im Kontext der konkreten Umsetzung und der gemachten Erkenntnisse angepasst werden.

Wenn Alasdair MacIntyre formuliert, „Rüben-setzen ist keine Praxis, wohl aber die Landwirtschaft“, dann ist dies ein gutes Bild für den Unterschied zwischen dem Nutzen agiler Methoden und agil sein. Ich bin der Überzeugung, dass wir zwei Arten von agiler Praxis brauchen. Wir brauchen

  1. eine sehr konkrete, detaillierte Praxis der eigenen Organisation und
  2. eine allgemeine agile Praxis, die über die Grenzen konkreter Organisationen hinausgeht.

In der agilen Praxis der eigenen Organisation geht es darum, sich der inhärenten Güter der Zusammenarbeit bewusst zu sein und diese zu fördern. Wir brauchen ein gemeinsames Verständnis von guter agiler Arbeit und müssen auf dieses Ziel hinarbeiten. Ganz im wörtlichen Sinn von Agilität gibt es dabei keine starren Vorgaben per Management-Entscheidung. Es geht um die kontinuierliche Entwicklung der agilen Praxis auf Basis der gesammelten Erkenntnisse. In diesem Sinnen trägt jedes Mitglied der Organisation immer auch zur Entwicklung der gleichen bei. Wir anfangen können in Retrospektiven nicht mehr nur über Prozesse und Rollen zu diskutieren, sondern uns über die inhärenten Güter zu unterhalten, die wir produziert haben und welche wir noch produzieren wollen, dann ist dies ein guter Beleg dafür, dass wir nicht nur agile Methoden anwenden, sonder agil sind.

Die allgemeine agile Praxis ist unsere gemeinsame Aufgabe. Die Devise muss lauten: practice what you preach! Es darf nicht nur darum gehen, Zertifikate oder Frameworks zu verkaufen, wobei Schulung und Weitergabe von Wissen natürlich zentrale Aufgaben sind und somit auch ein wichtiger Teil der allgemeinen agilen Praxis sein müssen. Wir brauchen sogar allgemein anerkannte Methoden wie Scrum, um einen Einstieg in die agile Organisation zu ermöglichen. Der Fokus muss aber auf auf der Verbreitung und dem Leben agiler Werte liegen. Ganz im Geiste des agilen Manifest müssen wir dafür sorgen, dass Individuen und Interaktion stärker diskutiert werden als Methoden und Werkzeuge.

Der Product Owner als Prediger

Manchmal gibt es diese Momente, in denen man die Welt nicht mehr versteht. Die Fakten liegen auf dem Tisch, die Vor- und Nachteile auf der Hand und trotzdem wird eine Entscheidung getroffen, die all dies scheinbar unberücksichtigt lässt. Gerade für agile Teams, die ein hohes Maß an Gestaltungswillen und Eigeninitiative aufweisen sollten, sind solche Momente kritisch. All zu schnell kann hier eine Situation entstehen, bei der sich das Team vom Unternehmen bzw. den Entscheidungsträgern entfernt. Die eigentliche Kraft des Teams geht verloren. Was können wir dagegen tun? Meine These dazu: Das P in PO steht für Prediger.

Ein mögliche Erklärung für scheinbar nicht nachvollziehbare Entscheidungen gegen alle Fakten liefert die klassische Analyse des Wissens. Sie besagt, dass drei Bedingungen erfüllt sein müssen, damit ein Individuum (I) Wissen über P erlangen kann:

  1. P muss wahr sein
  2. I muss an P glauben
  3. I muss Gründe haben an P zu glauben

Stellen wir uns vor, wir sitzen bei „Wer wird Millionär“ und haben es mit der 500.000-€-Frage zu tun. Wenn wir die Antwort wissen, dann können wir sie beruhigt einchecken lassen. Aber wann können wir sicher sein, die Antwort zu wissen? Gemäß der oben aufgeführten Bedingungen, sollten wir an unsere Antwort glauben (2). Wir müssen also von unserer Antwort überzeugt sein, plattes raten wäre dafür also keine Option. Zusätzlich sollten wir noch unterstützende Gründe (3) haben, an unsere Antwort zu glauben. Gründe, die wir nach außen erklären können, z.B. also, dass wir etwas über das abgefragte Thema gelesen haben. Damit hätten wir die Bedingungen (2)+(3) erfüllt, fehlt also nur noch die erste Bedingung (1). Und diese zeigt an dem Beispiel auch gleich das ganze Dilemma vor dem wir stehen. Denn ob unsere Antwort wirklich stimmt bzw. wahr ist, dass weiß am Ende nur Günther Jauch. Vielleicht haben wir ja leider den Artikel, den wir gelesen haben, falsch verstanden. Wir glauben dann an unsere Antwort, haben auch Gründe daran zu glauben, nur bleibt unsere Antwort dabei leider falsch.

In der Realität sind wir ständig mit tlw. sehr komplexen Fragen konfrontiert. Leider gibt es dabei keinen Günther Jauch, der die richtigen Antworten kennt. Es gibt keinen Spielführer, der uns heimlich Tipps gibt, und keine eindeutige Definition für die richtige Antwort. Deshalb versuchen wir Data Driven zu arbeiten, um die Wahrheit quasi zu messen. Aber ab einem bestimmten Grad an Komplexität helfen uns allein Daten nicht weiter. Wir müssen diese analysieren und Ableitungen treffen und haben auch dann keine Gewissheit über die Richtigkeit der gewonnenen Erkenntnisse. Und dann kommt der Glauben (2) ins Spiel, weil er die Bedingung ist, die wohl fast immer erfüllt werden kann. Die Gründe für den eigenen Glauben (3) sind schnell gefunden, im Zweifel im reichen Erfahrungsschatz, den jeder mit sich rum schleppt. Und wenn hart gemessene Daten, z.B. die Ergebnisse eines A/B-Tests, mal nicht so recht zum eigenen Glauben passen, dann sind diese eben falsch. Wer kann schon garantieren, dass es keinen Fehler in der Testanlage gab? Deshalb gewinnen in der Realität häufig die persönlichen „Glaubenssätze“ über die vermeintlich objektiven Daten.

Dieser Blick auf Wissen und damit auch auf die persönliche Wahrheit und die Grundlage für Entscheidungen zeigt, wie subjektiv wir alle agieren (müssen). Die klassische Analyse des Wissens weckt Verständnis dafür, wie Entscheidungen zustande kommen. Vor allem auch deshalb, weil es hier nicht um ein isoliertes Problem von Entscheidungsträgern geht, sondern weil wir alle vor der gleichen Herausforderung stehen. Darüber hinaus bekommen wir mit der klassischen Analyse des Wissens aber auch ein Mittel an die Hand, Wahrheit und Entscheidungen im Unternehmen zu beeinflussen. Nicht die reine Weitergabe von Fakten und Daten sind relevant, sondern den Entscheidungsträger an etwas glauben zu lassen. Ein Product Owner hat somit auch die Rolle eines Predigers, wenn er das Team und Produkt gut im Unternehmen platzieren will.

Scrum Day 2014: Denkanstöße zur agilen Idee

Die Konferenz Scrum Day 2014 findet dieses Jahr am 01./02.07. in Böblingen statt und der Besuch lohnt sich. Denn am 02.07. werde ich dort zum Thema „Denkanstöße zur agilen Idee“ sprechen 😉 Aber natürlich lohnt sich der Besuch vor allem auch wegen all der anderen tollen Vorträge, der ausgezeichneten Keynote Speaker und der Workshops. Die Agenda könnt Ihr hier einsehen: http://www.scrum-day.de/agenda.html.

Hier exklusiv für Euch ein kleiner Ausblick auf meinen Vortrag, der drei Thesen beleuchten wird, die einen philosophischen Hintergrund dabei aber hohe praktische Relevanz für das agile Arbeiten haben:

  • Wir brauchen Leute, die willens und fähig sind in einem agilen Umfeld zu arbeiten. Wie können wir aber frühzeitig feststellen, ob jemand diese Bedingungen erfüllt? Meine These dazu: Sartre statt Zertifikate. Ich werde darstellen, dass die Auseinandersetzung mit dem Existentialismus dabei helfen kann die Einstellungen und Meinungen zu hinterfragen, die maßgeblich die Eignung zum agilen Arbeiter beeinflussen.
  • Ein gut funktionierendes agiles Team arbeitet selbstorganisiert, nicht aber isoliert, sondern sinnvoll eingebettet in die Organisation. Meine These dazu: Das P in PO steht für Prediger! Die klassische Analyse des Wissens kann nicht nur helfen die Entstehung fragwürdiger Entscheidungen der Organisation zu verstehen, sie zeigt auch, an welcher Stelle man ansetzen muss, um Entscheidungen im Sinne des Teams zu forcieren.
  • Ein agiles Team ist besser als keins, noch mehr Potenzial bietet aber eine agile Organisation. Meine These dazu: wir brauchen keine agilen Methoden, wir brauchen eine agile Praxis. Ich werde darstellen, was Praxis (angelehnt an Alasdair MacIntyre) an dieser Stelle meint und welche Anforderungen sich daraus an unsere Arbeit und unser Selbstverständnis als agile Arbeiter ergeben.

Wer also über den Tellerrand hinausblicken will, dabei aber trotzdem einen klaren Bezug zu Scrum und agilem Vorgehen sucht, der sollte auf jeden Fall zu meinem Vortrag kommen. Ich freue mich auf zwei spannende Tage, viele Kontakte und angeregte Diskussionen! Wir sehen uns auf dem Scrum Day 2014!