16.11.2015  Verfasst von Sascha Meyer in Agile Methoden  

Meine Top-5 Impediments agiler Softwareentwicklung

... und wieso sie gerne ignoriert werden.

Transparenz. Einer der in meiner Praxis meistgenannten Erwartungshaltungen an die Einführung von Agile. Endlich mal wieder als Führungskraft erfahren, was meine Leute so treiben.
Klare Prioritäten: Gerne! Fortschritt auf einen Blick: Unbedingt! Hindernisse aufzeigen: Bringt Sie mir, ich bin ja Führungskraft! Und dann ist die Transparenz plötzlich da. Und was passiert?

Nicht selten passiert zu wenig, um die schlummernden Potentiale der Organisation zu heben. Priorisiert wird weiter nach Bauchgefühl. Entsteht externer Druck (Chef in der Tür, zugesagte Termine) wird eingeknickt und geliefert. Hindernisse werden gerne betrachtet und diskutiert, solange diese durch das Team zu lösen sind und keine Investitionen zur Folge haben. Hand aufs Herz: Wer pflegt schon ein dediziertes Impediment Backlog und arbeitet aktiv an deren Behebung?

Dieser Zustand ist bedauerlich. Vielmehr können große Potentiale einer Einführung agiler Organisationsmethoden erst durch harte und kontinuierliche Veränderungsarbeit erschlossen werden.

Meine persönliche Top 5 der ignorierten Hindernisse in Organisationen:

1. Wissensinseln a.k.a. fachliche Experten werden akzeptiert oder gar gewünscht
2. Keine Abkehr von Push-Prinzipien und insbesondere die Limitierung der Work in Progress wird nicht zugelassen
3.
Kunden- oder Anwender-Feedback erfolgt spät oder gar nicht
4.
Überfällige technische Modernisierungen wie Automatisierungen oder Veränderungen der Architektur werden nicht gefördert
5.
Personelle Kapazitätsgrenzen werden nicht behoben

Warum passiert das? In vielen Gesprächen mit Führungskräften habe ich eine gemeinsame Ursache identifiziert:

Kurzfristige realisierbare Erfolge werden stets bedeutsamer bewertet als die Ergebnisse langfristiger Maßnahmen. Der Experte ist kurzfristig schneller. Das kann man doch noch parallel machen. Das Produkt ist noch nicht gut genug um es zu präsentieren. Wir brauchen erst die Features, dann können wir optimieren. Es dauert zu lange jemand Neues einzulernen, bevor er durchstartet.

Gibt es hier ein methodisches Allheilmittel? Leider nein, denn die potentiellen Lösungen sind common sense.

  • Transparenz über Invest und Ergebnis schaffen: Es sollte gemeinsam mit der Organisation eine transparente Bewertung und Dokumentation von Impediments und der Lösungsmöglichkeiten erfolgen. Eine gute Möglichkeit ist hierzu das A3 Problem Solving Sheet.
  • "Kein ganz oder gar nicht-Denken". Kurzfristige Nachteile können häufig eingegrenzt werden, wenn man die Veränderungen nach und nach einführt. So kann in den Regeln des Teams verankert werden, dass eine Aufgabe je Woche explizit nicht durch den Experten oder im Pair erbracht wird. Nach und nach kann diese Quote angehoben werden. Die Risiken und potentiell kurzfristigen Nachteile werden so reduziert. Viele große Optimierungsvorhaben können ähnlich wie User Stories in kleinere, schneller operationalisierbare Schritte zerlegt werden. Beispielswiese kann Testautomatisierung iterativ und risikoorientiert eingeführt werden.
  • Organisatorische Verbindlichkeit: Es sollten verbindliche Vereinbarungen zwischen Teams und Management getroffen werden. Regeln sind ein guter Einstieg, aber haben in der Hitze des Geschäfts praktisch nur eine geringe Verbindlichkeit. Eine schöne Methode ist die feste Allokation von Verbesserungsbudgets. Teams erhalten Geld, das Sie in Verbesserungen investieren können. Es ist dabei die Entscheidung der Teams, ob Sie dies z.B. in eigene Refactoring Entwicklung, Trainings, Tools oder externen Support investieren.


Haben Sie Mut. Sorgen Sie dafür, dass im Rahmen von Retrospektiven identifizierte Impediments auch in der Praxis angepackt werden. Adressieren Sie auch schwierige und vielleicht unbequeme Hindernisse. Sie werden sich in zwei Jahren dafür danken.  

Der Autor

Sascha Meyer
Management Consultant