Samstag, 27. Oktober 2012

Kurze Auslassung ueber "Agile Methoden"

Zurzeit leide ich unter die Ignoranz eines (oder mehrerer) einfaeltigen Manager(s), die irgendwie geglaubt haben muessetn, dass wenn etwas sich "agil" nennt, es auch irgendwie sein soll.
Nichts da. Pustekuchen.
Ja, "leiden"; ich habe naemlich eine nicht zu unterschaetzenden Schwierigkeit mit Zeitverlust und Unueberlegenheit.

Bei mir auf der Arbeit wurde so eine "agile" Methode vorgeschrieben. Und zwar die (von meiner Sicht der Sache heraus) schlimmste von allen: Scrum.
Scrum auf deutsch bedeutet "Gedraenge". Was daran gut sein soll, ist mir ein einziges Raetsel. Sowohl an einem echten "Gedraenge" als auch in der Art und Weise, wie diese "Methode" durchgefuehrt wird.

Zunaechst ist auffallend, dass gewoehnliche Dinger bei den Scrum-Propheten mit anderen Namen genannt werden. So gibte es "Sprint" fuer Etappen, Backlog fuer Beschreibungen und das mieseste von allem sind die User Stories. Die gesamte beschriebene "Methode" ist eine Zwangsjacke (de Benutzung des Wortes "Methode" ist weitgehend verfehlt): Man wird gezwungen, anstatt Funktionalitaet, Wuensche bzw Beduerfnisse aus der Sicht eines Benutzers ganz knapp zu (be)schreiben. Ein Beispiel? Bitte schoen: "Als Kranfahrer moechte ich eine Software, was mir die taeglichen Berichte schreibt". Warum abweichende Namen fuer die Sachen? Eine logische Erklaerung gibt's nicht, wahrscheinlich will man irgendwie versuchen, mit positiven Begriffen die Untauglichkeit der "Methode" zu vertuschen.

Ganz wichtig dabei ist, dass der "Kunde" ganz eng mit den Entwicklern zusammenarbeiten muss. In unserem Fall muesste der Kranfahrer jede 2 oder 3 Tage bei den Entwicklern den Fortschritt der Arbeit kontrollieren, sonst wurde am Ende eines "Sprints"... doch nichts Brauchbares rauskommen.
Es ist natuerlich klar, dass ohne genaue Produktbeschreibung die Anwesenheit von Kranfuehrern und Chirurgen und Diplomaten sogar vonnoeten ist, um die SW schreiben zu koennen.

Stoerend wirken sich auch die vorgeschriebenen taeglichen Scrum-Meetings. Diese reissen die Entwickler von der Arbeit weg, und dann wird -alle zusammen stehend- Produktdesign in Mikrosteps gemacht. Ein Scrum-Meeting sollte nicht mehr als 15 Minuten dauern, bei uns dauern sie mindestens 15 Minuten, 1 oder 2 Male in der Woche etwa 30 Minuten, naemlich dann, wenn einen groesseren Step oder Aenderung in dem Design vollzogen werden muss. Nach dem Meeting ist es stets muehsam, sich der abgebrochenen Aufgabe wieder zu widmen. Meine Meinung? Scrum ist fuer ganz besonders Faule, die nicht schreiben koennen und in den Tag hinein zu leben pflegen.
Eine nicht so bescheuerte aber dafuer fast noch zeitraubender Sache -weil uneffizient (sogar mit den taeglichen Scrum-Meetigs verglichen!)-, sind die monatlichen Sprint-Meetings, wo jeder Entwickler selbst, aber in Beisammensein von allen, den Scrummaster schreiben laesst, was er so zu tun beabsichtigt fuer den kommenden Sprint. Dauert etwa 2 Stunden einmal pro Monat bei uns.

Die Scrum "Methode" ist wohl mit einer grossen Anzahl an Meetings versehen, wohl die vielen Studien ignorierend, die schon vor etlichen Jahren herausgefunden haben, was fuer ein Zeitverlust die Meetings darstellen. Ich schaetze, dass mehr als "ignorierend" gilt "Ignoranz": Das Lesen ist keine Staerke der "Gedraenge"-Apostel.

Der Grundgedanke der agilen Methoden, die sich selbst verwaltenden, organisierenden Entwicklerteams ist an sich nicht falsch. Mit Intelligenz angewendet duerften sie sicherlich gute Ergebnisse liefern. Doch, wenn man die Methoden unreflektiert implementiert, dabei es sich auch um eine der "agilen" (ich lache und heule gleichzeitig) Methoden handelt, die am unflexibelsten ist, mit gezwungen vorgeschriebenen Massnahmen... so sollte man eigentlich nicht ueberrascht sein, wenn die Ergebnisse eher ernuechternd wirken.

Es wird zwar behauptet, dass mit Hilfe der Sprints die Produktivitaet steigt (trotz haufenweise unnoetigen Meetings) weil in kuerzeren Etappen "brauchbare Produkte" erzeugt werden (z.B. Prototypen, ungetestete Module, getestete nicht integrierten Module, usw usf). Tja... Wunschdenken ist maechtig. Und ich bestreite nicht einmal (warum sollte ich?), dass die Effektivitaet steigt... leider sinkt dafuer die Effizienz um so mehr.
Bei uns ist nun der Geschaeftsfuehrer Scrummaster geworden. Macht er ganz gut; er laesst sich nicht merken, ob ihm die "Methode" nervt. Vielleicht glaubt er daran, er muesste naemlich; das ist sein Job...

Sicher gibt es Faelle, wo eine Scrummethode gut angewendet werden kann. Doch es sollte genau abgewogen werden, welche Vor- und Nachteile damit verbunden sind. Das blinde Anwenden eine Methode ohne Pruefung, ohne Anpassung, wenn sogar, wie in unserem Falle, einige der "zu empfehlen bei" nicht gegeben sind... das ist alles andere als durchdacht.
Zu empfehlen hierzu sind die Artikel und Buecher bei oose.de
Lesen hilft...

Keine Kommentare:

Kommentar veröffentlichen