Meine Erfahrungen mit "Agile"

vorhergehende Artikel in: Rants
15.05.2022

Ich habe inzwischen in mehreren Projekten gearbeitet, die von sich behauptet haben, die agile Methodik zu nutzen und war damit nie wirklich glücklich. Jetzt kann ich die Gründe dafür beginnen, in Worte zu fassen:

Lasst es nicht das Management entscheiden!

Aus meiner Erfahrung ist es hinderlich bei der erfolgreichen Umsetzung des Agile Paradigmas, wenn das Management entscheidet: "Ab morgen wird agil gearbeitet!" Wenn überhaupt ein positiver Effekt beobachtbar sein soll, dann nur dann, wenn das Management den Teams Freiraum bei der Gestaltung überlässt und das Team für sich entscheidet, dass Agile das Mittel der Wahl ist.

Ich konnte beobachten, was passiert wenn Management sich von oben für Agile entscheidet und das dann auch noch durch die Entscheidung für ein darauf aufgesetztes Skalierungsframework für Agile für einen ganzen Konzern verschlimmert. Das Resultat ist, dass in den Teams nur noch Schmerz ankommt und von den positiven "Benefits" von Agile auf Teamebene nichts mehr übrig bleibt.

Teamgröße ist alles!

Das leidige Schätzproblem

In einem meiner agilen Projekte entzündete sich regelmäßig in der Retro eine Diskussion zum Thema schätzen - Zunächst konnte man nicht entscheiden - schätzt man hier Komplexität oder Aufwand. Dem naiven Manager erscheint diese Diskussion zwecklos und leer, weil aus seiner Sicht beide Begriffe denselben Sachverhalt beschreiben. Das trifft jedoch nur zu, wenn alle Teammitglieder den exakt gleichen Wissensstand sind und untereinander völlig austauschbar: Eine Aufgabe, die eine gewisse Komplexität hat kann in der Realität für den einen Entwickler einen Tag Arbeit bedeuten, für den anderen eine Woche.

In einem der Projekte wurde dieses Problem dadurch umgangen, dass zu Start des Sprints bereits festgelegt wurde, wer welche Story bearbeitet und derjenige schrieb dann eine Schätzung dran. Man merkt hier bereits, dass das agile Vorgehen völlig mit Füßen getreten wurde. Zu Beginn - bei der Einführung von Agile in diesem Projekt - habe ich noch versucht, darauf hinzuarbeiten, dass das Wissen im Team breiter verteilt werden sollte. Das hat jedoch nie stattgefunden und so sind wir in der Sprintplanung letztlich zu dem beschriebenen Szenario übergegangen - für das wir aber auch kein teamübergreifendes Meeting benötigt hätten.

Was das Schätzproblem mit der Teamgröße zu tun hat

Ich habe inzwischen auch einanderes Projekt kennengelernt, in dem die Voraussetzung anders schienen - in dem oben beschriebenen habe ich gedacht, dass das Problem darin bestand, dass so viele unterschiedliche Komponenten und Technologien von dem Team bearbeitet wurden und sich mit jeder dieser Facetten nur wenige Teammitglieder wirklich auskannten.

Inzwischen kenne ich ein anderes Projekt, in dem alle im Team an derselben Anwendung arbeiten - und trotzdem kommen diese Diskussionen wieder hoch.

Erkenntnis

Das Team darf nicht zu groß sein - und offensichtlich ist eine Teamgröße von 10 oder mehr Köpfen wesentlich zu hoch!

Externe sind tödlich!

Aus meiner Erfahrung, die ich inzwischen gesammelt habe lässt sich schließen, dass Agile nur dann funktioniert, wenn alle teammember das gleiche Wissen haben. Das ist auch der Grund, warum das bei "Startupklitschen" so gut funktioniert: Dort finden sich Leute zusammen, die eine gemeinsame Vision haben und sich dagegen entschieden haben, damit einen Arzt aufzusuchen.

In einer gewachsenen Abteilung einer bestehenden Firma sind Leute zusammen, die unterschiedliche Bufserfahrung aufweisen und unterschiedliche Betriebszugehörigkeit. Das kann nie ein homogenes Team sein - und mit steigender Teamgröße ist es immer schwerer, eine solche Homogenität herzustellen.

Noch schlimmer ist es aber, wenn das Management versucht, externe Dienstleister in die Teams zu stecken: Ein Softwareentwicklungsteam als System gesehen, das als Ausgangsgröße die Effizienz hat und als Stellgröße die Teamgröße ist ein System nichtminimaler Phase: Wird in einem solchen System, in dem die Ausgangsgröße der Stellgröße folgen sollte die Stellgröße geändert, bewegt sich die Ausgangsgröße zunächst in die entgegengesetzte Richtung - in unserem konkretenFallsinkt die Effizienz also zunächst, wenn externe zum Team hinzustoßen. Das ist ein allgemeines Gesetz, das aber wissentlich immer ignoriert wird.

Artikel, die hierher verlinken

§219a und Roe vs. Wade

02.07.2022

Ich muss mir mal wieder was von der Seele schreiben - so einen Rant hats ja schon länger von mir nicht mehr gegeben.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Zugriff auf Maps ohne Cast in Java

    22.11.2017

    Collections im Zusammenspiel mit Generics erlauben es, ohne Cast auf Elemente gleichen Typs typsicher zuzugreifen - was aber wenn man typsicher auf Elemente unterschiedlicher Typen in einer Collection zugreifen möchte, ohne zu casten? Hier die Vorstellung einer möglichen Antwort

    Weiterlesen...

Neueste Artikel

  • Nerd-Dictation Tests

    Ich habe vor einiger Zeit schon einmal mit Spracherkennung experimentiert und war damals enttäuscht - vielleicht aber auch deshalb, weil ich nur mäßig motiviert war und mich deshalb bereits früh abschrecken ließ, als nicht alles sofort so funktioniert hat wie ich es wollte. Nun habe ich das Thema nochmals aufgegriffen...

    Weiterlesen...
  • Struktur von PKIs re: Archivzeitstempel

    Hier nochmal eine Beleuchtung der Organisation einer Public Key Infrastructure (PKI) von einem (von mir) bisher nicht betrachteten Blickwinkel

    Weiterlesen...
  • Security QA mit Kotlin-Bibliotheken und Java

    Über die Probleme und Herausforderungen beim Unit-Testen im Security-Umfeld mit Kotlin-Bibliotheken...

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier.