Bessere Software zu entwickeln, und das sogar deutlich schneller: Mit diesem Anspruch formulierten IT-Spezialisten bereits 2001 das Agile Manifesto. Viele Unternehmen haben seitdem agile Methoden eingeführt – sowohl in der IT als auch in anderen Arbeitsfeldern. Doch nicht überall herrscht Euphorie, denn agile Methoden machen Teams nicht auf Knopfdruck produktiver. In unserer Praxis begegnen uns immer wieder diese vier Probleme:

1. Die falsche Methode

Scrum ist die bekannteste agile Methode, aber sie passt nicht zu jeder Aufgabe. Ihr größtes Potenzial entfaltet sie in der IT- oder Produktentwicklung. Einzelne Eigenschaften (Features) dieser Produkte lassen sich als kurzfristige Zwischenziele sehr gut abgrenzen. Anders verhält es sich jedoch zum Beispiel im Projektmanagement: Sprints sind hier nicht so einfach zu definieren. Als Alternative bietet sich häufig eine agile Methode an, die dem Lean Management entstammt: Kanban. Sie lässt sich auch mit einer klassischen Wasserfallmethode verbinden.

2. Starre Systeme, träge Strukturen

Nicht jedes IT-System erlaubt es, damit agil zu arbeiten. Viele Unternehmen müssen erst neue Tools einführen. Parallel dazu steht die IT vor der Aufgabe, gewohnte Strukturen aufzubrechen. Ziel: Jedes Projektteam sollte möglichst die durchgehende Verantwortung für ein Produkt und die zugehörigen Systeme besitzen, um Schnittstellen zu anderen Bereichen zu vermeiden. Für eine agile IT-Organisation gibt es keine Blaupause, die jedes Unternehmen anwenden kann. Einige Firmen arbeiten zum Beispiel mit einer Matrix-Organisation, die sich aus sogenannten Chaptern und Gilden zusammensetzt: Jedes Team ist interdisziplinär aufgestellt und einem einzelnen IT-Produkt (Chapter) zugeordnet. Dafür übernehmen die Mitarbeiter die gesamte System- und Datenbankadministration, die laufende Weiterentwicklung und die zugehörigen Tests. Über die Chapter hinweg gehören IT-Spezialisten mit gleichen Rollen einer Gilde an, zum Beispiel der Entwickler-Gilde, der die disziplinarische Führung zukommt. Schwierig kann es werden, wenn nach alter Sitte nicht sauber getrennt wird: Üblicherweise sollte ein Chapter keine weiteren Aufträge erhalten oder ein Spezialist in mehreren Chaptern arbeiten.

3. Wachstumsschmerzen

Meist erproben Unternehmen Agilität in einem kleineren IT-Team. Dabei geht es in der Regel um Pilot- oder Prototyp-Projekte, die generell sehr innovativ sind. Läuft dies gut, versucht man das Prinzip auf weitere Bereiche zu skalieren. Probleme treten dann zum Beispiel auf, wenn Ressourcen fehlen, etwa nicht genügend Mitarbeiter als Tester zur Verfügung stehen. Möglicherweise hat das Unternehmen den Preis der Agilität unterschätzt und muss zusätzlich investieren.

4. IT-Kollegen als Exoten

Die IT arbeitet agil, doch der Rest der Organisation ist darauf nicht eingestellt – ein schwieriges, leider häufiges Szenario. Auch die internen Kunden in den Geschäftsbereichen müssen agile Methoden verstehen, wertschätzen und mittragen. Im besten Fall ist Agilität ein Teil der Unternehmenskultur, unabhängig von dem Maß, in dem Bereiche außerhalb der IT die Methode im Alltag anwenden. Praktisch bedeutet das: Nicht nur IT-Mitarbeiter erhalten Trainings in agilen Prinzipien; auch ihre internen Kunden werden geschult.

Diese vier Herausforderungen haben eines gemeinsam: Es gibt dafür nicht die eine, universelle Lösung. Jedes Unternehmen findet im besten Fall seinen eigenen Weg, indem es die vermeintliche reine Lehre hinterfragt und anpasst. Soll die gesamte Organisation agil werden oder nur die Bereiche, die mit IT-Systemen befasst sind? Arbeitet jedes IT-Team agil – oder ist es im Einzelfall vielleicht sinnvoller, bei der Wasserfallmethode zu bleiben? Erfordert ein IT-System wirklich ein eigenes Chapter oder könnte ein Team mehrere Systeme oder gar Produkte betreuen? Die Zukunft von Agilität wird sein, dass Teams individuelle Vorgehensweisen entwickeln, in die Elemente von Scrum, DevOps, Kanban oder anderer Methoden einfließen.