Typische Fehler beim agilen Arbeiten

Die agile Arbeitsweise ist aktuell ziemlich verbreitet und viele Unternehmen arbeiten bereits agil. Jedoch gibt es auch nach der erfolgreichen Einführung  noch keine Garantie, dass es gut funktionieren wird – es können immer noch einige Fehler passieren, die die agile Arbeitsweise sabotieren könnten. Hier sind einige solcher Fehler, die beim agilen Arbeiten passieren können.

1. Fehler: Vision & Mission nicht richtig kommunizieren

Der erste Fehler kann bereits bei etwas Grundlegendem und zwar bei der Vision entstehen. Hier ist es wichtig, genau zu wissen und zu kommunizieren, wohin die Reise gehen soll. Folgende Fragestellungen sollten geklärt sein: “Warum macht man das, was man macht?”, “Was bedeutet Erfolg?”. Die richtigen Entscheidungen können nur getroffen werden, wenn jeder Einzelne im Unternehmen die Vision kennt und sich damit identifizieren kann. In agilen Teams kann bereits ein starker Product Owner (PO) diese Aufgabe übernehmen, da dieser die notwendigen Entscheidungsbefugnisse hat und regelmäßig die Vision und Mission wiederholen und mit dem Team teilen kann.

2. Fehler: Nicht ausreichende Sprint-Vorbereitung & -Planung

Der zweite mögliche Fehler kann bereits zusammen mit einem neuen Sprint entstehen. Ein Warnzeichen dabei ist, wenn während des Sprint-Planning und der Besprechungen von kommenden Aufgaben eine Menge ungeklärter Fragen offenbleibt. Das bedeutet im Rückschluss, dass hier noch Inhalte fehlen und einige Abstimmungen folgen sollten. Wenn mit solcher Basis der Sprint startet, dann müssen die Inhalte geliefert werden, statt die Aufgaben zu erledigen. Ohne klar definierte User Stories können auch keine sauberen Schätzungen abgegeben werden und somit wächst das Risiko, den Sprintplan nicht einhalten zu können. Wichtig dabei zu wissen ist, dass man für jede User Story  ein gemeinsames Verständnis im Team benötigt. Es müssen bereits vor dem Sprint-Planning die anstehenden Aufgaben vorbereitet und klar definiert werden. Den Reifegrad für die Vorbereitung der Aufgaben liefert dann die Definition of Ready, die immer wieder als Checkliste genutzt werden soll.

3. Fehler: Umsetzen lassen ohne das “Big Picture” dahinter

Der dritte Fehler lauert hinter der Umsetzung von Aufgaben und zwar wenn man Anforderungen umsetzt, die niemand so richtig verstanden hat. In der agilen Welt ist jedes Team-Mitglied selbst dafür verantwortlich, die bestmögliche Lösung bzw. Ergebnis zu liefern. Aber wie soll das funktionieren, wenn die Team-Mitglieder den Hintergrund der Anforderungen gar nicht verstehen haben oder nicht nachvollziehen können. Letztendlich geht es ja darum, einen (Mehr-)Wert für das gemeinsame Produkt zu erzeugen und nicht für die Tonne zu arbeiten. Eine Möglichkeit, so einer Lage für alle Beteiligten zu entgehen, könnte die Retro sein. Hier soll darauf eingegangen werden, die Gründe für die Anforderungen bzw. Aufgaben zu besprechen, da hier eventuell immer noch die Vision, die nicht richtig kommuniziert wurde, fehlt.

4. Fehler: Ergebnisse erst im Review besprechen

