Schlagwort-Archive: agiles Manifest

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

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

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

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.