In der Softwareentwicklung will heute praktisch jeder agil sein. Das klingt modern und dynamisch. Liest man die Werte, die hinter dieser Idee stecken (agiles Manifest), versteht man leicht, warum.

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Software ist wichtiger als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Es liegt aber im Wesen des Menschen, Ideen (auch gute) falsch zu verstehen – manchmal auch absichtlich, um eigene Interessen zu verfolgen.

Nach der Definitionswelle von eher schwergewichtigen Vorgehensmodellen, die den Prozess und dessen Befolgung in den Mittelpunkt stellten, rückt die Agilität wieder das ins Zentrum, was auch dorthin gehört – die Menschen, ihre Anforderungen, Kommunikation und Vertrauen.

Will man die agilen Werte leben, muß die eingefahrene Arbeitsweise oft radikal geändert werden. Diese Änderungen, zumindest die wirklich wichtigen, beziehen sich nicht auf Techniken und Methoden, schon gar nicht auf Tools, es sind Änderungen, die im Kopf der Beteiligten passieren müssen.

Zunächst im Kopf der Mitarbeiter – die Mitarbeiter müssen bereit sein,

  • Verantwortung zu übernehmen – sonst kann sich ein Team nicht selbst organisieren,
  • ihre Arbeit transparenter zu machen – nur so erhält man einen „ehrlichen“ Status zur Steuerung der Zielerreichung,
  • Fehler zu machen, diese schnell aufzudecken und daraus zu lernen,
  • mit anderen zu kommunizieren – d.h. reden, nicht Email oder Dokumente – z.B. mit anderen gemeinsam am Flipchart ein Problem analysieren und einen Lösungsweg zu skizzieren,
  • als Team erfolgreich zu sein.

Auch im Kopf des Managements müssen manche alten Denkmuster über Bord geworfen werden. Das Management muß bereit sein,

  • Verantwortung abzugeben – und den agilen Teams zu übertragen,
  • eine Hauptaufgabe darin zu sehen, Hindernisse zu beseitigen, die die Teams auf ihrem Weg zur Zielerreichung nicht selbst beseitigen können,
  • Fehler zu erlauben und damit die empirische Prozessverbesserung erst zu ermöglichen,
  • den Mitarbeitern zu vertrauen.

All diese Punkte prägen die Kultur einer Organisation und machen sie damit zugänglich für Agilität, oder eben nicht. In einem Umfeld, das auf Mißtrauen basiert, in dem Fehler nicht erlaubt sind, in dem die Mitarbeiter nur nach Vorschrift arbeiten wollen, wird agiles Vorgehen nicht funktionieren. Das liegt aber nicht an der Idee der Agilität, sondern an den Menschen. Menschen zu ändern, ist ungleich schwieriger, als Technologien zu ändern. Vielleicht stürzen wir uns deshalb viel lieber auf die Technik, auf Prozesse und Methoden.

Agilität beginnt im Kopf – und sie geht dort auch weiter.

Das Leichtgewichtige an den postulierten Werten stellt höhere Anforderungen an die Fähigkeiten der Mitarbeiter, insbesondere im Bereich Requirements Engineering. Die Maxime „Funktionierende Software ist wichtiger als umfassende Dokumentation“ bedeutet ja nicht, daß gar keine Dokumentation und Spezifikation notwendig ist. Wieviel spezifiziert werden muß, hängt von vielen Faktoren ab, u.a. von der Problemdomäne. Aber es muß nicht in jedem Fall viel spezifiziert werden, schon gar nicht am Anfang eines Projektes. Wenn nicht jede Anforderung schriftlich fixiert wird, sondern viel eben auch durch Kommunikation während der Entwicklung geklärt werden kann, bedeutet das ja nicht, daß z.B die Qualitätskriterien für Anforderungen nicht eingesetzt werden sollten. Es passiert dann im Kopf, im Gespräch – eine anspruchsvolle Aufgabe. Agile Teams müssen im Bereich Requirements Engineering gut ausgebildet sein, um die agilen Werte in erfolgreiche Produkte umwandeln zu können.