Auch am Ende eines Sprints kann ein grober Fehler passieren, sobald die Ergebnisse gezeigt werden. Häufig bleiben noch Kleinigkeiten übrig, die man noch machen könnte, aber der Sprint ist nun zu Ende und neue User Stories warten schon im Backlog auf die Umsetzung. Was macht man nun mit den Kleinigkeiten, die geblieben sind? Es werden neue User Stories zur Optimierung angelegt und landen ebenfalls im Team-Backlog und dieser Stapel kann ziemlich schnell wachsen. Um diesen Fehler von vornherein nicht zu machen, sollte man bereits im laufenden Sprint Feedback-Gespräch mit dem Product Owner (PO) aufsuchen und versuchen, die Wichtigkeit zu vermitteln, was unter Umständen längere Umsetzungszeit bedeutet, aber im Endeffekt das gesamte Team somit in der Zukunft entlasten würde. Klar, es wird auch immer wieder Rest-Arbeiten oder Optimierungen geben, die eine neue User-Story erfordern, aber hier muss abgewogen werden, ob man diese doch gleich mit umsetzt oder nicht.

5. Fehler: An mehreren Themen gleichzeitig dran sein

Der fünfte Fehler besteht darin, an mehreren Themen gleichzeitig dran zu sein. Klar, es kommt durchaus vor, dass etwas Ungeplantes dazwischen kommt und mehrere Themen bzw. Aufgaben gleichzeitig erledigt werden müssen. Aber so etwas darf kein Dauerzustand sein, denn wenn man wirklich etwas gut machen möchte, dann braucht man Zeit und Aufmerksamkeit dafür. Denn Arbeit an mehreren Projekten bedeutet auch, dass man immer wieder zwischen den Themen hin und her “switchen” muss. Hier können Informationen verloren gehen, die Qualität kann abnehmen, was dem Unternehmen im Endeffekt nur Geld kosten wird. Das lässt sich verhindern, indem man versucht, solche “Störungen” von vornherein bei der Kapazitätsplanung mit einzubeziehen.

6. Fehler: Agiles Arbeiten nur “vorspielen”

Ein weiterer Fehler entsteht, wenn in Unternehmen von heute auf morgen einfach nur beschlossen wird, dass man ab sofort nur noch agil arbeitet. Was kann dabei eigentlich schief laufen? Plötzlich werden neue Begriffe, Meetings und Tools eingesetzt, damit man ab jetzt endlich agil arbeiten kann. Viele Unternehmen versprechen sich von der Agilität mehr Produktivität und Flexibilität. Doch ohne eine richtige agile Transformation besteht die Wahrscheinlichkeit, dass all die neuen schönen Tools, Meetings und Methoden gar nicht richtig wie geplant verwendet werden. Mit der Zeit verfällt dann alles doch wieder ins alte Muster weil “agil” eben nur “gespielt” und nicht richtig gelebt wird. Mehr zum Thema “Der richtige Start – Agile Transformation erfolgreich meistern“.

7. Fehler: Definition of Done – wann ist eine Aufgabe fertig?

Bei jeder User-Story stellt sich immer eine wichtige Frage: “Wann ist diese User-Story eigentlich fertig?” bzw. “Welche Kriterien müssen erfüllt werden, damit diese Aufgabe abgehackt werden kann?”. Wenn diese Fragen offenbleiben, dann ist es gar nicht möglich, einen Abschluss der jeweiligen User-Story zu erzielen. In der Praxis sieht man leider oft genug, wie manche User-Stories von einem Sprint in den nächsten immer wieder verschoben werden – diese scheinen nie fertig zu werden. Das ist dann für alle Beteiligten frustrierend und kann Auswirkungen auf die Motivation haben. Um so einen Fehler gar nicht zu begehen, muss zu jeder User-Story ganz klar formuliert werden, was dazu gehört und was nicht – eine klare Abgrenzung muss her. Lieber eine weitere User-Story aufmachen, wenn die Abgrenzung schwer fällt. Die Diskussionen über die allgemeine Definition of Done (DoD) ist dabei sehr wichtig. Das Team sollte darüber diskutieren und selbst entscheiden, was ihre Qualitätsansprüche sind, ob es ausreicht, nur den Quellcode zu produzieren oder die Ergebnisse im Anschluss noch ausführlich dokumentiert werden müssen.

Können wir Ihnen helfen?

Können wir Ihnen helfen?

Palina Vorobeva

Beitrag teilen:

Mehr Informationen, einen Austausch oder konkrete Unterstützung im Projekt?

Anfrage senden

Nach oben scrollen