metaMinds
Der Blog für digitale Besserwisser
scrum

Agile Development – die Antwort auf alle Fragen?

Martin Lederer - metaMind
Solutions Architect
Mehr erfahren
Expertenbeitrag

Agiles Vorgehen ist seit vielem Jahren der Prozess der Wahl bei der Organisation von Softwareprojekten. Für die sich stets im Fluss befindliche Softwarewelt ist das eine Ewigkeit.

Agilität und die ersten Scrum-Schritte stammen aus einer Zeit, in der EJB-Theoretiker noch von komponenten-orientierter Programmierung geträumt haben. Die Enterprise JavaBeans von 1999 heißen heute übrigens Jakarta Enterprise Beans.

Doch nicht nur die anhaltende „Magie“ von Agilität ist bemerkenswert, auch die ungewohnte Einigkeit in der ansonsten diskussionsfreudigen Community. Mit einem Scrum-Ansatz, worunter Agilität in der Softwareentwicklung hier überwiegend firmiert, könne man nichts falsch machen – Scrum scheint das richtige Werkzeug für alle Anwendungsfälle zu sein. Doch selbst wenn man zum gleichen etablierten Ergebnis kommen könnte, so lohnt es, die Agilität im Allgemeinen und ihre Scrum-Derivate hier im Besonderen ein bisschen abzuklopfen: Im schlimmsten Fall kann man ein tieferes Verständnis von Agilität gewinnen. Dabei geht es mir nicht um ideale Teams und ideale Modelle, und auch reine Theorien will ich nicht gegeneinander antreten lassen. Die interessanten Aspekte zeigen sich in der Softwareentwicklung „im Feld“.

Kommuniziert? Funktioniert!

Ohne in die allgegenwärtige Transparenz und Kommunikation ist Scrum kaum vorstellbar. Fehlende Kommunikation und Missverständnisse bei den Requirements konnten zu Wasserfallzeiten teuer werden: Sie waren einer der Haupttreiber bei der Hinwendung zu einem dezentralen Entwicklungsansatz. So betrachtet man heute ein Team wie eine gut geölte Maschine, deren Teile nahtlos ineinandergreifen:

Scrum kann nur funktionieren, wenn eine offene und transparente Kommunikation gepflegt wird (Quelle: iStock / Viktoria Kurpas).

Developer helfen sich gegenseitig, melden Fortschritte und Verzögerungen und sprechen mindestens einmal täglich mit den nicht-technischen Teammitgliedern sowie den im Umfeld des Teams liegenden Personen aus Fachbereichen – den Stakeholdern. Also eine Art verteiltes Bewässerungssystem im Vergleich zu einem großen Wasserfall.

Not a bang, but with a whimper

Allerdings gibt es eben auch Scrum-Projekte, welche die Erwartungen nicht erfüllen und die nach einem Jahr Realzeit sowie mehreren Personenjahren Entwicklungszeit erstaunlich wenig vorzuweisen haben. Da es keinen einzigen, großen Release-Tag gibt, tröpfeln die Ergebnisse als iteratives, langsames Scheitern ein. Maßnahmen können ergriffen werden – die allerdings wiederum Zeit brauchen, Kosten verursachen und keine Erfolgsgarantie bieten. Da Agilität gelegentlich mit einem Widerwillen zu klaren Ansagen einhergeht, kann sich der Versuch einer Problemlösung verselbstständigen. Tatsächlich durfte ich mehrfach Problemgespräche mit bis zu 20 Teilnehmern erleben, die sich über viele Stunden erstreckten und zu keinem Ergebnis kamen.

Jeder Beteiligte fokussiert sich auf sein Spezialgebiet, um optimale Ergebnisse zu erzielen (Quelle: iStock / enotmaks).

1/n schwarze Peter

Die Verantwortlichkeiten sind ebenso verteilt, was bedeutet: Alle tragen gemäß ihren Fähigkeiten zum Projekterfolg bei. Aber es heißt eben auch, dass es keine individuelle Schuld gibt. Die Enttäuschung angesichts des fehlenden Projekterfolgs zieht sich über einen langen Zeitraum, ebenso die individuelle Verantwortung. Die Gründe des Scheiterns sind dabei vielfältig, aber nicht komplett anders als die Gründe für das Scheitern vieler anderer Projekte.

Man könnte gewiss einwenden, dass das Verfahren im Großen und Ganzen dennoch funktioniert – wenn man wirklich gute Mitarbeiter hat, die miteinander reden und das Projektziel vernünftig ist. Das stimmt, aber funktioniert es dann nicht immer? Geht man ein Projekt mit gesundem Menschenverstand an, mit einem guten und flexiblen Projektleiter sowie einigen Entwicklern, die wissen, was sie tun, und die gut miteinander auskommen, könnte es dann nicht vielleicht auch so gehen – ganz ohne Standups, Planningpoker und Retros?

Die ideale Welt – gibt es nicht

Wenn ich Offenheit und Transparenz ebenso voraussetze wie ein kommunikatives Team, das respektvoll miteinander umgeht, einen verständigen und interessierten Kunden und geringe Zwänge von außen, wenige technische oder organisatorische Altlasten und einen Auftraggeber, der sich mit zwei von den dreien Projektparametern (Funktionsumfang, Kosten, zeitliches Ende) zufrieden gibt – mit solchen Startbedingungen müsste man schon großes Pech haben, damit ein Projekt fehlschlägt.

Wenn alle Voraussetzungen erfüllt sind, ist das Ergebnis ein erfolgreiches Projekt (Quelle: iStock / Govindanmarudhai).

Die Frage ist, welchen Mehrwert Scrum bietet, wenn es Probleme nicht lösen kann, an denen auch andere scheitern: Wo liegt denn dann der Vorteil? Eventuell verzögert es Problemlösungen: Ein Beispiel hierfür wäre Brooks’s Law, dessen Auswirkungen in einem selbstorganisierenden Team mit ausdrücklich geringem Fokus auf der Spezialisierung der Mitglieder als weit gravierender anzunehmen sind als bei einem Team mit zentraler Steuerung und hoher Arbeitsteilung.

Agile Vorgehensweisen, in der Regel in einer Mischform mit Scrum als Hauptzutat, werden praktisch überall eingesetzt; sie sind der kleinste gemeinsame Nenner, auf den man sich einigt, und die Sprintziele kleben noch an den Wänden, wenn das Team längst weitergezogen ist. Sie bieten auf alles eine Antwort. Aber welche Lösungen sind im „agilen Werkzeugkasten“ denn nun drin? Welche Schwäche haben die Methoden? Und wo sind andere Modelle vielleicht tatsächlich überlegen?

In einer kleinen Serie wollen wir ein paar Untiefen von agilen Vorgehensmodellen in der Praxis ausloten – dabei geht es nicht darum, rundum „bessere“ Alternativen zu erarbeiten, sondern eher Schwächen zu verstehen, um besser mit ihnen arbeiten zu können.

Im nächsten Beitrag beleuchten wir reale Einsatzbedingungen im Allgemeinen und Machtgefälle in Teams im Besonderen.

Quelle Titelbild: iStock / ribkhan

Kommentieren

Diesen Beitrag teilen

Alle Beiträge zu Agile Enterprise

Mehr erfahren
Martin Lederer - metaMind
Solutions Architect
Mehr erfahren

Meist gelesene Beiträge

metaMinds

Vom Personal-Verwalter zum Potenzial-Entfalter

Eigentlich soll der Einsatz digitaler Tools die Personalarbeit erleichtern. Wenn aber best…

Weiterlesen
metaMinds

Digital Adoption: Warum es auf die letzte Meile ankommt

Je sperriger neue Anwendungen sind, desto schwerer tun sich Mitarbeiter, diese auch wirkli…

Weiterlesen
metaMinds

Stunde der Entscheidung: Kreuzungen in Projekten

Einer der Hauptaufwandstreiber in der IT-Beratung ist nach meiner Überzeugung der Umstand,…

Weiterlesen