Agile – Das klingt frisch, das klingt dynamisch: Irgendwie hat sich herumgesprochen, dass es sich hier um das Nonplusultra der Entwicklungs-Philosophie handeln muss. Selbst Personen, die außer vielleicht einem gesunden Appetit in ihrem Leben bislang noch nichts entwickelt haben, fragen gerne einmal, ob man denn auch “agil entwickeln” würde. Es ist wahrscheinlich eines der Buzzwords der letzten Jahre. Aber, ist Agile auch immer der richtige Ansatz? Garantiert er automatisch ein brauchbares bzw. Kunden-orientiertes Produkt?
Die Antwort, gerade zur zweiten Frage, ist ein klares Nein. Doch gerade dieses vermeintliche Versprechen erhebt Agile jedoch für viele zum heiligen Gral.
Der agile Ansatz als „Lippenbekenntnis“ ist eher gefährlich. Oder wie mein Lieblings-Agile-Coach sagt: „Richtig ‚Agile‘ bedeutet schon mutig zu sein.“ Genau das ist den wenigsten jedoch bewusst. Sie glauben, es ginge einfach von selbst leichter und einfacher. Doch gerade die Grundsätze von Agile werden jedoch in der Regel nicht beachtet: In vielen größeren Organisationen werden Entscheidungen nach wie vor sehr hierarchisch getroffen. Da berichtet der Projekt-Mitarbeiter an den Teilprojekt-Leiter, der an den Projektleiter und dieser an Lenkungs- und Steuerungs-Kreise, die sich im Zweifel nochmal in der Linienorganisation rückversichern müssen. Genau das hat mit Agile jedoch nichts zu tun. „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Wer hier nicht ehrlich zu sich selbst ist, und eigentlich noch in tradierten Strukturen arbeitet, aber gerne vorgibt jetzt bestimmt „agil“ zu sein, der wird Schiffbruch erleiden.
Die Grundsätze von Agile werden oft nicht beachtet
Neben der Entscheidungsfähigkeit des Projekt-Teams, spielt allerdings auch die Einbindung des Kunden eine zentrale Rolle. Und solange es nicht gelingt, den (richtigen) Kunden (oder den Kunden richtig) in den Entwicklungsprozess zu integrieren, spielt es keine Rolle nach welchem Paradigma am Kunden vorbei entwickelt wird. Häufig genug passiert es sowohl beim Schreiben einer Spezifikation im nicht-agilen Ansatz, als auch bei den Sprint-Terminen im agilen Ansatz, dass der richtige Kunde (z.B. der tatsächliche Nutzer) gar nicht beteiligt oder anwesend ist. Er ist nicht selten der Mitarbeiter, der wichtige andere Dinge zu tun hat – beispielsweise sich um das Tagesgeschäft zu kümmern. Der entsandte Stellvertreter, der gerade verfügbar ist, weiß es so ungefähr, hat es schon mal gesehen, oder hat zumindest schon mal mit jemandem darüber gesprochen, der es wissen müsste.
Es ist wie bei dem Witz mit dem Betrunkenen, der seinen Schlüssel verzweifelt unter der Straßenlaterne sucht, mit der Begründung, dass er dort besser sehen kann als im dunklen Gebüsch wo er den Schlüssel eigentlich verloren hat. Manche Abkürzungen sind eben leider keine. Die Enttäuschung des Kunden ist in diesen Fällen vorprogrammiert.
Aber auch wenn der Kunde sich richtig einbringt, ist Agile dann auch in jedem Fall besser? Auch hier meine ich, nein. Agile bietet sich an und ist gegebenenfalls sogar notwendig und hilfreich bei besonders komplexen Projekten, mit verteilten Rollen und langen Laufzeiten, bei denen sich vor allem nicht alle Abhängigkeiten im Vorhinein identifizieren lassen und diese ggf. auch gar nicht kontrolliert werden können (eine schöne Erläuterung was „komplex“ und was „kompliziert“ ist – und wie man jeweils damit umgehen sollte – hat Thorsten Wolf auf agile4work.de niedergeschrieben.
In diesen Fällen ist eine fixe Planung zu Beginn teilweise gar nicht möglich. Agile ist in diesen Fällen eine Art „kleineres Übel“, das in einer immer komplexer und vernetzter werdenden Welt in Kauf genommen werden muss, um überhaupt ans Ziel zu kommen. Gerade hierfür brauche ich dann den Mut auf die „motivierten Individuen“ zu setzen, und das Vertrauen, „dass sie die Aufgabe erledigen“. Jede Spezifikation ist ansonsten inhaltlich überholt bevor sie abgestimmt und freigeben wurde.
Gerade bei architektonischen Entscheidungen darf das Ziel zu Beginn nicht vollkommen unklar sein
Auch in solch komplexen Projekten bedeutet Agile jedoch nicht, dass das Ziel zu Beginn vollkommen unklar sein darf, allenfalls der Weg dorthin. Gerade architektonische Entscheidungen werden sonst unter Umständen völlig falsch und praktisch irreversibel getroffen. Derartige Abhängigkeiten müssen dem Kunden so früh wie möglich erläutert und das Ziel mit ihm besprochen werden. Denn wenn ein Bauherr nicht weiß, ob am Ende ein Einfamilienhaus oder eine Tiefgarage herauskommen soll, und nicht einmal rudimentär damit vertraut gemacht wird, welche Bau-Technik für welches Vorhaben besser geeignet ist, wird er weder mit der Fertighaus- noch der Stein-auf-Stein-Methode zum gewünschten Ziel gelangen.
Nach mehreren „agilen“ Volten während der Bauphase steht er am Ende entweder in einem viel zu teuren Einfamilienhaus, oder einer ziemlich hässlichen Tiefgarage.
Benutzer-Bewertung
( Stimmen)
