Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly
Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Das erste Buch, dass sich objektiv und neutral mit Agilität auseinandersetzt, ist mir natürlich eine ebenso objektive und neutrale Rezension wert – und ich werde sie inkrementell verfassen.

Nachdem ich in einem Kommentar zu einem infoQ-Artikel geschrieben habe, dass ich eine Rezension verfassen würde, bin ich gerade dabei das Buch zu lesen.

Eigentlich habe ich Bertrand Meyer immer geschätzt, seine Bücher über Objektorientierte Softwareentwicklung haben mich im Studium begleitet. Er gehörte zu den Großen.

Jetzt habe ich das erste Kapitel gelesen und muss feststellen: Meyer demontiert sich in unerhörtem Ausmaß selbst. Nicht nur, dass schon in der Einleitung deutlich wird, dass er die Grundlagen agiler Methoden nicht verstanden hat, er definiert vielmehr in einer Auflistung diverser Praktiken aus dem agilen Umfeld alles als „gut“, das seiner Meinung nach nicht aus der agilen Community entstammt und alles als „schlecht“, das seiner Meinung eben aus dieser Community kommt.

Dabei interessiert ihn nicht, ob die betreffende Praktik sich irgendwo bewährt hat (User Story) oder tatsächlich von Agilisten zuerst beschrieben wurde (Continuous Integration). Ersteres ist schlecht, weil das eben so ist, letzteres ist nicht neu, weil es gut ist und es damit nicht agile sein kann.

Ich bin jetzt erst mit dem ersten Kapitel durch und über alle Maßen enttäuscht. Ich lese in diesem Buch vor allem Frust, aber wenig Sachlichkeit.

Kapitel 2: Dekonstruktion agiler Texte

Weil es so spannend war, habe ich gestern auch noch das zweite Kapitel gelesen. Hier beschäftigt sich Meyer mit der Dekonstruktion von Texten aus dem Umfeld der agilen Community.

Und er macht den gleichen Fehler, den viele Dekonstruktivisten machen: Er verzirkelt sich. Um zu zeigen, dass solche Texte nicht aussagefähig sind, zieht er ein Zitat aus „Succeeding with Agile“ von Mike Cohn heran, in dem eine Anekdote zur Diskussion gesprochenes vs. geschriebenes Wort berichtet wird.
Meyer meint nun, das Cohn mit dieser Anekdote “beweisen“ wolle, dass das gesprochene dem geschriebenen Wort überlegen ist und folgert daraus, dass in der agilen Community anekdotische Evidenz als Beweismittel betrachtet wird. Das lustige hieran ist, dass Meyer selbst eine Anekdote (ich habe bei Mike Cohn gelesen…) als Grundlage einer Generalisierung heranzieht (…deshalb ist das in allen Texten von Agilisten so). Gänzlich lächerlich wird Meyers zynische Dekonstruktion aber, wenn man weiß, das Cohn gerade mit diesem Zitat nichts beweisen wollte, sondern genau das Gegenteil: einen vermeintlich bereits erbrachten Beweis (Geschriebenes ist klar und eindeutig) widerlegen wollte. Und dazu reicht eine einzige Anekdote eben aus. Das sollte Meyer als Wissenschaftler wissen.

Als Meyer dann noch meint, dass „in den meisten seriösen Projekten“ irgendwann alle Leute mal danach schreien, man möge „es“ doch aufschreiben, damit „alle“ die Chance hätten, „es“ zu verstehen und nachzuvollziehen, konnte ich nur noch den Kopf schütteln. In den seriösen Projekten, in denen ich war, erlebte ich, nach dem Dinge aufgeschrieben waren, sehr oft die Situation, dass Leute nach der Lektüre über einen Text sprechen wollten, um ihn richtig zu verstehen.

Für Meyer ist es jedenfalls keine Frage: Weniger reden, mehr schreiben. Das ist eindeutiger und sicherer. Mit eigenen Erfahrungen kann ich das nicht bestätigen. Ich habe das differenzierter erlebt: Schreibe so viel, dass man mit einem kurzen Gespräch Verstehen bei allen Beteiligten erreichen kann.

Ach, und eines hat Meyer auch nicht verstanden: In agilen Projekten brauchen wir deshalb keine Feinspezifikation, weil wir automatisierte Tests haben. Die sind zwar zwangsläufig immer nur Beispiele für Anwendungsszenarien, helfen aber Entwicklern beim Verstehen viel mehr als abstrakte und generische Anforderungen, wie Meyer sie favorisiert.

Meine Meinung zu dem Buch ist auch nach dem zweiten Kapitel nicht besser geworden. Das sind jetzt immerhin 28% – ich bin total auf den Rest gespannt.

Kapitel 3: Big Upfront Anything

