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

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )