Warum gute Entwickler:innen keine Tickets abarbeiten wollen

Dieser Artikel ist Teil des Survival-Kits für Entwickler. 

Entwickler sind keine Ticket-Automaten, sondern Problemlöser. Lerne, wie du dir deine Autonomie zurückholst und wieder echten Wert lieferst, statt nur Jira-Status zu schieben.

Wenn mich in einem Refinement oder in einem Daily jemand aus dem Dev Team fragt, was mit dem Ticket denn erreicht werden soll, dann freu ich mich jedes mal auch wenn ich weiß, dass ein bisschen mehr Arbeit vor mir liegt, diese Frage zu beantworten. Ich weiß aber auch, warum der Entwickler mich das fragt.

Anscheinend ist eine solche Frage aber nicht bei allen Unternehmen beliebt. Anscheinend ist bei vielen Unternehmen 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 = 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.

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

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

Was gute Entwickler:innen eigentlich antreibt

Gute Entwickler:innen wollen meiner Meinung nach verstehen, warum etwas gebaut wird. Sie wollen Entscheidungen treffen dürfen, statt nur Anweisungen umzusetzen. Sie sind sehr interessiert an Feedback - vor allem von echten Usern des Systems. Und sie wollen Dinge fertig machen und nicht nur weiterreichen.

Sie optimieren nicht auf „busy“, sondern auf „done“. Und 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. Das kann man oft an folgenden Symptomen sehen.

Tickets werden übergeben statt gemeinsam gelöst. Es gibt keine Zeit für eine Diskussion oder ein Planning oder eine Architektur. 

Die Verantwortung endet an Spalten- oder Zustandsgrenzen. Eine Rückfrage zu einem Ticket ist eher unerwünscht. Ein Ticket ist nicht durch das Gespräch Ready geworden, sondern weil es in Up Next liegt. Für genau diesen Punkt schau gerne in einen Deep Dive von mir.

Der Kontext geht bei jeder Übergabe verloren. Dadurch dass es nicht erwünscht ist, über Tickets zu reden oder nachzudenken (weil es ja angeblich effizienter ist), geht auch jedes mal, wenn ein Ticket von einer Hand in die andere geht, Kontext verloren.

Und dann kommt natürlich noch das hier dazu. Erfolg wird daran gemessen, wie viele Tickets „durchgezogen“ wurden. Die heilige Kuh "Velocity". Bei manchen Unternehmen sogar Code-Zeilen (ja, ich meine dich, Microsoft). Warum frustriert das? Weil Story Points nicht funktionieren.

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

Schauen wir uns den typischen Flow von Arbeit an. Ein Ticket wandert von „To Do“ zu „In Progress“ zu „Review“ zu „Done“. So weit so gut. Doch sehr sehr oft verbringt ein Ticket mit Warten.

Warten auf Reviews. Warten auf Entscheidungen. Warten auf andere Teams. Warten auf Releases. Gute Entwickler:innen spüren das sehr genau. Und 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 auf das Team ausgeübt wird, haben Entwickler:innen oft kein Verständnis mehr - und das kann ich sehr gut nachvollziehen! Was oft von Außenstehenden nicht verstanden wir:

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

Es ist ein Systemdesign-Problem.

Systeme, die auf Ticket-Abarbeitung statt auf die Arbeit optimiert sind, neigen dazu, die Verantwortung zu fragmentieren. Diese Systeme fördern Übergaben statt Zusammenarbeit zwischen Menschen. Sie trennen Denken von Umsetzen. Sie optimieren die lokale Auslastung statt auf den Gesamtfluss zu schauen.

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 "Digitale Transformationsbubble" dies gerne so sieht.

Was hilft, sind meist sehr bodenständige Dinge, die eigentlich sehr naheliegend sind.

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

Arbeit sollte so geschnitten werden, dass sie abschließbar ist. Spike Stories und die SPIDR-Methode sind bewährte Ansätze, die extrem helfen, Code nicht nur zu entwickeln, sondern ihn dem Nutzer zuzuführen.

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.

Wenn wir oben über Flow sprechen, dann habe ich das Gefühl, dass zwar Entwickler:innen genau wissen, was das bedeutet, aber das Umfeld sieht es nicht oder will es nicht wahr haben.

Mein Tipp: Wenn du verstehen willst, warum du trotz ständiger Arbeit nicht fertig wirst, schau dir meine Flow Physics Simulation an. Da siehst du live, wie WIP-Limits dein Team beschleunigen.

Kurz gesagt: Es sollte für alle erstrebenswert sein und bleiben, dass wir weniger in Ticket-Logik sondern mehr in Problemlöse-Logik denken sollten und unsere Systeme um diese Logik bauen sollten.

Der Perspektivwechsel

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

Und vielleicht ist genau das ein Signal, dass nicht die Menschen das Problem sind, sondern das System, in dem sie arbeiten sollen.

Rüste dich für den Wandel
Dass du keine Lust auf bloße Ticket-Abarbeitung hast, ist ein Zeichen von Professionalität. Um das System zu ändern, brauchst du die richtigen Werkzeuge in deinem Alltag:

🎯 Schritt 1 (Klarheit): Refinement meistern: Tickets richtig schneiden
⏰ Schritt 2 (Fokus): Das Daily zurückerobern: Taktik statt Beichte
🎯 Schritt 3 (Schutz): DoD: Dein Schutzschild für Qualität
🏠 Zurück zur Übersicht: Das Agile-Survival-Kit für Entwickler

Kennst du das Gefühl?
Schreib mir auf Mastodon oder teile diesen Text mit deinem Team – oft ist man nicht allein mit diesem Frust!