Bloß weil wir AGIL sind, werfen wir jetzt jegliche erfolgreiche Methode über Bord?
Die Neue Religion ist der Alten Religion überlegen! Und wir sind die einzigen, welche Recht haben! So ist das Credo oft zu hören.
„In Scrum steht nichts von Architektur, deshalb machen wir das nicht“ und so einen Blödsinn muss man sich anhören.

Zur Einstimmung können Sie sich auch gerne einmal ein „Reality Adjustment“ von einem der Unterzeichner des agilen Manifests durchlesen. „Dave Thomas – Agile is Dead“[i] oder das Video [ii]anschauen.

Ich bin es richtig leid.

Leid zu sehen

• wie „Ingenieure“, anstatt nachzudenken, einer Methode folgen und diese nicht hinterfragen.
• wie Menschen ihre haarsträubende Qualität mit „AGILE“ rechtfertigen
  • während Sie gleichzeitig intern zuzugeben:
    Wir waren dem Kunden gegenüber nicht ehrlich
    == wir haben unseren Kunden belogen
    und
  • in der internen Kommunikation von grob Fahrlässigem Handeln sprechen
  • während in der Außenkommunikation von Test gesprochen wird.
• …… die Liste ist länger

Ich bin es leid.

Ich lese fast jeden Tag warum AGILE so großartig ist und alle anderen Methoden nicht.
Und natürlich lese und höre ich, dass SCRUM oder SAFe®, LESS etc. … anderen Modellen, meist Wasserfall (Einen Feind hat man immer, um sein Verhalten zu rechtfertigen) überlegen sind.

Und hier kommt dann immer wieder die Aussage, welche ich seit ca. 20 Jahren tätige:

„Ich bin Kindergärtner für Erwachsene.“

Mir dreht sich der Magen rum, wenn ich die Artikel lese, geprägt von absolutem nicht Verstehen was Wasserfall eigentlich ist, feststellen, dass sich Wasserfall und Agile widersprechen.

Aussagen wie

Die Wasserfall-Entwicklungsmethode ist aufgrund ihrer starren Struktur und ihrer strengen Kontrollen oft langsam und kostspielig. [iii]

sind an der Tagesordnung und zeigen nur eines. Man hat das Modell nicht verstanden.
Da ist es natürlich schön, wenn man gleichgesinnte Ignoranten um sich herum hat.

Falls es jemanden interessiert, steht im agilen Manifest: [iv]

„Develop better ways“

Da steht nichts von Daily, SCRUM, SCRUM of SCRUMS, User Story, EPIC etc.
Das Obige ist oftmals „added inappplicables“.
Hinzugefügte „Nichtanwendbare“, um Geld zu verdienen und aus agile, Agile zu machen [v]
Im agilen Manifest steht auch nicht, dass Wasserfall schlecht sei.

Es gibt hochgradig effektive Teams, egal mit welcher Methode die entwickeln.

Mir ist die Methode Schurz Pips egal. Was mir nicht egal ist, ist das Ergebnis.

Und die Behauptung – Agile ist die einzige Lösung – ist schlichtweg Blödsinn, bzw. kann ich aufgrund meiner Erfahrung und den Rückmeldungen meiner Kollegen (Quer über die gesamte Entwicklungslandschaft) nicht bestätigen.

Was ist denn nun besser?

Casper Jones hat in 2015 eine Studie veröffentlicht
„Evaluating Ten Software Development Methodologies“

Und liefert folgende Tabelle zu den Kosten unterschiedlicher Methoden

Was auffällig ist: Das es signifikante Unterschiede in den Kosten und Qualitätskosten gibt.

Schon in 2015 – und es hat sich seitdem nicht verbessert- stellte er fest

„Erfahrung macht es“

und

„Keine einzelne Methode scheint ein Allheilmittel zu sein, das bei jeder Größe und Art von Softwareanwendung erfolgreich ist.“

Und nun dehnen wir das „agile Vorgehen noch auf jede andere Aktivität und Entwicklung aus, reden von sich selbst organisierenden Teams, ohne zu berücksichtigen, dass Selbstorganisation in der Natur maximal zu losen Einzeller Verbünden führt. Der Einzeller-Verbund mag besser sein, als das was derzeit existiert, aber er ist nicht die Lösung für Alles.

Hierarchische Strukturen

Größere Systeme haben hierarchische Strukturen, wobei jeder Funktion eine Gruppe zugewiesen wird und innerhalb des Rahmens frei agieren kann.

Fragt sich, warum die Natur hierarchische Systeme baut. Oder sollte man doch noch mal anschauen, was Dave Thomas da sagt?

