Wo man auch immer man sich zum Thema Entwicklung trifft und austauscht, fällt das Wort „agil“. Manchmal hinter vorgehaltener Hand als DER Tipp – manchmal in Bezug auf eine Methode.

Agilität ist also in. Ist hip.
Wer bei Wikipedia nachsieht, wird die Bedeutungen „beweglich“ und „flexibel“ finden. Das klingt ja schon mal ganz brauchbar. Im allgemeinen Sprachumgang wird „agil“ eher in Verbindung mit rüstigen Menschen verwendet.
So lange wollen wir nun nicht warten. Beweglichkeit und Flexibilität können wir auch schon in jüngeren Jahren – in jüngeren Entwicklungsstufen – gut einsetzen.
Ist „agil“ sein jetzt nur eine Modewelle? Wenn ja, wieso brauchen wir beim Projektmanagement eine solche? Haben wir nicht schon genug theoretische Lösungskonzepte mit zu wenig praktischer Umsetzung? Wie soll uns diese Agilität weiter bringen?
Um Antworten auf diese Fragen zu finden und den Mystizismus auf reale Beine zu stellen, blenden wir zuerst 11 Jahre zurück. Die Wirtschaft war damals geprägt durch:

• Erzeugte Features und Produkte, die nie zum Einsatz kamen (Studien haben ~60% nicht verwendete Funktionalität aufgezeigt!)
• Erzeugte Features und Produkte, die nicht den geplanten Nutzen brachten
• Fehlerhafte Produkte
• Sich ständig ändernde Situationen und Rahmenbedingungen im Unternehmen
• Zu lange Lieferzeiten und ständige Lieferverzögerungen
• Kostenexplosionen

17 Vertreter der „leichtgewichteten Ansätze“ trafen sich 2001 und plauderten über Lösungsszenarien zu diesen wenig zufriedenstellenden  Ergebnissen. Die Überzeugung über sinnvolle Alternativen mündete in der agilen Allianz mit folgenden Grundsätzen:

• Menschen und Beziehungen statt Prozesse und Werkzeuge
• Funktionierende Software statt umfangreiche Dokumentation
• Mitwirkung von Kunden statt Vertragsverhandlungen
• Einstellen auf Veränderungen statt sture Planabarbeitung

Die Aussagen sind dann wie beabsichtigt angekommen, wenn beide Teile der Aussagen je Zeile als wichtig erachtet werden, aber die Ziele der linken Spalte über diejenigen der rechten gestellt werden.

Mit diesen Erkenntnissen wurde nahezu mit allen bekannten Wirtschaftsmustern gebrochen, denn mit den herkömmlichen Vorgehensweisen und Methoden war eine Verbesserung nicht mehr machbar.

Agilität zeichnet sich aus durch

Manchen sprechen bereits von Agilität, wenn lediglich Flexibilität in der Konfiguration angeboten wird und/oder Module wahlweise eingesetzt werden. Das trifft aber absolut nicht zu.

Absolutes Muss ist die Einbindung der Kundenseite, deren Mitarbeit während der gesamten Erstellung, Umgang mit neuen oder geänderten Anforderungen und frühe Liefermöglichkeit fertiger einsatzfähiger Teilprodukte. Erst dann reden wir von Agilität.

Aus diesem Generalansatz entstanden diverse unterschiedliche Ausprägungen. Die einen konzentrierten sich auf agile Produktentwicklung, die anderen auf spezielle Entwicklungsmethoden für Software und der dritte auf agiles Projektmanagement.

Zu diesem Bündel gesellten sich noch weitere komplementäre Vorgangsweisen aus der Welt des hochproduktiven Arbeitens in Asien. Deren Betrachtung lassen wir jetzt außen vor.

Klassifizierung der Methoden/Frameworks

Generell erfolgt die Einteilung in eher leichtgewichtete und erweiterte Ansätze. So gelten Scrum, Lean und XP (Extreme Programming) als Vertreter der Ersteren. DSDM Atern und AgilePM  (Agile Project Management) hingegen werden der Zweiteren hin zu gerechnet.

Vom Einsatzzweck her wird Lean eher in Produktionsumgebungen als Verfahren zur Vermeidung von Verschwendung allerlei Art verwendet. XP findet insbesondere im Software-Engineering seinen Fokus und ist damit sehr spezifisch. Scrum als bekannteste Methode wird in der Produktentwicklung eingesetzt. Auch wenn der Hauptanwendungsbereich von Scrum in der Entwicklung von Software oder integrierter Soft-/Hardware besteht, so kann Scrum auch für andere Waren genutzt werden. AgilePM und Atern passen für alle Aufgaben mit emergenten Anforderungen und komplexen Firmenstrukturen. V.a. dann, wenn hohe Skalierbarkeit gefordert ist. Die Bandbreite reicht bspw. von der IT über die Organisationsentwicklung bis hin zur Teamkoordination in Segmenten des Bauwesens. Alle beide und Scrum können auch gut als Lösungsprozess bei einem unscharf definiertem Ziel als Werkzeug mit hoher Erfolgswahrscheinlichkeit heran gezogen werden.

Wenn also jemand von „Scrum“ spricht (einen der am meist verbreiteten Vertreter im deutschsprachigen Raum) und „agil“ damit meint, so ist das zutreffend. Aber in der agilen Welt gibt es weit mehr. Die Passung auf den Einsatzzweck ist das ausschlaggebende Kriterium der Selektion. Kombinationen daraus machen immer wieder genau DEN ausschlaggebenden Vorteil für Kunden aus.

Auswahl des agilen Ansatzes

• Wie sieht die Gesamtsituation/ der Hintergrund aus?
• Sind einfache oder komplexe Umgebungen zu berücksichtigen?
• Besteht die Aufgabe in einfacher Produktentwicklung?
• Wie häufig ändern sich die Anforderungen an das Produkt/werden Verbesserungsmöglichkeiten sichtbar?
• Sollen Projekte und Programme geliefert werden?
• Ist ein umfangreicherer Projektlebenszyklus erforderlich?
• Existieren projektübergreifende Abhängigkeiten?
• Findest Du mit minimaler Formalität das Auslangen oder ist die Einbindung einer strukturierten Unternehmensumgebung notwendig?