
Agile - Die häufigsten Fehler
Written by Robert
📅 2025-04-11 | 🚀 Galvanytics | 🏷️ Projectmanagement
Inhaltsverzeichnis
TABLE OF CONTENTS
- 1.Agile nicht verstehen#agile-nicht-verstehen
- 2.Zu starke Versprechungen#zu-starke-versprechungen
- 3.Falsche Geschwindigkeit#falsche-geschwindigkeit
- 4.Nur Namensänderung#nur-namensänderung
- 5.Abschätzen von Aufwand und Zeit#abschätzen-von-aufwand-und-zeit
- 6.Immer wieder die gleichen Meetings#immer-wieder-die-gleichen-meetings
- 7.Das Management#das-management
- 8.Zuviel Regulierung#zuviel-regulierung
- 9.Keine Transparenz#keine-transparenz
Agiles Projektmanagement
Agiles Projektmanagement ist wohl das Buzzword der letzten Jahre. Auch bei meinem letzten Arbeitgeber, stand "agiles" Arbeiten auf der Tagesordnung. Allerdings gab es so einige Hindernisse. In diesem Artikel werde ich ein paar Fehler beschrieben von Michael de la Maza aufgreifen und mit meinen eigenen Erfahrungen anreichern.
Agile nicht verstehen
Die agile Denkweise beschreibt eine Philosophie, die sich von der traditionellen Projektmanagement-Methoden unterscheidet.
- Agiles Projektmanagement bekräftigt enge Zusammenarbeit zwischen den Teammitgliedern und den Stakeholdern, statt einer zum Projektstart verhandelten Anforderungsliste.
- Flexibles Planen: Agile beinhaltet häufige Änderungen an Plänen und Schätzungen, um den Wert zu maximieren, im Gegensatz zum traditionellen Projektmanagement, das starr an den ursprünglichen Plänen festhält.
- Team-Entscheidungsfindung: In agilen Projekten haben die Teammitglieder die Autonomie, Aufgaben und deren Ausführung zu entscheiden.
Zu starke Versprechungen
Agiles Projektmanagement ist nicht die Lösung für alle Probleme. Ich möchte hier nochmal auf die agile Denkweise und die Stacey Matrix hinweisen. Es ist wichtig, realistische Erwartungen zu setzen und die Grenzen der Methode zu verstehen. Wird Agilität als Allheilmittel dargestellt, kann dies zu Enttäuschungen führen, wenn die Ergebnisse nicht den Erwartungen entsprechen.
Was sollte man also kommunizieren bzw. beachten?
- Vorteile von Agilität herausarbeiten ohne Ergebnisse oder Zeitpläne zu versprechen.
- Den Kunden und sein Umgebungsfeld kennen bzw. die Vorteile für sein eigenes Unternehmen kennen.
- Feedback und Metriken einholen, um den Fortschritt zu messen und die Erwartungen anzupassen. Das schafft Transparenz und Vertrauen.
- Kleine Erfolge feiern, um das Team zu motivieren und den Kunden zu zeigen, dass es Fortschritte gibt.
Falsche Geschwindigkeit
Gewisse Prozesse brauchen Zeit und das muss man zum einen verstehen und zum anderen auch akzeptieren. Ein Biskuit-Boden braucht ca. 20 Minuten im Backofen, die Erhöhung der Temperatur oder Reduzierung der Backzeit wird nicht zum gewünschten Ergebnis führen. Gute Qualität braucht Zeit. Damit das Unterfangen gelingt braucht es Fürsprecher und Unterstützer, die den Prozess vorantreiben und auch mal auf die Bremse treten. Folglich ist es wichtig, dass das Management den Prozess unterstützt und nicht nur die Ergebnisse sieht.
Ähnlich wie beim Backen, muss die richtige Geschwindigkeit experimentell herausgefunden werden. Der gleiche Biskuit-Boden gelingt in einem anderen Ofen vielleicht schneller oder langsamer.
Nur Namensänderung
Agilität ist eine Denkweise, folglich nützt es nichts, nur die Namen der Meetings, Prozesse und Rollen zu ändern. Als Beispiel sei die Umbenennung des Projektleiters in den Product Owner genannt. Das ist keine wirklich spürbare Transformation, allerdings werden hier schon Erwartungen an das gesamte Team geweckt, die nicht erfüllt werden können. Zwar kann die Moral des Projektleiters erstmal steigen, wenn sich aber nicht ändert, kann seine Moral am Ende sogar sinken.
Vermutlich hört man dann sowas wie: „Das ist neumodiger Quatsch.“ oder „Ist doch das gleiche wie früher.“. Warum nicht erst mit der Transformation beginnen und dann die Namen ändern?
Abschätzen von Aufwand und Zeit
Das Schätzen von Aufwand und Zeit ist eine der größten Herausforderungen im Projektmanagement.
Auch hier gilt wieder, zu starke Versprechungen können zu Enttäuschungen führen. Aber auch gar keine Aussage zu treffen ist nicht zielführend.
Daher sollte der Fokus von Vorhersagen zu echten Abschätzungen basierend auf historischen Daten gelenkt werden.
Hier kann man mit oberen, unteren und mittleren Schätzungen arbeiten, um auch Unsicherheiten und Veränderungen innerhalb der Projektlaufzeit zu berücksichtigen.
Nicht zu vergessen sind neue Aufgaben, die während des Projekts hinzukommen können.
Zudem kann es helfen mit Metriken zu arbeiten und sich folgende Fragen zu stellen:
- Wie schnell kann dein Team eine Kundenanfrage bearbeiten? (Messung von Accpetance bis zum Release)
- Wie viel Arbeit kann dein Team in einem Sprint erledigen? (Messung von Story Points)
- Wie ist die Qualität der Arbeit? (Messung von Bugs, die während des Sprints auftreten)
- Wie oft konnte dein Team die geplante/gedachte Arbeit abschließen? (Messung von Burndown Charts)
Zum Schluss noch ein Wort über Übergabezeiten. Agilität bedeutet nicht, dass es keine Übergabezeiten mehr gibt. Das wäre zwar schön, ist aber nicht realistisch. Eine Kennzahl, um Übergabezeiten zu messen, ist die Flow Effektivität.
Immer wieder die gleichen Meetings
SCRUM schreibt eine Reihe von regelmäßigen Meetings vor, die darauf abzielen, den Fortschritt zu verfolgen und die Zusammenarbeit zu fördern. Diese Meetings sind wichtig, können aber schnell langweilig werden, wenn sie nicht gut moderiert werden. Das kann dazu führen, dass die Teammitglieder nicht mehr aktiv teilnehmen und die Meetings als Zeitverschwendung empfinden.
Ähnlich wie mit einem Computerspiel, wenn ich als Nebenmission immer wieder die gleichen Aufgaben erledigen muss und bekomme immer die gleichen Ergebnisse, verliere ich schnell das Interesse und werde die Nebenmission eventuell nicht mehr machen.
Inspiration für neue Techniken und Ideen gibt es genügend, man muss nur danach suchen und sich trauen, diese auch auszuprobieren (kontinuierliche Verbesserung). Auch neue Gesichter und Perspektiven können helfen, die Meetings aufzulockern und neue Impulse zu setzen.
Fehler im Buy-in
Ein Buy-in ist eine Zustimmung oder Unterstützung für eine Idee, ein Projekt oder eine Initiative.
Das Management
Wer kennt es nicht, jemand sagt dir, "tue das" oder "mache jenes" und er hält sich selbst nicht daran. Wenn ich will, dass meine Kinder Brokkoli essen, dann muss ich es auch essen. Andernfalls werden sie vielleicht den Brokkoli essen, aber ich selbst verliere an Glaubwürdigkeit.
Das klingt so banal, ist aber in der Praxis nicht immer so einfach. Hier braucht es Vorbildsfunktionen und Mentoren, die den Prozess vorantreiben. Freiwillige, die ihre Ergebnisse teilen und in die Organisation tragen. Die entscheidenden Schlüsselrollen sollten also vor der Transformation identifiziert und entsprechend sensibilisiert werden.
Zuviel Regulierung
Autonomie ist ein wichtiger Bestandteil der agilen Denkweise. Regulierung oder gar Micro-Management reduzieren Kreativität und Innovation. Die Folge kann sein, dass die Teammitglieder sich nicht mehr trauen, ihre Ideen zu teilen oder Risiken einzugehen. Das kann zu einem Rückgang der Produktivität führen und die Motivation der Teammitglieder beeinträchtigen. Das bedeutet nicht, dass jeder machen kann, was er will. Es ist wichtig, dass es klare Ziele und Erwartungen gibt, die das Team erreichen soll und das auch jeder dem zustimmt.
Als Vater kann ich bestätigen, dass es super schwierig ist Verantwortung abzugeben. Nicht den Weg von Schule nach Hause zu kontrollieren und darauf zu vertrauen, dass die Kinder sicher und heil ankommen, ist nicht einfach. Aber wenn man sich darauf einlässt wird es zur Selbstverständlichkeit. Es fördert auch gegenseitiges Vertrauen und Respekt. Meine Kinder wissen, wie sie nach Hause kommen (auf ihre Weise) und das ist doch die Hauptsache. Natürlich frage ich nach, ob alles geklappt hat und natürlich gibt es auch ein paar Regeln. Klappen Sachen nicht, dann kann man hier gezielt nachsteuern bzw. nachbessern und anpassen an sich verändernden Situationen. Im Großen und Ganzen gilt auch hier Communication und Adapating to change.
Keine Transparenz
Ich glaube jeder kennt die Situation, er steht auf einem Bahngleis und der Zug, der eigentlich kommen sollte, kommt nicht. Die Anzeigen sagen nichts und die Durchsagen sind unverständlich - Das ist frustrierend. Wäre man nicht zufriedener, wenn jemand sagt: „Wir haben selbst keine Ahnung was gerade los ist, wir probieren aber alles was in unserer Macht steht Sie mit Informationen zu versorgen“? oder „Wir haben unseren Zeitplan nicht gut kalkuliert und werden uns um 20 Minuten verspäten“?
Fehler eingestehen oder Unwissenheit preiszugeben ist nicht einfach, aber es schafft Verständnis und kann helfen, Vertrauen aufzubauen.
Ein informeller Vertrag zwischen dem Team und den Stakeholdern über die Erwartungen und Ziele kann helfen, Missverständnisse zu vermeiden. Aber auch das eigene Bewusstsein kann durch Tools wie VAST Zyklus von Michael Sahota gefördert werden:
- Vulnerability: Wie verletzlich will ich sein?
- Authenticity: Handel ich authentisch?
- Safety: Wie sicher fühle ich mich?
- Trust: Wie viel Vertrauen habe ich in mein Team?
Ich kann meine Verletzlichkeit zeigen und beobachten, wie sich der Zyklus auf die anderen Bereiche auswirkt.