Das Wort „agil“ wurde bis zu einem Punkt untergraben, an dem es praktisch bedeutungslos ist, und das, was als agile Gemeinschaft gilt, scheint größtenteils eine Arena für Berater und Anbieter zu sein, die mit Dienstleistungen und Produkten hausieren gehen. (Ebd)

Hierarchie ist nichts Falsches, eine Ausgestaltung – egal mit welcher Entwicklungmethode gemäß „Ich bin im Recht und Du im Unrecht“ ist allerdings eher das Problem – so auch schön im Artikel Havard Buiness Review: „Why do so many managers have forgotten they are human beings“[vi] dargestellt

Herdentrieb und Anerkennung

Man folgt der Herde, weil man ja nicht „out“ sondern „in“ sein will.
Agile ist halt gerade in. Medien berichten darüber und wenn man nicht „mit der Herde geht“ ist man outdated und wird (zumindest medial) abgestraft.

„Jede Neuentwicklung wurde von einer Einzelperson gemacht, welche sich gegen den herrschenden Strom gewendet hat.“

Ist eine Aussage, die glaube ich von Paul Kurt Feyerabend „Wider den Methodenzwang“[vii]  stammt. Sehr lange ist es her.

Gegen den Strom zu schwimmen ist anstrengend, aber wenn es (technisch) notwendig ist, müssen Sie halt die Mühe auf sich nehmen. Und Veränderung passiert nicht, wenn man der Herde folgt!

Wenn die Herde einmal in Bewegung ist, kann Sie kaum einer aufhalten. Aber „Better Ways“ ist individuell und es stellt sich die Frage, ob Sie sich in der Herde wohlfühlen, oder individuell sein wollen.

Probleme in Projekten

Finden Sie in allen Bereichen, auch wenn man heute dazu „Herausforderungen“ sagen muss, weil es politisch nicht opportun ist von Problemen zu sprechen.

Probleme aus Projektsicht: Die Aufwandstreiber

Das obige Bild stammt aus dem Projektmagazin[viii] und zeigt den Auszug einer Studie (deren methodische Erfassung mir unbekannt ist) die Probleme

• Geforderte Terminplanung
• Produktqualität
• Dokumentation.

Ich denke, dass jeder Projektleiter dies nachvollziehen kann. Die Punkte passen unabhängig von der verwendeten Entwicklungsmethode.

1987 Barry Boehm und Victor Basili

Die Probleme aus technischer Sicht „Software Defect Reduction Top 10 List[ix]“ haben sich auch seit 1987 nicht wirklich geändert. Meiner Meinung nach gelten die Daten auch in anderen Entwicklungsdomänen.

• (Software)Fehler, die erst spät im Lebenszyklus einer Software gefunden werden, verursachen bis zu 100-mal mehr Kosten als solche, die frühzeitig entdeckt werden.
• 40 bis 50 Prozent des Gesamtaufwandes eines (Software)Projekts entstehen durch eigentlich vermeidbare Nacharbeit.
• 80 % der vermeidbaren Nacharbeit werden von nur 20 % der Fehler verursacht.
• 80 % der Fehler treten in nur 20 % der Module oder Komponenten auf.
• 90 % aller Ausfälle eines Systems werden von nur 10 % der Fehler verursacht.

Auch diese Aussagen haben sich in den letzten 35 Jahren nicht geändert.
Diese Probleme anzupacken und zu lösen, scheint wichtiger zu sein, als irgend eine neue Methode zu verteidigen.
Die Farge die sich stellt wäre:

Erreichen wir mit dem was wir tun, das gewünschte Ziel?

Daraus resultiert aus Finanzsicht

• 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich vermeidbare Nacharbeit. Eine deutliche Reduktion dieses Aufwandes kann vor allem durch Verbesserungen in den Bereichen
  • Entwicklungsprozess
  • Softwarearchitektur und
  • Risikomanagement erreicht werden
• Selbst mit dem zusätzlichem Aufwand zur Vermeidung lassen sich
  MINDESTENS 20% der Entwicklungskosten sparen
• Ø Gehalt Entwickler 75.000 à 220 Arbeitstage
  == ca. 44 AT mehr Leistung / Jahr

Wer bei den Zahlen, egal auf welcher Position nicht hellhörig wird, dem ist glaube ich nicht zu helfen. „Better Ways“ heißt, dass man genau da hinschauen muss.

Der Entwicklungsprozess als Hemmschuh oder Beschleuniger

Mit AGILE hat sich ein Verfahren etabliert, das in Bezug auf Qualität am Ende steht. Nichtsdestotrotz wird es vehement vorangetrieben.
Während intern AGILE als die Lösung gilt, sprechen die Zahlen eine andere Sprache.

The COQ (Cost of Quality) percentages reveal a chronic problem for software applications. 
We have so many bugs that finding and fixing bugs is the major cost of both development and total cost of ownership.

