Agil? Das funktioniert doch gar nicht!

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

Eure ganzen Meetings sind Zeitverschwendung! Warum sollte ich zwei Entwickler bezahlen, wenn sie gemeinsam am Rechner sitzen und nur einer programmiert?! Test-Driven Development dauert viel zu lange! Wir können unseren Benutzern nicht zumuten, jede Woche zu releasen!

Gegen agile Softwareentwicklung gibt es viele Vorbehalte. Manche davon kritisieren ein bestimmtes Framework, wie zum Beispiel Scrum oder SAFe; Andere wiederum agile Vorgehensweisen und Praktiken oder sogar agile Prinzipien und Werte.

Im letzten Teil der Serie "Quick Glance At: Agile Engineering" habe ich erklärt, was "doing things right" und "doing the right thing" bedeutet und warum beides wichtig ist. Heute gehe ich auf einige der vorhin genannten Kritikpunkte ein.

Ich werde sie nicht in einem kurzen Video entkräften können, aber diese Kritikpunkte sind mir bewusst. Und eines möchte ich von vornherein klarstellen: Agile Softwareentwicklung und agiles Engineering lösen gewisse Probleme unter gewissen Voraussetzungen. Wenn dein Team diese Probleme nicht hat oder die Voraussetzungen (noch) nicht erfüllt, kann es sein, dass es für euch bessere Vorgehensweisen gibt. Zumindest vorerst.

Bevor ich auf die wichtigsten Kritikpunkte eingehe, die ich bisher gehört habe, pausiere bitte kurz. Beantworte in deinen Notizen die Fragen:
Was stört dich besonders an agiler Softwareentwicklung, so wie du sie bis jetzt erlebt hast?
Was würdest du anders machen, und wie?

Am besten lädst du dir die aktuelle Notizbuchseite als PDF herunter und druckst sie doppelseitig aus.

Kritikpunkte

Was sind denn nun einige dieser Kritikpunkte?

Einfach gleich richtig Machen: "Wenn wir etwas sorgfältiger arbeiten und keine Fehler machen, dann brauchen wir auch keine kleineren Arbeitspakete, keine iterative und inkrementelle Vorgehensweise, kein Test-Driven Development, usw..."
Aber: Das ganze setzt natürlich voraus, dass es überhaupt möglich ist, keine Fehler zu machen; Also, dass wir die Bedürfnisse unserer Benutzer immer sofort verstehen und richtig umsetzen, dass sich der Markt nicht verändert, und so weiter.

Es gibt kein sinnvolles Zwischenergebnis: "Wir müssen diese Anforderung nicht weiter in kleine Stories zerteilen, weil unsere Benutzer sowieso kein Zwischenergebnis akzeptieren würden."
Aber: Das lässt nur leider außer Acht, dass wir auch während der Entwicklung Feedback benötigen. Außerdem sollte man hinterfragen, ob die Benutzer wirklich niemals kleinere Lieferungen akzeptieren würden.

Micro Management: "Diese ganzen Meetings und Feedbackschleifen führen nur dazu, dass uns unsere Führungskräfte noch genauer kontrollieren und noch detaillierter steuern können. 'Scrum is a micro-manager's dream'."
Leider stimmt das zu einem gewissen Grad und darüber habe ich auch in meinem Buch über Agile Antipatterns, und zwar im Kapitel "Burnout by 1000 Baby Steps", geschrieben. Die Engineering-Organisation muss sich emanzipieren, aber dafür gibt es keine einfachen, schnellen Lösungen.

Das dauert alles zu lang: "Ensemble-Programming, TDD, die ganzen Meetings, das ist doch alles Zeitverschwendung. Lasst das weg und ihr seid schneller."
An diesem Kritikpunkt gefallen mir zwei Dinge nicht: Erstens überlegt man hier nicht, unter welchen Voraussetzungen die agilen Vorgehensweisen effektiver sein könnten. Man kanzelt sie pauschal als "langsamer" ab. Und zweitens vergleicht man hier fast immer einen bekannten Zustand—jeder unserer 5 Entwickler arbeitet an einer User Story und braucht dafür eine Woche—mit einem unbekannten, (negativ) idealisierten Zustand: Wenn sie an einem Rechner gemeinsam sitzen, dauert das also 5 Wochen.

Budget und Umfang sind fix; Wir haben doch eine Deadline: "Wir müssen sowieso alle diese 30 Features zur Deadline in 6 Monaten liefern und zwar genau mit diesen zwei Teams. Warum sollten wir dieses ganze agile Prozedere überhaupt machen?"
Ja, wenn die Voraussetzungen nicht gegeben sind, kann agile Softwareentwicklung nicht alle ihre Vorteile ausspielen. Aber schnelle Lieferung und schnelles Feedback bleiben trotzdem noch wertvoll. Und in so einer Situation wäre es auch dringend notwendig, die Voraussetzungen noch einmal zu überdenken und neu zu verhandeln.

