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

  • Monte Carlo im Dungeon

    30.07.2017

    Der von mir neulich vorgestellte Dungeon-Generator war nur ein Schritt auf dem Weg: Ich wollte meine Studentenzeit aufleben lassen und einen Simulator bauen, in dem ich Monte-Carlo-Lokalisierung ausprobieren konnte...

    Weiterlesen...

Neueste Artikel

  • OpenSource - lieben, hassen - oder beides?

    Ich habe neulich zwei verschiedene Ideen verfolgt, die mich beide dazu brachten, OpenSource-Projekte mit meinem Input zu veredeln. Dabei sah ich, was schlecht an OpenSource-Projekten ist und warum deren Existenz trotzdem eine richtig gute Sache ist!

    Weiterlesen...
  • Links zu SNMP, Telegraf unf Grafana

    Nachdem die letzten Linksammlungen eher immer wilde Zusammenstellungen waren, die alle möglichen und unmöglichen Themen umfassten, hier nun eine thematisch eher enger begrenzte...

    Weiterlesen...
  • LinkCollections 2022 VIII

    Nach der letzten losen Zusammenstellung (für mich) interessanter Links aus den Tiefen des Internet für dieses Jahr folgt hier nunmehr die nächste:

    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.