Warum Arbeit im Chat landet statt im Ticket

Ein Bug kommt per Teams rein. Eine neue Anforderung fällt als Nebensatz im Daily. Die Entscheidung, welche Variante gebaut wird, steht in einem Slack-Thread mit 40 Nachrichten. Drei Wochen später fragt jemand, wer das eigentlich wollte. Im Ticket steht nichts dazu. Kommt dir das bekannt vor? Mir schon...

Was ich denke: Arbeit landet im Chat, weil der Chat bequemer und sicherer ist als das Ticket und mit Disziplin bekommst du das nicht weg. Du musst das Ticketschreiben leichter machen und die Angst rausnehmen.

Damit kein Missverständnis entsteht: Ich bin ein großer Fan von Gesprächen. Face2Face vor Video, Video vor Telefon, Telefon vor Chat. Wer redet, klärt mehr als jedes Formular. Reden ist also nicht das Problem. Das Problem ist, dass das Ergebnis nie im Ticket ankommt.

Warum der Chat gewinnt

Der erste Grund ist banal. Im Chat tippst du eine Zeile und drückst Enter. Für ein Ticket wählst du Projekt, Vorgangstyp, Komponente, füllst sieben Pflichtfelder aus und überlegst, ob das jetzt eine Story oder ein Task ist. Wer es eilig hat, nimmt den kurzen Weg, und die Kosten trägt jemand anders, nämlich der, der in drei Wochen danach sucht.

Der zweite Grund wiegt schwerer. Ein Ticket ist öffentlich. Es hat einen Assignee, Zeitstempel und eine Historie jedes Statuswechsels. In einem Team, in dem Fehler Konsequenzen haben, schreibt niemand „Ursache war mein fehlender Null-Check“ in einen Kommentar, den der Bereichsleiter lesen kann. Die Direktnachricht an die Kollegin fühlt sich sicherer an. Mit Faulheit hat das wenig zu tun. Wer so handelt, reagiert ganz vernünftig auf ein Umfeld, in dem ein ehrlicher Kommentar gegen einen verwendet werden kann.

Drittens weiß oft niemand, was überhaupt ins Ticket gehört. Ein leeres Formular mit zwölf Feldern schüchtert ein, und bevor man etwas Falsches reinschreibt, ruft man lieber kurz rüber. Oder es ist viel zu anstrengend, das alles auszufüllen.

Viertens ist das Tool überladen. Ein Jira-Workflow mit elf Status, Pflichtfeldern beim Übergang und drei Klicks pro Kommentar erzieht Leute dazu, das Ticket nur noch anzufassen, wenn es sein muss. Das Board zeigt dann irgendwann einen Stand, den es so seit Tagen nicht mehr gibt, und alle wissen es.

Und dann gibt es noch das Management, das Chat-Gewusel für agil hält. Viel Bewegung im Kanal sieht nach Tempo aus. Agiles Arbeiten lebt aber davon, dass Feedback die nächste Arbeit verändert, und genau dafür muss Feedback irgendwo ankommen, wo die nächste Arbeit es findet. Eine Entscheidung, die im Slack-Verlauf nach oben weggescrollt ist, verändert gar nichts mehr.

Was dagegen hilft

Die Mittel, um hier besser zu werden, sind einfach.

Das Ergebnis zurückschreiben. Wer das Gespräch geführt hat, schreibt danach eine Zeile ins Ticket: was entschieden wurde, von wem, wann und warum. Das dauert eine Minute. Den Chat-Verlauf kopiert dafür niemand ins Ticket. Wie so ein Kommentar aussieht, steht im Artikel Was gehört in ein Ticket?.

Das Ticket schlank machen. Drei Felder reichen für die meisten Aufgaben: Warum, Was, Acceptance Criteria. Wenn ein Ticket so schnell geschrieben ist wie eine Chat-Nachricht, fällt der wichtigste Grund für den Umweg weg.

Tickets beschreiben Arbeit, nicht Menschen. Kommentare handeln vom System: „Deployment-Skript prüft die Umgebung nicht“, nicht „Max hat auf Prod deployt“. Und es gibt keine Auswertungen über einzelne Personen, keine Statistik, wer wie viele Tickets geschlossen hat. Diese Zusage muss von der Führung kommen, denn ein Team kann sich schlecht selbst versprechen, dass es nicht kontrolliert wird.

Ausmisten. Ein Status lohnt sich nur, wenn er ändert, wer als Nächstes handeln muss. „Review gestartet“ und „Review fertig“ sind kein eigener Status. Jedes Feld, das niemand auswertet und für das keiner in einem Satz sagen kann, wozu es eigentlich da ist, fliegt raus.

Ich bin hier selber schuldig. Ich kenne es von mir selber nur zu gut. Eine Slack-Nachricht ist schneller als ein Jira-Ticket. Aber ich ärgere mich auch jedes Mal über mich, denn in der Regel muss ich später den Status nachsehen. Und den finde ich natürlich nicht. Weiterhin ist es klar, dass das Team sich mit der Koordination einer Slack-Nachricht viel schwerer tut als in Jira. Mir sind so auch schon Aufgaben verloren gegangen. Und deswegen versuche ich immer wieder lieber die fünf bis zehn Minuten für ein ordentliches Ticket zu investieren.

Chat bleibt erlaubt

Rückfragen, „schau mal kurz“, gemeinsames Debuggen, die Absprache, wer heute Mittag den Build beobachtet: Das gehört in den Chat und soll dort bleiben. Niemand muss ein Ticket anlegen, um eine Frage zu stellen.

Kritisch wird es bei allem, was jemand in sechs Monaten suchen wird. Neue Arbeit, geänderter Umfang, eine Freigabe, die Ursache eines Bugs. Im Chat haben die Abwesenden das nie gelesen, und wer im Thread einfach nicht widersprochen hat, gilt plötzlich als einverstanden, obwohl er nur nicht reingeschaut hat. Im Ticket kann jeder nachlesen und Einspruch erheben, auch die Kollegin, die an dem Tag Urlaub hatte.

Die Prüffrage ist einfach: Versteht jemand, der nicht dabei war, später, was entschieden wurde und warum? Wenn nein, gehört eine Zeile ins Ticket.

Fang morgen nach dem Daily an

Nimm dir nach dem nächsten Daily zwei Minuten. Alles, was dort entschieden oder zugesagt wurde, kommt als eine Zeile in das passende Ticket. Mach das eine Woche lang, ohne es groß anzukündigen, und schau dann, wie oft noch jemand fragt, wer das eigentlich wollte.

Feedback oder Widerspruch? Schreib mir auf Mastodon an @nobsagile oder per Mail an nobsagile@gmail.com.