Agile Day der BASTA! 2012

Wider den agilen Schwachsinn
Kommentare

Scrum, Kanban, Extreme Programming, Pair Programming, TDD, BDD, FDD, UDD – lang ist die Liste der agilen Methoden, die den Prozess der Software-Entwicklung verbessern sollen. Verfolgt man die agilen Diskurse ein wenig genauer, kann man aber schnell auf den Gedanken kommen, dass der erzeugte verbale Wirbel irgendwie in einem Missverhältnis steht zu dem, was Agilität in der Praxis wirklich positiv verändert.

Wird da nicht jede Woche eine neue Sau durch’s Dorf getrieben, die neue Heilsmethode für den garantierten Projekterfolg angepriesen, immer neue Lables auf uralte Binsenweisheiten geklebt? Hadi Hariri, Technologie-Evangelist bei JetBrains und BASTA!-Speaker auf dem Agile Day, hat jedenfalls die Schnauze voll von dieser „Agilen Hype-Industrie“. Was sollen bitte Ausgeburten des agilen Schwachsinns wie die „Pomodoro-Technik„, die in nichts anderem besteht, als sich eine Eieruhr auf 25 Minuten zu stellen und sich in dieser Zeit nicht unterbrechen zu lassen? Sogar zertifizieren lassen kann man sich als „Pomodoro Master.“ Und wäre dies nicht schon Dünnbier genug, kommen ganz progressive Geister auf den Gedanken, Pomodoro schon wieder als veraltet zu erklären und die Tomaten-Technik postmodern mit Scrum zu mixen. Das Ergebnis: Scrumodoro. Hariris Kommentar: Sind wir denn nun alle übergeschnappt?

Hadi Hariri in seiner Session:
Hadi Hariri in seiner Session: „Developers: Prima Donnas of the 21st Century“

Nun beziehen sich diese Heerscharen an agilen Methodiken auf die doch eigentlich recht konzise Liste der vier Grundwerte des agilen Manifests, die da bekanntlich lauten:

(1) Individuen und Interaktionen stehen über Prozessen und Tools; (2) laufende Software über vollständige Dokumentationen; (3) die Zusammenarbeit mit dem Kunden über Vertragsverhandlungen; (4) die Reaktion auf Veränderung über dem Einhalten eines Planes.

Und so stand der Agile Day der BASTA! wieder ganz im Zeichen dieser Grundwerte und stellte die bewusst provokante Frage: Was ist wirklich dran an Agile, in der Praxis? Was bleibt übrig, wenn die agilen Hype-Wellen abgeflaut sind? Auf welche Dinge kommt es wirklich an, will man sein Team von den Erkenntnissen der agilen Bewegung profitieren lassen?

Denn zweifellos gibt es sie, die agilen Errungenschaften, die zu echten Fortschritten in der Art und Weise geführt haben, wie man heute Software entwickelt. Zumindest ins allgemeine Entwickler-Bewusstsein gedrungen ist, dass man heute nicht mehr einen Kundenauftrag entgegennehmen sollte, um nach sechs Monaten klaustrophobischer Entwicklung das fertige Produkt „über den Zaun zu werfen“. Bekannt sein dürfte, dass es meist ziemlich in die Hose geht, zu Beginn eines Projektes eine komplexe Architektur bis ins Detail auszuspezifizieren, um diese danach plangemäß umzusetzen. Und jeder weiß mittlerweile, dass der Projekterfolg stark von einem dynamischen Team abhängt, in dem die Kommunikation stimmt.

Wirklich jeder? Fühlt man ein wenig in deutsche Entwicklerbefindlichkeiten vor, beispielsweise in den Diskussionen mit den BASTA!-Besuchern des Agile Days, kommen einem doch überwiegend Entschuldigungen zu Ohren, warum Agile nun genau in ihrem Unternehmen nicht wirklich funktioniert: Das Management unterstützt uns nicht, wir bekommen keine Zeit für Agile, unser Team wechselt ständig die Entwickler, irgenwie wollen nicht alle mitziehen, und so weiter und so fort. Und am häufigsten: Wir machen ja so ein bisschen Scrum, aber ganz auf Agile umstellen dürfen wir nicht.

Ein bisschen Scrum? Geht das? Eine kontroverse Diskussion, die spannend ist, hier aber nicht weiter getrieben werden kann. Der geneigte Leser wende sich an den Artikel „Ich will ja Scrum machen, aber mein Chef nicht!“ – Was tun?„.

Mit wahren psychologischen Profiler-Qualitäten wurden die Gründe für das Scheitern von Agile in Dino Espositos Session „Low Quality Code is Money-Loss Guarantee“ aufgedröselt. Oft beginnt das Ende vom Lied bereits ganz am Anfang, bei der Kommunikation zwischen Management und Entwickler-Team zum Start eines Projektes. Das Management ist darauf getrimmt, einem Projekt ein gewisses Budget zuzuodnen – sowohl zeitlich als auch pekuniär. Ein Entwickler kann hingegen zum Projektstart kaum abschätzen, wieviel Zeit ein gewisses Feature benötigt. Die High-Level-Feature-Wünsche eines Kunden muss der Entwickler in kleinteilige Implementierungs-Details aufbrechen – und dies ist erst nach einem nicht unerheblichen Forschungsaufwand möglich.

Dino Esposito auf der BASTA!:
Dino Esposito auf der BASTA!: „Low Quality Code is Money-Loss Guarantee“