Meyers Buch zu lesen wird nicht leichter. Im dritten Kapitel lässt er sich über die These aus, dass Agilisten ein Feindbild im Big Upfront Anything haben.

Er greift erneut auf das Mittel der Dekonstruktion agiler Texte zurück, diesmal mit dem Beispiel des ‚Slander by Association‘. Einige Seiten lang hält sich Meyer daran auf, zu dass Agilisten ‚Wasserfall‘ mit ‚Vorhersagend‘ gleichsetzen – er hat das in einem(!) Buch von Sutherland gelesen.

Neben der Notwendigkeit von Requirements, Architektur und CMMI, die Meyer vor allem mit ihrer Notwendigkeit begründet (Zirkelschlüsse hat er Agilisten bis zum dritten Kapitel noch nicht vorgeworfen), gibt es inhaltlich kaum Neues. Bemerkenswert sind seine Sprünge in der Abstraktionsebene. Einmal zeigt er anhand eines Code-Beispiels, wie wichtig es ist, dass das verwendete Pattern erkennbar (Meyer sagt: dokumentiert) ist – etwas, dem kein agiler Entwickler jemals widersprechen würde. An einer anderen Stelle wird deutlich, dass er das Konzept des Backlogs in Kombination mit schnellem Feedback nicht verstanden hat: In Meyers Welt werden im klassischen Requirements Engineering unnötige Anforderungen vor der Analyse aussortiert, wohingegen seiner Meinung nach im Agilen auf eine Analyse verzichtet wird und unnötige Requirements nach der Implementierung(!) wieder ausgebaut werden. Aus welchem Projekt auch immer er diese Erfahrung zieht: Es war nicht agil, so arbeiten wir nicht. Ein anderer Punkt, den Meyer kritisiert, ist das vermeintliche Verzichten auf Architekturarbeit vor der Implementierung. Auch hier folgt er seinem Prinzip: er beschreibt ein Extrem wo in der Realität Pragmatismus herrscht. Er verwechselt den Verzicht auf Unnötiges mit einem generellen Verzicht und verstrickt sich in der weiteren Argumentation in der selbst geschaffenen Konfusion.

Auch im dritten Kapitel tappt Meyer wieder in die methodische Falle, die er sich im zweiten Kapitel gebaut hat: Er kritisiert ein in seiner Wahrnehmung nach typisches Verhalten von Agilisten und zeigt selbst das gleiche Verhalten: Er argumentiert immer wieder, dass in Büchern und Veröffentlichungen über Software-Engineering niemand behauptete, Big Upfront Anything wäre eine Lösung. Niemand aus der Agilen Community kritisiert Bücher über Software Engineering. Agilität kritisiert den realen Projektalltag. Und der ist ganz häufig Plan-Driven Waterfall mit viel Big Upfront Anything, obwohl das kein Buch so empfiehlt.

Kapitel 4: Agile Prinzipien

Die agilen Prinzipien dekonstruiert Meyer indem er zeigt, dass sie einer allgemeinen Definition von Prinzip nicht genügen. Woher er seine Definition eines Prinzips nimmt, ist nicht referenziert, aber sie ist in seinem Sinne zweckmäßig. Wikipedia beschreibt ein Prinzip als Ursprung bzw. als Gesetzmäßigkeit, die anderen Gesetzmäßigkeiten übergeordnet ist und weißt explizit darauf hin, dass eine Gesetzmäßigkeit im Sinne eines Prinzips auch eine Regel sein kann. Im Folgenden nimmt er die Prinzipien auseinander und zeigt, inwiefern sie seiner Definition eines Prinzips widersprechen. Auch hier lässt er sich wieder auf diesen unsauberen Stil ein, der den Leser schon durch die ersten drei Kapitel begleitete.

Da die agilen Prinzipien seiner Definition nicht genügen, formuliert er eigene, die in organisatorische und technische Prinzipien aufgeteilt sind. In einigen Aspekten treffen Meyers Prinzipien den Kern der agilen Werte sogar besser als die des agilen Manifests, aber im Wesentlichen sind sie als Strohmann-Argumente angelegt, so dass sie in seinem Sinne widerlegt werden können. Hier alle wiederzugeben würde den Rahmen sprengen.

An einer Stelle zitiert Meyer ein Paper aus dem Jahr 1993, in dem gezeigt wird, dass ein großer Teil der Fehler in einer Software auf das Verständnis der Anforderungen zurückzuführen sind. Die agile Lösung für dieses Dilemma stellt schnelles Feedback durch Anwender dar, Meyer favorisiert eine intensivere Analysephase vor dem Projekt. Sein primäres Argument gegen schnelles Feedback durch Customer Collaboration ist, dass die wesentlichen Stakeholder zu viel beschäftigt sind und deshalb weniger fähige als Vertreter entsendet würden.

Später begründet er, dass auch in agilen Organisationen Manager benötigt würden. Gute Gründe dafür hat Jurgen Appelo mit Management 3.0 geliefert und diese sind in der agilen Community auch anerkannt. Meyer referenziert Appelo nicht, sondern schreibt stattdessen „The need for managers remains, of course, because this is how companies work…“ Ich konnte leider nicht herausfinden, wie ein Manager in Meyers Sichtweise definiert ist, bin mir aber sicher, dass es Leute gibt, die diese Aussage widerlegen können.

Erwähnenswert finde ich noch, dass Meyer in Kent Becks Äußerung, ein Architekt würde auch programmieren eine Provokation sieht. Als jemand der einmal Architekt gewesen ist, glaube ich, kein Programmierer würde mich in dieser Rolle ernst nehmen, würde ich nicht hin und wieder selbst Code schreiben.

Gegen Ende des Kapitels lässt sich Meyer darüber aus, dass Scrum als agiles Projektmanagement Framework Änderungen nicht willkommen heißt, wie es das Agile Manifest fordert. Hier verwechselt er die definierte Arbeit im Sprint mit Änderungen im Backlog. Für die Gründe der Unveränderlichkeit von Anforderungen während eines Sprints interessiert er sich nur marginal – immerhin findet er diese Regel akzeptabel.

Während er im Kapitel verteilt relativ viel zu additiver und multiplikativer Komplexität schreibt, beachtet er leider nicht, dass Softwareentwicklung ein komplexes System ist und viele Dinge voneinander abhängen und miteinander wirken. Daher ist sein lineares Vorgehen zur Dekonstruktion der agilen Prinzipien nur von begrenztem Nutzen, wenn es darum geht, Agilität zu untersuchen.

Mittlerweile habe ich die Hälfte des Buches gelesen und kann nur den Kopf schütteln. Warum schreibt jemand wie Meyer, der eigentlich eine Instanz ist, so unreflektiert und unsauber über ein so wichtiges Thema?

Kapitel 5: Agile Rollen

Das Kapitel über die Rollen in agilen Organisationen ist recht kurz.

Meyer beschreibt, dass die agile Community Manager vor allem negativ betrachtet und über Verbote definiert. Steve Jobs benennt er als ein Beispiel für einen Manager, der sich nicht bewerben bräuchte – ich nenne ihn immer als ein Beispiel für einen Product Owner. Diesen beschreibt Meyer dann auch viel zu kurz – er reduziert ihn darauf, Storys zu Beginn eines Sprints auszuwählen und am Ende des Sprints abzunehmen. Diese Aufgaben gehören natürlich dazu, sind aber nur ein Bruchteil dessen, was ein Product Owner leisten muss. Insbesondere ignoriert Meyer komplett die ökonomische Verantwortung eines Product Owners.

Weiter schreibt Meyer über agile Teams, dass sie viele Management-Aufgaben wahrnehmen „…including the critical one of deciding, step after step, what tasks to implement“. Man könnte jetzt den Versuch unternehmen, Meyers Text dahingehend auseinander zu nehmen, dass ein Manager, der sich tatsächlich um einzelne Implementierungsaufgaben kümmern muss, zu wenig Energie in das Big Design Upfront investiert hat. Die Zeit spare ich mir aber. Wenn Meyer nicht zu den Managern gehört, die ihren Entwicklern vertrauen, sind agile Projekte mit ihm nicht möglich.

Spannend wird die Sache, wenn er zum Thema Kunden und Repräsentanten gelangt. Meyer meint, dass relevante Anwender so stark in Organisationen eingebunden sind, dass sie für die Teilnahme an einem Projekt nicht zur Verfügung stehen. Stattdessen würden an ihrer Statt zweitklassige Mitarbeiter entsandt, die man auf Anwenderseite los werden wollte. Abgesehen davon, dass das auch seine Idee der Vorab-Anforderungsaufnahme unmöglich machen würde, halte ich diese These für gewagt – denn sie sagt nichts anderes, als dass das betreffende Projekt für das Management nicht wichtig genug war, um den relevanten Leuten entsprechende Zeit einzuräumen.

Von Scrum Mastern hat Meyer keine gute Meinung. Zum Einen, weil es Zertifizierungsprogramme gibt und zum Anderen, weil Scrum Master nicht an der Entwicklung beteiligt sein sollen. Ersteres ist in meinen Augen für eine Bewertung der Rolle des Scrum Master irrelevant. Zweites kann man durchaus diskutieren – und kommt meistens zu einem Ergebnis, das Meyer vermutlich ablehnen würde, weil es ein typischer Ausspruch seiner so verhassten Consultants ist: Es kommt darauf an. Ich kenne Teams, bei denen es hilfreich ist, als Scrum Master mit zu entwickeln. Und ich kenne Teams, bei denen das extrem behindert hat. Ich selbst hatte als Scrum Master nie Zeit, mit Hand an den Code zu legen, weil ich damit beschäftigt war, mein Team großartig zu machen. Das können in Meyers Welt aber nur Manager, in denen er die besseren Scrum Master sieht. Auch hier denke ich: es kommt darauf an.

