“Ich bin zu alt für sowas”
Balin
Manche Probleme werden von den Kollegen nur erkannt, wenn wir für sie drastische Vergleiche entwerfen. Ohne die Bilder einer anderen Gefahr vor dem inneren Auge, werden organisatorische Defizite häufig mit einem Achselzucken hingenommen.
Wer kennt ihn nicht Smaug den Drachen? In meiner Jugend wussten tatsächlich nur die Liebhaber von Sagen und phantastischen Geschichten von ihm, viele von ihnen genauso computerbegeistert wie der Autor. Seitdem der Hobbit nun, in viel zu vielen Teilen, verfilmt wurde, ist die Geschichte von Smaug ins kollektive Gedächtnis gewandert.
Smaug, der letzte der Urulóci, überfiel die Zwergenstadt im einsamen Berg und tötete ihre Bewohner. Dann raffte er alle Schätze zusammen und legte sich auf ihnen zur Ruhe. Immer wieder flog er danach hinaus und plünderte die Umgebung, sodass sich eine Einöde um den Berg bildete, in die sich kein Mensch oder Tier mehr verirrte.
Nach vielen Jahren kam der Hobbit Bilbo in die Höhle und stahl dem Drachen einen Pokal aus dessen immensem Schatz. Als der Drache dies bemerkte wurde er furchtbar böse und als der Hobbit ihm am nächsten Tag erneut ärgerte und ihm entkam, fasste der Drache den Entschluss eine Stadt der Menschen in der Nähe zu verwüsten. Zu seinem Leidwesen kannten die Menschen durch Bilbo seine Schwachstelle und konnten ihn beim Angriff töten.
Die meisten Leser werden nun vermuten, dass es in der eigenen Firma keinen verborgenen Drachen Hort geben sollte, aber leider ist diese Annahme falsch. Es gibt eine ganze Reihe von Schätzen, Einöden und Drachen. In unserem Beispiel heißt der Drache Issue-Tracking.
Das Issue-Tracking genießt in der Regel ein hohes Ansehen, kanalisiert und organisiert es doch Fehlermeldungen und Feature-Wünsche zu einem Produkt. Es gibt den Verantwortlichen die Möglichkeit Anforderungen und Fehler zu analysieren, priorisieren, beauftragen und am Ende zu prüfen.
Aber schon Theophrastus Bombast von Hohenheim wusste “Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis machts, dass ein Ding kein Gift sei.” und so ist es auch mit dem Issue-Tracking bestellt. Es verwandelt sich in ein Monster, wenn die Anzahl der verwalteten Einträge dauerhaft steigt.
Üblicherweise kommt es zu einem Anstieg von Einträgen, wenn mehr rein kommt, als rausgeschafft werden kann. Zu Beginn eine schöne Sache, aber nach einiger Zeit häufen sich die Beschwerden, weil immer mehr Leute auf irgendetwas warten. Dann kann das Gefühl entstehen, dass die Organisation auf der Stelle tritt. Das Gefühl ist natürlich falsch, denn alle arbeiten mit Hockdruck an ihren Aufgaben. Diese Situation kann den Drachen anlocken.
Denn nun wird eifrig in den Issue Listen priorisiert und die Arbeit der Mitarbeiter stärker organisiert und strukturiert. Zusätzliche Arbeiten, die von den Mitarbeitern häufig nebenbei erledigt wurden, werden von ihnen nun, aus Selbstschutz, auch an das Issue-Tracking gemeldet und müssen zusätzlich verwaltet und priorisiert werden. Die Geschwindigkeit, mit der neue Issues entstehen, wird größer. Auch das Priorisieren und Verwalten der Issues wird immer schwieriger und langwieriger. Vorschläge, irgendwelche Themen nicht mehr anzugehen und ihre Issues zu löschen, werden aber weiterhin abgelehnt, denn alles ist irgendwie wichtig.
Irgendwann kommt die Idee, dass vielleicht die Schwächen in der Software das Problem verursachen. Und die Entwickler werden gebeten, Lösungen zu suchen um diese Schwachstellen zu finden. Leider werden diese Lösungen als Issues in das Issue-Tracking gemeldet. Mit einem Drachen auf dem Gold, kommt es nun zum Backlog-Unten.
Vor vielen Jahren entdeckten wir Software-Entwickler in einer längst vergessenen Firma eine unangenehme Gesetzmäßigkeit, die wir damals Backlog-Unten nannten. Wichtige Entwicklerthemen wurden als Storys in das Backlog aufgenommen und priorisiert. Das ein oder andere Thema wurde sofort angegangen, aber der Rest der Themen versank langsam und unaufhörlich im Backlog. Selbstverständlich gab es wichtige Gründe, kundengetriebene Themen vorzuziehen, aber nach längerer Zeit befanden sich alle Entwicklerthemen ganz unten im Backlog und noch schlimmer, es gab keine neuen Entwicklerthemen. Die Entwickler hatten aufgehört sich am Erstellen des Backlogs zu beteiligen. Damit begann sich die Einöde um den Schatz herum auszubreiten. Die Qualität der Software stagnierte und Entwickler wanderten ab.
Leider gibt es kein Erfolgsrezept gegen den Drachen, denn die Gründe für einen Goldschatz im Issue-Tracking hat vielfältige Gründe. Eine genaue Analyse der Engpässe in der Bearbeitung der Issues ist nötig, denn manchmal ist nicht die eigene Software das Problem, sondern die Arbeitsabläufe in der Organisation, oder die Wissensverteilung, oder die Qualität der Issues, die Anzahl oder die intrinsische Motivation der Mitarbeiter. Und natürlich ist es nie einer der Gründe allein, sondern ein sehr individuelles Gemisch für eine Organisation und ihren einzelnen Strukturen.