Hinzu kommt, dass Software-Entwicklung im Allgemeinen als eine Art Ingenieurskunst angesehen wird. Espositos Position ist hier eindeutig: Entwickler und Ingenieure haben grundverschiedene Berufe! Hat es etwa ein Brückenbauer mit der Konstruktion eines wirklichen Artefaktes der Welt zu tun, besteht die Arbeit eines Software-Entwicklers in der Simulation eben dieser Wirklichkeit. Baut der Ingenieur seine Brücke nach bekannten statischen Grundregeln „nach Plan“, wird der Entwickler mit ständig wechselnden Anforderungen geplagt, agiert in einer Welt des inflationären Baustoff-, sprich: Technologiewandels, kann eigentlich nie sicher sein, was der Kunde wirklich von ihm will.

Und dazu kommt noch Espositos griffige Anti-Metapher:

Verzichtet der Brückenbauer auf Qualität, um Geld zu sparen, wandert er ins Gefängnis. Verzichtet der Entwickler auf Qualität, um Geld zu sparen, wird er befördert! Denn nichts gefällt dem Management besser als ein Projektleiter, der schneller mit seiner Software fertig ist als erwartet. Ob die Architektur in zwei Jahren noch skaliert, versteht der Manager nicht. Dass Refaktorisierungen die Wartbarkeit erhöhen würden, interessiert den Manager nicht.

Ist nun also alles verloren?

Nun, es gibt zum Glück ja auch gelingende Software-Projekte – sehen wir also nicht allzu schwarz. Worauf es ankommt, sind starke Projektleiter, die dem Management auch die internen Bedingungen der Entwicklung klar vermitteln können. Es gilt eben nicht, allen Wünschen sofort nachzukommen: „Wir brauchen bis Montag das Feature X für unseren Kunden!“ – „Alles klar, Chef!“. Auch die völlige Blockade führt selten zum Ziel „Nee, das können wir auf keinen Fall machen!“. Meist gibt es einen Kompromiss, der für beide Seiten tragbar ist: „Bis Montag können wir für den Kunden ein Feature-Mockup zusammenbauen, die genaue Implementierung dauert dann noch eine Woche länger!“

Und damit kommen wir zurück zur Kommunikation – einem der Grundwerte des agilen Manifests, dem Hadi Hariri nachtrauerte. Hadi ist der Meinung, dass es auf Entwicklerseite hier tatsächlich einiges zu verbessern gibt – das berühmte Milchbeispiel macht es deutlich:

  • Frau: „Geh in den Supermarkt und bring eine Flasche Milch mit – und wenn sie dort Eier haben, dann bring 6 mit.“
  • Entwickler kommt mit 6 Flaschen Milch und ohne Eier zurück.
  • Frau: „Warum hast du 6 Flaschen Milch gebracht?“
  • Entwickler: „Nun ja, wie du gesagt hast: Weil sie dort Eier hatten!“

Vielleicht stimmt es ja, dass Entwickler irgendwie anders denken. Dass Entwickler allerdings mundfaul sein sollen, verbannte Hadi in das Reich der Mythen. Man schaue sich nur einmal die Kommentarvielfalt auf Entwicklerportalen wie Hacker-News oder reddit an. Entwickler lieben es, sich über ihr Fach zu unterhalten! Was sie nicht mögen, so Hariri, ist Smalltalk (Entwickler, bitte jetzt nicht fragen, ob hier die Sprache Smalltalk gemeint ist…).

Liebe Entwickler: Kommt raus aus Eurer Komfort-Zone!, forderte Hariri. Dass andere Euch nicht verstehen, liegt nicht an denen (Manager, Kunden oder andere komischen Spezies), sondern an Euch! Macht einen Schritt auf die anderen zu, verbessert Eure Kommunikation mit Andersdenkenden, arbeitet an Eurem Konfliktlösungsverhalten! Denn das ist es, was das agile Manifest aussagt! Agile ist nicht der, der nach einem Wochenendseminar sein Scrum-Master-Zertifikat in den Händen hält! Agile wird nicht in den Dialekten „Pomodoro“ oder „Scrumodoro“ gesprochen. Agile ist keine Industrie, und wenn Agile mittlerweile dazu verkommen ist, dann ist sie nichts mehr wert:

We are losing focus!

Wie kann es sein, dass bei einer US-amerikanischen Agile-Konferenz kaum eine Session von Software-Entwicklung handelt? „Wir reden mittlerweile so viel über agile Prozesse, dass wir darüber den ersten Grundsatz des Manifests vergessen: Individuen und Interaktionen sind wichtiger als Prozesse.“

Hadi Hariris Aufrüttlersession war einer der Höhepunkte der gesamten Konferenz und lies die Anwesenden nachdenklich in die restlichen Sessions des Agile Day gehen: Thomas Schissler „Kanban, die Alternative zu Scrum?“, Urs Enzler „Agile Qualitätssicherung“ und Daniel Grund „Softwarearchitektur im agilen Kontext“ fügten den ein oder anderen Spritzer hinzu, wie agile Methodik in der Praxis tatsächlich die Entwicklerwelt bereichert.

Eine Aussage sollte den Besuchern des Agile Day bis heute noch nachhallen: Lasst Euch nicht durch die mitunter übertriebenen Regelwerke und Methoden abschrecken: Nicht überall wo „Agil“ draufsteht, ist auch Agil drin. Besinnt Euch auf die Grundwerte des agilen Manifests und setzt sie in Eurer täglichen Arbeit um.

Und so schließen wir an dieser Stelle mit einer versönlichen Aussage von Agile-Kritiker Hadi Hariri:

Entwickler, lasst Euch nicht für dumm verkaufen! Findet zurück zu Euren Werten und genießt das, was Ihr tut! Denn letztlich ist Software-Entwickler einer der besten Berufe, die ihr haben könnt!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -