Navigation überspringen

"Agile" hat seine Bedeutung verloren

Dies ist der dritte Blogbeitrag in meiner Serie über den aktuellen Stand von Agile.

Allgemein
Agile

Im ersten Beitrag habe ich meine Ansicht über die sich ändernde Stimmung gegenüber Agile und einige meiner eigenen Geschichte und Erfahrungen damit dargelegt. Außerdem habe ich vier Faktoren genannt, die meiner Meinung nach zum derzeitigen Zustand beitragen.

Im zweiten Blogbeitrag haben wir uns den ersten dieser vier Faktoren angesehen: Die zunehmende Popularität von Agile.

Dies ist der dritte Blog-Beitrag der Serie, in dem wir uns mit dem zweiten Faktor befassen werden: "Agile" hat seine Bedeutung verloren.

Ein neuer Kunde

Ich hatte als interner Agile Coach für mehrere Unternehmen gearbeitet, bevor ich 2016 Berater bei Holisticon wurde. Einer meiner ersten Kunden wollte sich voll und ganz auf Agile einlassen. Sie versicherten mir mehrfach, dass sie wirklich engagiert seien. Ich war begeistert.

Wenn ich mit einem neuen Kunden zu arbeiten beginne, versuche ich, mich zunächst im System zurechtzufinden. Wenn ich z. B. mit einem Team arbeite, versuche ich, mir ein Bild der gesamten Wertschöpfungskette zu machen und wie das Team darin positioniert ist. Wie weit ist das Team vom Kunden entfernt? Wie weit reicht die Definition of Done?

Dieses spezielle Team war Teil der "Build"-Einheit. Es war zwischen "Plan" und "Test und Betrieb" angesiedelt. Es gab klare Übergaben zwischen diesen Einheiten. Das Team verfolgte im Wesentlichen einen Wasserfall-Ansatz, indem es die Arbeit aus einem bereits vor Jahren erstellten Anforderungsdokument ableitete und dann große Mengen an eine Testabteilung übergab.

Eine Struktur wie diese ist typisch für einen Plan-First-Ansatz in der Softwareentwicklung. Funktionale Silos werden eingerichtet, um die Effizienz und die optimale Ressourcenzuweisung zu optimieren.

Während diese Art von Struktur bei Problemen, die im Voraus analysiert werden können, funktionieren mag, führt sie zu Problemen, wenn man versucht, Agile in sie hineinzupressen. Aufgrund der Abschottung ist es so gut wie unmöglich, auf diese Weise schnelles Kundenfeedback zu erhalten und potenziell auslieferbare Inkremente zu liefern.

Aber der Kunde war entschlossen, vollständig agil zu arbeiten. Das hatte er mehrfach gesagt. Und so begann ich mit meiner Arbeit. Ich wandte mich an die Mitarbeiter entlang der gesamten Wertschöpfungskette. Die Leute aus der "Plan"-Einheit waren sehr daran interessiert, frühere Ergebnisse zu sehen, mehr Transparenz über den aktuellen Entwicklungsstatus zu erhalten und in der Lage zu sein, Dinge auf dem Weg anzupassen. Eine Person sagte mir: "Hören Sie, ganz unter uns, ich kann mich nicht mehr daran erinnern, was ich vor zwei Jahren in diese Anforderungsdokumente geschrieben habe oder warum die Dinge überhaupt dort drin sind. Damals schien es eine gute Idee zu sein, aber jetzt bin ich mir da gar nicht mehr so sicher." Wir stellten einen regelmäßigen Kontakt zwischen Geschäftsleuten und Entwicklern her. Die Dinge liefen großartig.

Die Leute aus der Abteilung "Testen und Ausführen" waren skeptischer. Sie waren nicht wirklich in der Lage, kleine Chargen zu verarbeiten und schnelles Feedback zu geben. Man sagte mir, man würde meine Bitte um eine direktere Zusammenarbeit intern besprechen und sich dann wieder bei mir melden. Und so wartete ich.

Faux pas

Ein paar Tage später riefen mich die Leute, die mich eingestellt hatten, in ihr Büro. Sie wollten wissen, was zum Teufel ich getan hatte. Hatte ich mit Leuten in anderen Abteilungen gesprochen, ohne sie vorher zu fragen?

Ohne es zu wissen, hatte ich einen schweren Verstoß begangen: Ich hatte direkt mit einem Mitglied einer anderen Einheit gesprochen. Das war gegen das Protokoll. Der richtige Weg wäre gewesen, zuerst mit ihnen zu sprechen, damit sie mit dem Vorgesetzten der anderen Person sprechen konnten. Erst dann hätte ich die Möglichkeit gehabt, mich mit dieser Person in Verbindung zu setzen und ein Treffen zu vereinbaren, das höchstwahrscheinlich von jemandem auf höherer Ebene überwacht worden wäre. Und was hatte ich überhaupt damit zu tun, mit "test and run" zu sprechen? Sie hatten mich eingestellt, um im Bereich "Build" zu arbeiten!

