Die Aufgabe ist spezifiziert. Die vorbereitenden Aufgaben sind gelaufen. Der Entwickler hat entwickelt. Nun muss - je nach Projektmethodik - der Entwickler, der PO oder der PM ansagen, dass die Aufgabe erledigt ist.
In vielen Projekten schmoren Tickets von fast-fertigen Aufgaben herum. Warum fällt es uns so schwer, FERTIG zu melden und zur nächsten Aufgabe überzugehen?
IT-Aufgaben perfekt zu lösen, ist nahezu unmöglich. Eine weitere Testabsicherung, eine klarere Struktur im Code, also ein schönerer Code, eine GUI-Umsetzung näher an der Vorlage - die Liste der Gründe, nicht fertig zu sein, ist lang.
Alle Mitarbeiter wollen gute Arbeit leisten. Eine Aufgabe als FERTIG zu markieren und sie für vollendet zu erklären, heißt auch, das Urteil anderer zuzulassen. Und zunächst keine Option auf Änderung zu haben. Und gleichzeitig ist kein Software-Entwickler bzw. eine Entwicklerin wirklich fertig. Eine "Definition of Done" hilft dem Entwickler bzw. der Entwicklerin bei der Entscheidung, ob diese fertig sind.
Es ist aber Entscheidung, FERTIG zu sein. Es ist kein abprüfbarer Fakt. Wenn zu viele Tickets auf "fast fertig" stehen, ist es Zeit, über die Fehlerkultur nachzudenken und einen Raum zu schaffen, in der kleine Fehler kein Problem darstellen - sondern ein Aufforderung an alle sind, besser zu werden. Wenn diese Offenheit gegeben ist, werden Aufgaben auch beendet werden.
- Nächster Artikel: Ankündigung: WDX | (Er-)Findet Eure Projektmethode
- Vorheriger Artikel: Neu an Bord: Manfred Jessen
- Kategorie: Projekt, Kultur
Kommentar schreiben