Agiles Vorgehen ist inzwischen in einer Vielzahl von Projekten vorzufinden. Dennoch ist es immer noch Neuland. Hast du gerade begonnen dich im agilen Umfeld zu bewegen? Oder bist du schon eine Weile dabei? Hier sind 7 typische Fehler im agilen Projektmanagement und wie du ihnen begegnen kannst.
Keine Vision haben
Warum machen wir das Ganze eigentlich? Und was bedeutet Erfolg für uns? Für jeden Einzelnen ist es viel leichter, die richtigen Entscheidungen zu treffen, wenn jeder weiß, wo die Reise hingehen soll. Dabei kann ein starker Product Owner (PO) helfen. Er sollte echte Entscheidungsbefugnisse haben und kontinuierlich seine Mission teilen. Nehmt euch Zeit darüber zu sprechen – veranstaltet z. B. einen Workshop in dem ihr die Ergebnisse erarbeitet.
Keine Vorbereitung, kein Planning
Ein neuer Sprint soll starten. An dieser Stelle versteckt sich bereits der zweite Fehler von agilen Projekten: Bei der Besprechung der kommenden Aufgaben ergibt sich eine große Reihe ungeklärter Fragen. Wo kommen die Inhalte her? Wie soll der Dialog aussehen? Wer darf die Funktion nutzen? Lässt sich das technisch überhaupt umsetzen und wie? Wie passt die neue Funktion zum Rest der Anwendung und warum braucht der Kunde das eigentlich?
Das Planning zieht sich wie Kaugummi. Letztendlich wird ein Sprint gestartet. So richtig geklärt sind die Dinge aber noch nicht und die Schätzungen fühlen sich auch nicht gut an. Klar, es wird immer eine Restunsicherheit geben oder Dinge, die sich während der Bearbeitung ergeben. Ein Grundverständnis und -gefühl sollte jedoch vorhanden sein.
Für jede Story braucht es ein gemeinsames Verständnis. Es lohnt sich im Rahmen des agilen Vorgehens schon vor dem Planning über anstehende Aufgaben zu sprechen, um genügend Zeit zu haben und den Umfang zu schärfen.
Und wann ist eine Aufgabe nun fertig für einen Sprint? Die Antwort auf diese Frage lässt sich in einer Definition of Ready festhalten und immer wieder als Checkliste nutzen.
Stumpfes Umsetzen
"Wir haben uns schon gedacht: das kann nicht richtig sein. Wir haben es trotzdem so umgesetzt." Schön. Hilft aber kein bisschen. Der dritte agile Fehler ist stumpfes Umsetzen von Anforderungen, die niemand so richtig verstanden hat. Jeder im Team ist dafür verantwortlich ein optimales Ergebnis zu erreichen.
Schließlich geht es am Ende darum einen Wert zu erzeugen und nichts für die Tonne zu produzieren. Das ist für alle unbefriedigend – nicht nur für Team und PO, sondern auch für Kunden und andere Stakeholder.
Falls so etwas beim agilen Arbeiten passiert, sollte in der Retro darauf eingegangen werden um die Gründe zu erörtern. Vielleicht liegt es an der Angst Fehler zu machen oder die Vision wurde noch nicht richtig verstanden.
Erst zum Review Ergebnisse präsentieren
Der Sprint ist zu Ende und es wird präsentiert. Es fallen lauter Kleinigkeiten auf, die man noch hätte besser machen können. Nun ist der Sprint aber vorbei und neue Stories müssen zur Verbesserung erstellt werden.
Wenn die Zeit da ist, wieso fertige Stories nicht vorher schon mit dem PO besprechen? Eine guter Zeitpunkt dafür ist z. B. nach dem Daily. Dabei ergibt sich wichtiges Feedback, welches ein Inkrement erst so richtig wertvoll macht.
Es wird immer Dinge geben, die ein neues Ticket erfordern, so wie es immer Dinge geben wird, die man auch gleich mit umsetzen kann / hätte können.
Auf mehreren Hochzeiten gleichzeitig tanzen
Puh, ganz schön stressig, aber was soll man machen? Da sind eben noch die anderen Projekte, für die man verantwortlich ist. Und ab und zu kommen einfach noch andere Aufgaben dazwischen. Irgendwie funktioniert das schon. Wirklich?
Nun eigentlich wissen wir ja: Wenn wir etwas wirklich gut machen wollen, braucht es Zeit und (ungeteilte) Aufmerksamkeit. Macht euch eure Störfaktoren bewusst. Mehrere Projekte bedeuten immer auch Kontextswitche – und die sind teuer.
Was lässt sich ändern? Lassen sich diese Störungen vielleicht sogar beseitigen? Eine Möglichkeit wäre es z. B. bei der Verfügbarkeitsplanung andere Projekte mit einzubeziehen. So wird Zeit für andere Dinge eingeplant.
Scrumtheater spielen (How to build your own Cargo Cult)
Warum schätzen wir eigentlich mit Storypoints? Wir rechnen doch intern sowieso wieder mit Tagen. Der Releaseplan ist auch wie immer und überhaupt haben sich nur ein paar Namen geändert. Wir haben jetzt noch mehr neue Meetings.
Wenn die Meetings und Tools nur eingesetzt werden, damit man sagen kann “Wir sind jetzt agil”, bekommt man alten Wein in neuen Schläuchen. Jedes Meeting mutiert dann zu eine Charade, bei der alle nur agil spielen, tatsächlich aber alles andere als agil sind. Die Gründe dafür können vielseitig sein. Vielleicht passt das Umfeld gar nicht? Oder das Team möchte sich gar nicht verändern / agil werden?
Meistens passiert so etwas, wenn einfach beschlossen wird: “So, wir sind ab sofort agil!”.
Definition of Done
Wann sind wir eigentlich fertig? Eine wichtige Frage! Bleibt diese Frage ungeklärt wird es sehr schwer, einen Abschluss zu finden. Ich habe in einem agilen Projekt mal eine Story mit 500 Kommentaren gesehen. Diese Story wurde von Sprint zu Sprint geschoben und stets erweitert. Sie wurde einfach nie fertig.
Frust ist vorprogrammiert.
Besser ist es, klar zu formulieren, was zu einer Story gehört und was nicht. Im Zweifel lieber eine Folgestory festhalten. Eine Diskussion über die allgemeine Definition of Done (DoD) regt zum Nachdenken an, was wirklich wichtig ist.
Mehr zu User Stories kannst du übrigens im Artikel "Was sind (gute) User Stories?" von meiner Kollegin Katharina Lattenkamp nachlesen.
Welche Qualitätsansprüche haben wir? Reicht es, nur Quellcode zu produzieren? Was ist mit Releasenotes oder dem Deployment? Die DoD macht Schätzungen leichter und vergleichbarer. Beispiel: Eine Story mit Test und Deployment dauert länger als eine Story ohne diese beiden Punkte.
Das waren 7 Fehler bei agilem Vorgehen. Hast du dich wiedergefunden? Was ist dir in deinen Projekten aufgefallen? Erzähl uns gerne deine Erfahrung, als Kommentar zu diesem Beitrag.
Kommentare