In einer Kugler Maag Studie „Agile in Automotive –State of Practice 2015“ – auch aus 2015 und seither inhaltlich ohne Änderung – steht z.B.:

“Low and high performers have a problem in such projects –
low performers with transparency,
high performers lose the hero status”

Das heißt übersetzt:
Die Guten werden gehen, weil Sie nicht angemessen behandelt werden – wer will schon in dem Wissen, dass er extrem gut ist – mit Anderen gleich gestellt werden.

Die Methode selbst scheint zwar beliebt, ist aber

1. Nicht das universelle Allheilmittel
2. Qualitätsmäßig nicht der Brüller
3. Finanziell auch nicht
4. Macht interne Probleme

„Devlop better ways“, heißt also immer Situationsangemessen zu reagieren.
Und auch wenn es heißt, dass müssen wir erst alles lernen (die Prozesse und Methoden), glauben Sie mir – gute Mitarbeiter machen das mit Freude, erfolgreich und schnell.

Kein Fullstack

Die Stellenanzeigen heißen immer wieder – „Fullstack[x] Entwickler“. Ich kenne nur Wenige. Und selbst diejenigen, welche es können haben Ihre Präferenzen.
Es ist nicht jedermann gleich und ein effektives Nutzen der Fähigkeiten und Wünsche ihrer Mannschaft bringt sie weiter.

Jemanden für alles einzusetzen ist nicht sinnvoll, weil (fast) Niemand überall gleich gut ist. Da Interesse und Erfolg/Spaßfaktor aber sehr wichtige Punkte für Effizienz (Qualität und Geschwindigkeit) sind, mag es günstiger sein sich eine bestimmte Expertise extern einzukaufen und Ihre Mitarbeiter nur ihre eigenen Interessen ausführen zu lassen, da gerade in den Gebieten des Eigeninteresses meist extreme Kompetenz und Geschwindigkeit existiert. Rechnen Sie mal Motivation und Interesse mit in Ihre Entwicklungskalkulation[xi].

Doch nicht so „AGILE“

Wenn Sie sich die obigen Daten sich zu Gemüte führen und da ein bisschen hineinstochern, werden Sie feststellen, dass die Prinzipien des agilen Manifests klasse sind, die Umsetzung eher marginal ist, und die Methode nicht so hip ist, wie Sie vorgibt.

Und wenn es schon in der Software nicht/nicht immer funktioniert, warum sollte man das dann überall auch so machen?

Better ways heißt dann auch, dass man schaut was verbessert werden kann und nicht „mit dem Tool haben wir die Probleme im Griff“
Eine Entwicklung und eine Organisation welche agil ist schaut nach Zielen, dem Produkt und nicht nach dem Tool.
Die alte Wesiheit:

A fool with a tool is still a fool

bleibt gültig

The Real why opens the door

Das obige ist nur rein Auszug am Füllhorn der Herausforderungen.
Ichhabe erlebt, dass es ein Jahr dauert, bevor die sachlich richtige Aussage des Beraters überhaupt ins Beusstsein kommt – und dann auch nur in Auszügen und erst nachdem es mehrfach „gekracht hat“.

Wenn Sie glauben dass eine Umstellung auf agile Entwicklung ihre Probleme löst, ohne dass Sie die Basics bearbeitet haben, dann sind Sie verloren.
Finden Sie die wirklich Ursache, stecken Sie Zeit in die RCA (Ursachenanalyse) und dann gilt:

Plan the flight, fly the plan.

Und jedes Mal, finden Sie die URSACHE für die Abweichung, sofern es eine Abweichung gibt.

Appeasement nutzt nichts, nur wenn Sie die Ursache habenkönnen Sie eine Korrektur vornehmen. Und achten Sie auf den Unterschied zwischen Rechtfertigung und Grund.

Management Summary

Wenn ich es bis hierhin nicht geschafft habe sie ein wenig wach zu rütteln, denke ich, dass Sie weiterhin im Tiefschlaf bleiben sollten, ich wäre der Falsche für Sie.

Wenn ich es geschafft habe sie aufzuregen – ich freue mich auf eine angeregte Diskussion und ggfs. eine fruchtvolle Zusammenarbeit

Seien Sie ErfolgReich!

Quellverweise

[i] Dave Thomas – Agile is Dead

[ii] Video Dave Thomas

[iii] hEvaluating Ten Software Development Methodologies“

[iv] agiles Manifest:

[vi] Havard Buiness Review: „Why do so many managers have forgotten they are human beings“

[vii] Paul Kurt Feyerabend „Wider den Methodenzwang“

[viii] Projektmagazin

[ix] Software Defect Reduction Top 10 List“

[x] „Fullstack

[xi] Entwicklungskalkulation – oftmals mit Faktor 10 Genauigkeit eher ungenügend.