Gegen Ende des Kapitels schlägt Meyer endlich etwas versöhnlichere Töne an: „Every project must examine that tradeoff in light of its own circumstances; there is no universal, dogmatic answer.“ Dem kann ich nur zustimmen, genau das ist das, was ich immer aus der agilen Community höre.

Kapitel 6: Management-Praktiken

Auch dieses Kapitel ist kurz – so kurz wie es von der Praxis weit entfernt ist. Meyer bringt hier viel durcheinander. Er verwechselt die Aufgabenliste im Sprint mit dem Backlog: „It is the rule that during a sprint, the task list does not grow.“ – Die Task List darf wachsen, nur die User Storys dürfen sich nicht ändern. Oder er schreibt das Abbrechen des Sprints dem Product Owner zu: „terminating the sprint early — a decision that, as we have seen, is the privilege of the product owner.“ Nun, meines Wissens nach ist das nirgendwo definiert und wird in der Community aufs Heftigste diskutiert.

In Zusammenhang mit der Closed-Window Rule bringt Meyer auch die Änderung am Inhalt des Sprints mit Änderungen am Product Backlog durcheinander. Änderungen sind willkommen, am Product Backlog dürfen jederzeit Änderungen vorgenommen werden. Aber nicht am Inhalt des Sprints.

Bedauerlich finde ich Meyers ablehnende Haltung gegenüber dem Daily Standup. Er bringt die üblichen Argumente wie Zeitzonen bei verteilten Teams, Meeting-Inflation und unterschiedliche Anwesenheiten bei flexiblen Arbeitszeiten. Alles typische Fälle, in denen die Teams mit denen ich bisher gearbeitet habe, Lösungen gefunden haben.

Das Planning Game und Planning Poker beschreibt Meyer ebenfalls anders, als ich es kennengelernt habe und mit meinen Teams praktiziere. Ich kann aber durchaus verstehen, dass insbesondere das Planning Poker nach Meyers Vorlage nicht funktioniert. Hier stimme ich ihm absolut zu.

Es geht weiter im Kapitel mit Iteration Planning, Code Ownership, den Scrum-Meetings und anderen Dingen, die Meyer als Management-Praktiken einstuft. Einiges davon erklärt er falsch (Iteration Planning) oder erkennt nicht an, dass es neben seinem zentralistischen Weltbild durchaus erfolgreiche Projekte gibt, die multiplikative Komplexität mit einem Scrum-of-Scrums beherrschen.

Deprimierend finde ich seinen Standpunkt zur Code Ownership. Als jemand, der lange Zeit in Open Source Projekten mitgearbeitet hat und auch in dem ein oder anderen großen Industrie-Projekt dabei war, weiß ich wie kritisch ein hoher Truck-Faktor – der geht nämlich mit Fürstentümer im Code einher – ist.

Kapitel 7: Technische Praktiken

Das Kapitel funktioniert ähnlich wie Kapitel 6. Meyer stellt etliche Praktiken aus der agilen Community vor – das bedeutet: er beschreibt, wie er sie versteht – und nimmt sie dann auseinander. Das gelingt mal besser und mal schlechter, scheitert aber in der Regel an praktischer Erfahrung in realen agilen Projekten (das behaupte ich hier einfach mal, anders kann ich mir vieles in diesem Buch nicht erklären – wer es widerlegen mag: Kommentare sind offen). Wenn Meyer Refactoring kritisiert mit den Worten „refactored junk is still junk“ dann fehlt mir ehrlich gesagt eine Idee, was ich dazu schreiben könnte.

Im Wesentlichen geht es um Pair Programming, Coding Standard, Continuous Integration, Refactoring und Test Driven Development. Mir fehlen zu einer ernsthaften, kritischen Auseinandersetzung die Studien, die zeigen, dass TDD und Pair Programming die Produktivität erhöhen. Vielleicht hat Meyer die einfach nicht finden können.

Meyers Ton wird versöhnlicher. Zwar ist die Grundstimmung im Buch noch sehr aggressiv, aber es kommen öfter zähneknirschend Zwischentöne, die konstatieren, dass doch nicht alles so schlecht ist – auch wenn Meyer nicht müde wird, zu betonen, dass Design by Contract Unit Tests selbstverständlich überlegen ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.