Warum gute Entwickler:innen keine Tickets abarbeiten wollen

Survival-Kit für Entwickler Teil 7 von 8 Zur Übersicht

Wenn mich im Refinement oder im Daily jemand aus dem Dev-Team fragt, was mit einem Ticket eigentlich erreicht werden soll, freue ich mich jedes Mal. Auch wenn ich dann weiß, dass ein bisschen Arbeit vor mir liegt, diese Frage zu beantworten. Ich weiß nämlich auch, warum sie gestellt wird.

In vielen Unternehmen ist eine solche Frage nicht beliebt. Da ist das Ticket das Gesetz und Jira der Richter.

Kein Wunder, dass Entwickler:innen dann frustriert sind. Sie sind es zu Recht.

Das Missverständnis: Tickets sind nicht die Arbeit

Tickets sollen Arbeit sichtbar machen. Sie sollen helfen, Dinge zu planen, zu priorisieren und zu koordinieren.

Das Problem beginnt dort, wo Tickets die Arbeit ersetzen, statt sie zu unterstützen.

Ein Ticket ist kein Problem. Es ist eine Repräsentation eines Problems, meist stark vereinfacht und oft aus dem Kontext gerissen.

Wer Software entwickelt, arbeitet aber nicht an Tickets. Sondern an Problemen, Zusammenhängen und Konsequenzen.

Was gute Entwickler:innen antreibt

Sie wollen verstehen, warum etwas gebaut wird. Sie wollen Entscheidungen treffen dürfen, statt Anweisungen umzusetzen. Sie wollen Feedback, vor allem von echten Usern. Und sie wollen Dinge fertig machen, nicht weiterreichen.

Sie optimieren nicht auf busy, sondern auf done. Genau hier entsteht die Reibung.

Wie Ticket-Abarbeitung Arbeit kaputt macht

In vielen Unternehmen passiert unbemerkt ein Rollenwechsel. Aus Problemlöser:innen werden Zustandsverwalter:innen. Man erkennt es an vier Symptomen.

Tickets werden übergeben statt gemeinsam gelöst. Für Diskussion, Planung oder Architektur gibt es keine Zeit.

Die Verantwortung endet an Spaltengrenzen. Eine Rückfrage ist unerwünscht. Ein Ticket ist nicht durch das Gespräch ready geworden, sondern weil es in „Up Next“ liegt. Zu genau diesem Punkt gibt es einen Deep Dive von mir.

Der Kontext geht bei jeder Übergabe verloren. Weil es angeblich effizienter ist, nicht über Tickets zu reden, verschwindet bei jedem Handwechsel ein Stück Wissen.

Erfolg wird daran gemessen, wie viele Tickets durchgezogen wurden. Die heilige Kuh Velocity. Bei manchen Unternehmen sogar Codezeilen, ja, ich meine dich, Microsoft. Warum das frustriert? Weil Story Points nicht funktionieren.

Das System belohnt Aktivität, nicht Wirkung. Dabei ist Wirkung das, was wir eigentlich wollen.

Schau dir den typischen Weg der Arbeit an. Ein Ticket wandert von To Do nach In Progress, dann ins Review, dann auf Done. Nur verbringt es die meiste Zeit mit Warten: auf Reviews, auf Entscheidungen, auf andere Teams, auf Releases. Gute Entwickler:innen spüren das sehr genau. Sie merken: Ich werde langsamer, obwohl ich ständig arbeite.

Das ist kein Dev-Problem, das ist ein Systemproblem

Wenn dann von außen Druck aufs Team kommt, ist das Verständnis irgendwann aufgebraucht. Das kann ich sehr gut nachvollziehen. Was Außenstehende dabei oft nicht sehen:

Es ist kein Zeichen von Unwillen. Kein „Die wollen nicht“. Und schon gar kein Generationenproblem.

Es ist ein Systemdesign-Problem.

Systeme, die auf Ticket-Abarbeitung optimiert sind, fragmentieren Verantwortung. Sie fördern Übergaben statt Zusammenarbeit. Sie trennen Denken von Umsetzen. Und sie optimieren die lokale Auslastung, statt auf den Gesamtfluss zu schauen. Wie das mathematisch nach hinten losgeht, steht in Warum am Freitag nichts fertig ist.

In so einem System wirken gute Entwickler:innen plötzlich schwierig. Dabei versuchen sie nur, professionell zu arbeiten.

Was stattdessen funktioniert

Die Lösung ist selten ein neues Tool oder ein anderes Framework, auch wenn die Transformationsbubble das gerne so sieht. Was hilft, ist bodenständig und naheliegend.

Was ist schlecht daran, gemeinsam am Board zu arbeiten, statt Tickets weiterzureichen? Ist eine User Story nicht genau das, eine Geschichte, die jemand erzählt?

Arbeit sollte so geschnitten werden, dass sie abschließbar ist. Spikes und die SPIDR-Methode helfen dabei, Code nicht nur zu entwickeln, sondern ihn beim Nutzer ankommen zu lassen.

Und Gespräche sollten wichtiger sein als Ticket-Texte. „Individuals and interactions over processes and tools“ aus dem agilen Manifest ist kein verstaubter Treppenwitz, sondern bitter ernst gemeint. Niemand sollte sich hinter Prozessen verstecken.

Sobald du über Probleme und Lösungen sprichst statt über Textfelder in Jira, ändert sich deine Rolle im Team.

Der Perspektivwechsel

Wenn gute Entwickler:innen keine Tickets abarbeiten wollen, dann nicht, weil sie schwierig sind, sondern weil sie Verantwortung ernst nehmen.

Vielleicht ist genau das das Signal: Nicht die Menschen sind das Problem, sondern das System, in dem sie arbeiten sollen. Stell im nächsten Refinement eine dieser drei Fragen und schau, was passiert. Wenn es unangenehm wird, hast du etwas gefunden.