Einige Unternehmen, die ich unterstütze, beginnen unsere ersten Gespräche oft mit einer Aussage in folgender Form: »Wir haben Agilität eingeführt, aber irgendwie hat sich nicht viel geändert.« Die Antwort darauf ist meistens, dass dieses Unternehmen eine Agile Methode eingeführt hat, von Agilität aber noch weit entfernt ist.
Schon vor einiger Zeit hatte ich einen Blogartikel unter dem Titel Wer Scrum macht, macht noch lange nicht Agile geschrieben, und diese ersten Zeilen hier gehen in eine ganz ähnliche Richtung – wo ist also der Unterschied zu der Grütze, die ich vor Jahren verzapft habe?
Seinerzeit ging es eher um die Erkenntnis, dass es einen Unterschied zwischen Agilität und Agilen Methoden gibt. Die Fragen, wie ich es erkennen kann, dass ich eine Agile Methode und nicht das Prinzip Agilität lebe, und wie ich aus dieser Falle wieder herauskomme, sind seinerzeit zu kurz gekommen. Das möchte ich jetzt nachholen, weil ich feststelle, dass gerade das sehr vielen sehr schwer fällt.
Kurz rekapituliert: Scrum oder Kanban (was für mich eigentlich keine Methode ist, aber lassen wir hier mal Fünfe gerade sein) sind Methoden, die uns helfen sollen, das Prinzip Agilität zu leben. Agilität ist als empirisches iteratives Vorgehen definiert bzw. kontinuierliches schrittweises Lernen aus Erfahrung. Der Einsatz einer Methode garantiert nicht, dass ich das auch tue. Ich kann auch sagen, dass man sich ganz leicht an alle Scrum Regeln halten kann, ohne das Geringste über den Anwender oder das Produkt zu lernen. Scrum wird dann zu einem einfachen Werkzeug, mit dem ein großes Projekt in viele kleine Teile geschnitten wird.
Bevor wir uns die Lösung des Problems ansehen können, sollten wir kurz in die Ursachen gehen. Verstehen wir nicht, warum etwas geschieht, wird es sehr schwer, das zu bekämpfen.
Wird Agilität in einem Unternehmen eingeführt, gibt es meistens ein paar Workshops, in denen irgendein oberschlauer Klugscheißer (also jemand wie ich) den Kollegen erklären soll, wie Agilität geht. Dabei vergessen wir nur zu gerne, auch zu klären, was Agilität ist. Vielleicht versuchen wir das in der ersten halben Stunde, oder die Workshopteilnehmer dürfen eine Stunde mit Lego spielen. Wirklich verstanden hat es damit aber kaum jemand, und ich mache den Workshopteilnehmern dabei keinen Vorwurf.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Das Prinzip Agilität ist im Vergleich zu den handfesten Regeln, mit denen ich mich den Rest des Tages beschäftige, vollkommen abstrakt. Wir sind es gewohnt, in Absprachen, Vereinbarungen und Regeln zu denken. Das haben wir über viele Jahre gelernt. Jetzt sollen wir aber plötzlich in Prinzipien denken und dieses Prinzip dann in Regeln übertragen. Das fällt uns als Menschen schwer, während es uns sehr leicht fällt mit greifbaren Regeln zu arbeiten.
Die Freiheit von Scrum – eine seiner Stärken – wird da zu seiner Schwäche, indem es keinerlei Hilfe dabei gibt, wie dieses Lernen und das Ziehen von Schlüssen und Konsequenzen aus dem Gelernten ablaufen soll. Scrum gibt uns lediglich das Event Review. Die Erklärungen dazu genügen jedoch nicht.
Natürlich ist der Scrum Master gefordert, das Problem aufzulösen, aber wie zur Hölle sollen die das können, wenn die selbst im gleichen Workshop waren und auch nur Regeln gelernt haben? Erfahrene Kollegen können diese Situation auflösen, Neulinge sind damit vollkommen überfordert. Erfahrene Scrum Master gibt es jedoch nicht überall. In vielen Teams sitzen Neulinge, und manchmal läuft es dann darauf hinaus, dass diese Scrum Master jahrelang nur auf Regeln schauen.
Um das zu erkennen, muss ich natürlich zuerst einmal wissen, was das Prinzip Agilität wirklich bedeutet. Wenn Ihr das hier lest, habt Ihr vielen Eurer Kollegen schon eine Menge voraus, glaubt mir. Dann frage ich mich, was eigentlich passieren muss, wenn ich tatsächlich regelmäßig lerne.
Zum einen müsste es Bewegung in meinem Backlog geben. Ich lerne, dass sich Prioritäten verschieben. Ich lerne, dass andere Dinge gebraucht werden. Ich lerne, dass das, was wir zuletzt getan haben, noch in irgendeiner Form nachbearbeitet werden muss. Vielleicht weil die Usability noch nicht richtig funktioniert, oder es sinnvoll ist, noch weitere Daten auszugeben, oder was auch immer.
Wenn ein Backlog über einen längeren Zeitraum kaum verändert wird, ab und an unten ein paar neue Dinge angeklebt und nur Sprint für Sprint die obersten Einträge abgearbeitet werden, ist das ein ziemlich schlechtes Zeichen.
Zum anderen müsste es irgendeine Form eines Informationsaustauschs zwischen Entwickler und Anwender geben, wobei der Anwender auch nicht immer der Kunde sein muss. Im Zweifel geschieht dieser Informationsaustausch mittelbar – über den Kunden, aber die wirklichen Wünsche, Bedarfe, Meinungen, Feedbacks der Anwender müssen auf irgendeinem Weg zu den Entwicklern geraten. Wenn der Kunde uns sagt wir haben unsere Anwender gefragt, wir haben Interviews geführt, und dies sind die Ergebnisse, liebe Entwickler, dann ist das auch ok. Dann haben wir eben nur einen mittelbaren Kontakt. Den direkten Weg kann ich nicht immer gehen.
Geschieht das nur einmalig zu Beginn des Projekts und nicht regelmäßig, dann ist das auch ein ausgesprochen schlechtes Zeichen.
Wenn Ihr fragt, wie der Informationsfluss zwischen Anwender und Entwickler aussieht, wie regelmäßig das geschieht, und was dann mit diesen Erkenntnissen passiert, habt Ihr die Antwort darauf, ob Ihr das Prinzip Agilität lebt, oder ob Ihr nur einer Methode und einem Regelwerk folgt.
Eigentlich könnte mir das egal sein. Ich will schließlich nur ein tolles Produkt schaffen, mit dem ich bergeweise Geld verdienen kann. Gelingt mir das trotzdem, habe ich alles richtig gemacht.
Bedingt.
Zum einen könnte das Produkt noch viel toller sein, und ich könnte noch viel mehr Geld verdienen (machen wir uns nichts vor – wir sind keine Heilige), zum anderen ist eine Methode, wenn sie dem darunterliegenden Prinzip nicht dient, reine Verschwendung. Da sich nicht viel ändert, wenn ich das kontinuierliche Lernen ignoriere, kämpfe ich völlig sinnlos gegen Wiederstände. Wir haben Verluste durch die Einführung der Methode, weil wir schulen müssen, und weil wir gegen alte Gewohnheiten arbeiten.
Mein Punkt ist, dass Scrum – ohne wirklich Agilität zu leben – ein eher schlechtes Geschäft für das Unternehmen ist. Wir müssen Glück haben, dass sich der Aufwand, den wir mit der Transformation haben, durch zufällige positive Effekte rentiert.
Aber jetzt endlich: wie wirke ich dem entgegen?
Ohne dass mindestens einer das Prinzip des kontinuierlichen Lernens auf Erfahrung (also aus dem Gemachten und nicht aus dem theoretischen) wirklich wirklich wirklich verinnerlicht hat, geht nix. Absolut nix. Diese eine Person sollte (und meistens ist es das auch) der Scrum Master sein.
Befindet sich das Unternehmen in der Transformation und will das weitestgehend aus eigener Kraft schaffen (weil Berater auch nicht ganz billig sind), gibt es jedoch nur selten jemanden, der den frischgebackenen Scrum Master an die Hand nehmen kann. In dem Fall kann man nur immer und immer wieder die gleich Platte auflegen:
Was lernen wir daraus?
Wie setzen wir das Gelernte um?
Wie erfahren wir, was der Anwender braucht?
Malt es von mir aus in riesigen roten Lettern an die Bürowand – ist mir egal. Aber diese drei Fragen stellen wir immer wieder, in fast jedem Meeting. Und wenn mich jemand fragt, warum ich immer wieder genau diese Fragen stelle, dann lautet meine Antwort, dass genau diese Agilität bedeuteten.
Ich meine das vollkommen ernst. Das Prinzip Agilität muss in die Köpfe – über die Scrum Master in die Product Owner in die Entwickler und in alle anderen auch. Agilität findet nicht auf der Insel der Glückseligen in einzelnen Teams statt, es betrifft das gesamte Unternehmen, aber das ist ein anderes Thema.
Will ich das Prinzip Agilität in die Köpfe kriegen, sollte ich – wenn möglich – bei der ersten Begegnung der Kollegen mit dem Begriff Agilität beginnen. Je früher, umso besser. Je später ich versuche, den Begriff neu zu erklären, desto schwerer wird es werden, weil sich die Verbindung Agilität = Scrum schon in den Köpfen festgesetzt hat.
Wenn wir anfangen, das Prinzip zu verstehen und weiter zu verbreiten, beginnen wir damit, Regeln zu schaffen, mit denen wir für einen kontinuierlichen Informationsfluss vom Anwender zum Entwickler sorgen. Nehmen wir uns nur vor, dass wir regelmäßig Feedback einholen wollen, werden wir das bald vergessen haben. Wollen wir es regelmäßig tun, müssen wir es in eine Regel gießen, weil wir uns sonst einfach nicht an unsere eigene Absicht halten werden. Auch das ist menschlich, und auch hier mache ich niemandem einen Vorwurf.
Diese Regeln selbst werden extrem unterschiedlich sein. Sind es wenige Anwender, mit denen ich direkt kommunizieren kann, werde ich vielleicht einfach mit ein paar davon telefonieren oder sie zum Review einladen. Sind es Massen von Menschen, weil ich vielleicht Amazon heiße, werde ich wahrscheinlich eher die Supportanfragen auswerten, AB-Tests machen usw. Ich habe unendlich viele Möglichkeiten, einen Informationsfluss vom Anwender zum Entwickler zu etablieren.
Wenn der einmal hergestellt ist (meistens werden es auch mehrere sein), wird die Frage nach dem Umsetzen des Gelernten fast automatisch beantwortet. Niemand macht Kundeninterviews, ohne daraus Konsequenzen zu ziehen.
Ok, das war eine dumme Behauptung. Manchmal machen wir auch Kundeninterviews, um unsere Annahmen bestätigen zu lassen. Wenn das mein Ziel ist, werde ich auch einen Weg finden, dies zu erreichen.
Sobald neue Informationen vorliegen, stellen wir im Team die Frage, was wir mit diesen neuen Erkenntnissen tun sollen. Meistens finden die Kollegen die richtige Antwort, wenn wir gelernt haben, dass man Dinge aus dem Backlog wegwerfen darf, wenn sie nicht mehr gebraucht werden. Wenn wir Dinge Wegwerfen können, haben wir auch keine Scheu, anders zu priorisieren oder eine Anforderung zu verändern.
Kernaussage: Das Prinzip Agilität ist ungleich einer Agilen Methode. Der Einsatz einer Agilen Methode garantiert nicht, dass ein Team bzw. eine Organisation Agilität lebt. Ein tiefes Verständnis des Prinzips ist der erste Schritt zur Lösung des Problems.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
