Warum Magnete besser sind als Jira

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

In den guten alten Zeiten, als agile Teams an einem Ort zusammengearbeitet haben, bestanden Boards aus Tafeln, die man nicht nur beschreiben, sondern auch mit Magneten nutzen konnte. Tickets waren aus Papier und für jedes Teammitglied gab es einen (und nur einen) Magneten, auf den man ein Foto der jeweiligen Person geklebt hat.

Von Zeit zu Zeit stand jemand auf, verschob eine Karte in eine andere Spalte, zog ein Ticket aus “To do” hinüber zu “In progress” und – vor allem – fixierte die Karte mit dem eigenen Magneten. Allen war klar, wer gerade woran arbeitet. Ein Blick genügte. Karten in “To do” waren Aufgaben fürs Team, jeder konnte sich frei bedienen.

Heute arbeiten Teams mit Jira, und manche glauben, die Entsprechung für den Magneten wäre das Feld “Assignee”. Weit gefehlt. Was ich heute beobachte, sieht exemplarisch so aus:

• Team A weist die Tickets bereits im Sprint-Planning den Personen zu. Manchmal hat jeder Entwickler schon im Planning “seine” zehn Tickets.
• In Team B stellt sich ein Entwickler “seinen” Sprint schon vor dem Planning zusammen; nach wenigen Minuten sagt er im Planning mit einem Unterton, der an “macht, was ihr wollt, ich bin raus” erinnert, etwa “Also, mein Sprint ist schon voll.”
• Team C hat das mit den crossfunktionalen Teams so verstanden, dass Arbeitspakete nach individuellen Skills der Teammitglieder geschnitten werden. Und dann kann man schon im Refinement den Assignee zuweisen.

Insgesamt kann ich sagen, dass ich seit Jahren ausnahmslos Teams sehe, in denen die Menschen Dutzende von Magneten (aka Assignee) besitzen. Oder, wie ich finde, sie werden von den Magneten besessen.

An unzähligen Stellen prangt das eigene Konterfei und sagt: “Arbeite schneller in der Feature-Factory, das Fließband läuft und läuft und die nächsten Tickets rollen schon auf Dich zu!”

Sprint-Ziele, Teamarbeit, werterzeugende Arbeit? Für den Unsinn hab ich keine Zeit, ich muss ja implementieren.

Wer raus will aus der Feature-Factory, sollte folgendes probieren; ein Kombinieren der Vorschläge ist erlaubt:

• Jede Person darf zu jedem Zeitpunkt maximal einmal als Assignee in Erscheinung treten.
• Assignees gibt es nur in den Spalten, in denen wirklich gearbeitet wird (“In progress”, “Pull request”, “In testing” oder ähnlich); keinesfalls in “To do” oder früher.

Für die beiden Vorschläge braucht es Disziplin. Die ist zwar super, funktioniert aber meist nicht, sobald Menschen beteiligt sind. Deshalb hier der ultimative Tipp:

Man lösche das Feld “Assignee” in Jira. Radikal? Das kommt darauf an, wozu es eingesetzt wird. Wenn es nur dazu dient, das Fließband in der Feature Factory zu füllen, dann: Weg damit!

Tschüss. Stefan

(rme)