Bei uns funktioniert das nicht weil...: "Wir sind anders, und wir haben folgende gute Gründe warum agile Softwareentwicklung bei uns nicht funktionieren kann: ..."
Und dann kommen meistens sehr ähnliche Gründe. Ja, jede Firma, jedes Team ist unterschiedlich—aber auch nicht so unterschiedlich. Man könnte überlegen, ob man in einem lokalen Optimum festsitzt und die Gründe verschwinden würden, wenn man es über den nächsten Hügel schaffen könnte.

Aber wir sind soch bereits agil!: "Wir machen doch schon SAFe (oder Scrum). Wir machen alle Meetings, liefern die Artefakte, haben Release Trains, haben alle zwei Wochen Sprint Reviews."
Wenn ihr das wirklich alles macht und es für euch funktioniert, dann passt doch alles. Aber, wenn

• ihr im Sprint Review unfertige Software zeigt,
• ihr nicht jeden Sprint oder öfter etwas in Produktion deployed,
• umfangreiche manuelle Tests nötig sind, bevor man in Produktion darf,
• euer Backlog lang ist und Einträge normalerweise nicht einfach wegfallen, weil sie unnötig geworden sind,
• eure Prioritäten fix sind,
• ihr viel Zeit mit schätzen und planen verbringt,
• ihr häufig Fehler in Produktion findet,
• ihr viele Fehler im Backlog habt oder sogar ein eigenes Engineering Backlog oder Technical Dept Backlog habt,

dann seid ihr vielleicht doch noch nicht so agil, wie ihr glaubt.

Beantworte bitte folgende Fragen in deinen Notizen:
Welche dieser Kritikpunkte hast du bereits gehört oder sogar selbst kritisiert?
Was hältst du von meinen Antworten auf diese Kritikpunkte?
Was hättest du geantwortet?

Rahmenbedingungen und Optima

Deine Firma und dein Team müssen die Rahmenbedingungen schaffen, damit Softwareentwicklung für euch funktioniert. Und diese Rahmenbedingungen sind wahrscheinlich nicht genau gleich wie bei anderen, vergleichbaren Teams oder Firmen.

Wenn ihr alles genau gleich macht wie Spotify oder Valve oder Apple bedeutet das trotzdem nicht, dass bei euch alles funktioniert. Denn: Ihr seid anders. Und nicht alles, was ich hier erzähle, wird bei euch auf Anhieb funktionieren.

Aber: Alles, worüber ich in dieser Serie spreche—Test-Driven Development, Continuous Refactoring, Evolutionary Design, Ensemble-Programming, etc.—kann funktionieren, wenn die Rahmenbedingungen stimmen. Es kann sogar besser funktionieren als die Alternativen.

Die große Schwierigkeit besteht darin, herauszufinden, ob etwas bei euch nicht funktioniert,

• weil eure Situation wirklich so speziell ist und diese Vorgehensweise nicht funktionieren kann
• oder weil ihr mit eurem aktuellen Vorgehen gerade in einem lokalen Optimum feststeckt und diese Vorgehensweise besser funktionieren könnte, wenn ihr bestimmte Rahmenbedingungen ändert.

Ich werde in den weiteren Teilen immer wieder versuchen, Informationen und Argumente zu liefern, um zwischen den beiden Situationen zu unterscheiden. Ich werde in den einzelnen Kapiteln und Teilen über Vor- und Nachteile von Praktiken und Vorgehensweisen und deren erwarteten Nutzen sprechen.

Aber herausfinden, was für dein Team am besten funktioniert, kannst du nur durch Experimente und Feedback.

Mach eine kurze Pause, in der du notierst:
Welche Praktiken des Agile Engineering kennst du?
Welche davon setzt ihr bereits ein?
Welche anderen würden auf Anhieb bei euch funktionieren?

Fazit

Es gibt viel Kritik und Ressentiments gegen agile Softwareentwicklung und agiles Engineering. Es wird pauschal behauptet, eine gewisse Vorgehensweise würde nicht funktionieren—Stichwort: "TDD is dead". Oft entspringt diese Kritik aber einer falschen Anwendung der Praktiken und Vorgehensweisen.

Alle Praktiken und Vorgehensweisen, über die ich in dieser Serie spreche, können besser funktionieren als die Alternativen—unter gewissen Voraussetzungen.

Aber alle Teams und Firmen sind verschieden, wobei die Unterschiede auch nicht so groß sind. Und viele Organisationen könnten von agilem Engineering mehr profitieren, als sie es jetzt tun. Wenn sie es besser einsetzen würden.

In diesem Teil der Serie ging es um Kritikpunkte an agiler Softwareentwicklung. Ich konnte sie sicher noch nicht entkräften, aber ich habe meine Sichtweise und Kritik an den Kritikpunkten dargelegt. Im nächsten Teil befassen wir uns damit, wie wir abwägen zwischen schnellem Handeln und den richtigen Zeitpunkt abzuwarten.

Weitere Informationen

• Aktuelle Notizbuchseite als PDF