Ich war verblüfft. Mir fehlten die Worte. So sehr ich ihnen auch die Schuld geben wollte, so wurde mir doch klar, dass ich ihnen nie mitgeteilt hatte, was ich zu erreichen versuchte. Als eine Art Erklärung begann ich, ihre Wertschöpfungskette zu zeichnen. Ich erklärte, dass es bei Agile darum geht, die Feedbackschleifen zu verkürzen, näher an den Kunden heranzukommen, mehr Wert zu liefern und auf Veränderungen reagieren zu können. War es nicht das, was sie wollten? Sie wissen schon, Agile...?

Ihre Antwort? Nein, das ist absolut nicht das, was wir wollen. Wir wollen Agile! Sie wissen schon, Elemente aus einem Anforderungsdokument nehmen und sie in User Stories übersetzen. Geschwindigkeitsmessung. Aufzeigen, ob wir noch nach Plan arbeiten. Und wenn das nicht der Fall ist, korrigieren wir den Kurs, damit wir uns an den Plan halten! Agile!

Concept Creep

Jetzt, wo ich für dieses Thema sensibilisiert bin, sehe ich es überall um mich herum auftauchen. Nicht nur bei der Arbeit mit Kunden, sondern auch bei der Arbeit mit anderen Agile Coaches. Der Begriff Agile war mit so vielen unterschiedlichen Interpretationen und Wertvorstellungen behaftet, dass er zu unzähligen Missverständnissen führte. Und das trägt meiner Meinung nach enorm zu der aktuellen Welle der Enttäuschung bei. Wie können wir erfolgreich sein, wenn wir uns nicht darüber einig sind, was wir eigentlich erreichen wollen? Wie können wir zusammenarbeiten?

Die Tatsache, dass der Begriff Agile seine Bedeutung verloren hat, war ein weiterer Punkt, auf den Craig Larman hinwies, als ich 2017 sein LeSS-Training besuchte. Er begann das Training mit seiner Definition des Begriffs und den damit verbundenen Zielen, die sich aus dieser Definition ableiten. Sie erwies sich als so grundlegend, dass wir während dieser drei Tage immer wieder darauf zurückgriffen. Die meisten Argumente wurden durch die Frage geklärt, ob ein bestimmter Ansatz mit den aus dieser Definition abgeleiteten Zielen vereinbar ist oder nicht. Das machte die Diskussion so viel einfacher, weil das Argument nie zu einer Schlacht zwischen Agile und Nicht-Agile wurde.

Ähnlich wie bei der zunehmenden Popularität von Agile und seiner Bewegung durch den Hype-Zyklus ist die mangelnde Klarheit bezüglich seiner Definition nicht spezifisch für Agile. Kürzlich bin ich auf den Begriff "Concept Creep" gestoßen, der in der Psychologie verwendet wird und diese Dynamik sehr gut beschreibt: Ein Begriff hat anfangs eine sehr spezifische Bedeutung, aber wenn er in den Mainstream eindringt, wird er immer vager.

Was für Agile gilt, gilt auch für OKRs. Das ist keine Theorie. Ich erlebe es bei meinen Kunden immer wieder: 30 Ziele mit Hunderten von output-orientierten Schlüsselergebnissen. Früher nannten wir das eine Roadmap, jetzt sind es OKRs. Daran hat sich nichts geändert.

Oder nehmen Sie den Begriff "Minimum Viable Product" (MVP), der von Eric Ries in seinem Buch "The Lean Startup" populär gemacht wurde. Jeder, der dieses Buch gelesen hat, weiß, dass er über das MVP als etwas spricht, das es einem Unternehmen ermöglicht, die Build-Measure-Learn-Schleife so schnell wie möglich zu durchlaufen: "Die Lektion des MVP ist, dass jede zusätzliche Arbeit, die über das hinausgeht, was erforderlich war, um mit dem Lernen zu beginnen, Verschwendung ist, ganz gleich, wie wichtig sie zu diesem Zeitpunkt erschien." Heutzutage bedeutet der Begriff MVP für praktisch alle Unternehmen, die ich sehe, eine geringfügige Verringerung des Umfangs eines Produkts, das in seiner Gesamtheit in einer großen Charge ohne vorherige Interaktion an die Kunden ausgeliefert wird, genau wie früher. Das "Lernen" wird aufgeschoben, bis alles entwickelt, getestet und ausgeliefert ist.

Erwartungen offenlegen

Es gibt zwei Erwartungen an Agile, die ich am häufigsten sehe und die die meisten Enttäuschungen hervorrufen: mehr Effizienz und mehr menschliche Nähe. Lassen sie mich kurz zusammenfassen, was diese beiden Erwartungen sind und warum sie häufig zum Problem werden.

Die Hoffnung auf mehr Effizienz ist in Organisationen, die planorientiert sind, sehr beliebt. Sie suchen nach einer Möglichkeit, die gleichen Ressourcen zu nutzen, aber mehr Leistung zu erbringen. Dies soll ihnen helfen, ihre Pläne schneller zu erfüllen. In Wirklichkeit führt es aber zu Zombie-Agile. Christiaan, Barry und ich gehen in unserem Buch ausführlicher auf Zombie Scrum ein. Hier ist ein Auszug, der das Konzept des Effizienzdenkens erklärt.

Die zweite Erwartung ist die einer stärkeren menschlichen Bindung. Agile Methoden sollen dafür sorgen, dass sich die Menschen in einer Organisation besser fühlen. Jede Art von Asymmetrie wie Status, Macht und Fachwissen wird als etwas angesehen, das abgeschafft werden muss. Jeder redet den ganzen Tag lang, aber keiner macht wirklich etwas. Christiaan, Barry und ich haben angefangen, dies "Happy Clappy Scrum" zu nennen. Da die beiden keine Initiative zeigen, dieses Thema zum Gegenstand unseres zweiten Buches zu machen, übernehme ich es und nehme den anderen den Wind aus den Segeln. Mehr dazu demnächst.

Erfolg definieren

Anhand meines eigenen Beispiels, der anderen Beispiele aus der Branche und der beiden populären Erwartungen an Agile, die ich skizziert habe, ist hoffentlich deutlich geworden, dass wir immer klären müssen, was wir meinen, wenn wir von Agile sprechen.

Hier sind Fragen, die ich mit meinen Kunden verwende, wenn sie sagen, dass sie agiler werden wollen:

  • Welches Problem wird Agile für sie lösen?
  • Wie werden sie wissen, wann ihr Problem gelöst ist?
  • Wie sieht es aus, wenn ihre agile Transformation "abgeschlossen" ist?
  • Gibt es eine Möglichkeit, diesen Erfolg zu messen?
  • Wie nah sind sie an diesem Zustand?
  • Wie viel sind sie bereit zu investieren, um diesem Ziel näher zu kommen?
  • Was ist Agile nicht?

Wenn sie in einem agilen Umfeld tätig sind, lade ich sie ein, diese Fragen mit anderen zu erörtern. Ich glaube wirklich, dass wir von einer binären "Agile ist da oder nicht"-Definition des Erfolgs zu einer Definition übergehen müssen, die transparent macht, was wir tatsächlich zu erreichen versuchen.

Wir können nicht davon ausgehen, dass andere Menschen dasselbe meinen wie wir, wenn sie das Wort Agile verwenden. Die Klärung dessen, was wir meinen, hilft uns, einen Konsens darüber zu erzielen, worauf wir eigentlich hinarbeiten. Es hilft uns, zusammenzuarbeiten. Es vermindert die Tendenz, zwischen agilen und nicht-agilen Menschen zu unterscheiden. Wir wollen alle gemeinsam erfolgreich sein, wählen wir also die geeigneten Methoden aus!

Sobald wir eine gemeinsame Definition von Erfolg haben, können wir uns an die Arbeit machen. Oder wir können beschließen, dass Agile nicht das Richtige für uns ist. Das Unternehmen, das ich eingangs erwähnt habe, und ich haben uns getrennt. Wir hielten uns gegenseitig die "Es liegt nicht an dir, sondern an mir"-Rede und winkten zum Abschied. Seitdem hat sich dort nicht viel geändert.

Manchmal sind die Veränderungen, die nötig sind, damit Agile funktioniert, zu groß. Agile ist wirklich schwierig! Und das wird das Thema des nächsten Beitrags sein.

Autor

Johannes Schartau

Passionierter Agilist. Wegbereiter. Disziplinierter Optimist. Perspektivenerweiterer. Ruhepol. Komfortzonenbrecher. Empath. Potentialentdecker. Spaßversteher.

Über uns

Holisticon in 67 Worten

Holisticon steht für einen integrierten Beratungsansatz: Indem wir Technologie, Strategie und Organisation ganzheitlich denken und steuern, können wir die Digitalisierung innovativer Geschäftsmodelle zukunftssicher ermöglichen.

Das Unternehmen wurde 2007 von Oliver Ihns und Dierk Harbeck gegründet. Heute begleiten rund 80 Mitarbeitende an den Standorten Hamburg, Hannover, München und Lissabon Kunden aus verschiedensten Industrien erfolgreich durch die Transformation. Holisticon ist Partner führender Technologiemarken und Mitglied der internationalen Nexer Group.