Wie uns Git agil macht – oder auch nicht

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.

Bei meiner Arbeit mit Entwicklerteams bin ich auf die Meinung gestoßen, dass wir agil arbeiten, wenn wir so arbeiten, wie Jira es vorsieht. Ich bin nicht dieser Meinung. Für mich gilt in diesem Zusammenhang der Spruch: A fool with a tool is still a fool.

Ich glaube nicht, dass ein Tool ein Team agil machen kann. Allerdings kann die Art und Weise, wie Tools verwendet werden, Hinweise geben, wie es um die Agilität im Team bestellt ist. Das gilt auch für Tools, die ein agiler Coach oder Scrum Master oft nicht im Blick hat; das gilt vor allem für Scrum Master, die keinen technischen Hintergrund haben. An solchen Stellen müssen Entwickler die Führung übernehmen, damit sich das Team weiterentwickeln kann. Was ich damit meine, möchte ich an einem realen Beispiel erläutern.

In einem Team, mit dem ich gearbeitet habe, war es um die Zielerreichung und das Sprint-Commitment nicht gut bestellt. Das Team hat oft nicht fertigstellen können, was es zu Sprint-Beginn geplant hatte. Tickets sind von einem Sprint zum nächsten gewandert. Die Cycle-Time war hoch. Durchaus keine unüblichen Probleme; vom agilen Gedanken war nicht mehr viel zu sehen.

Wenngleich die Ursachen mehrschichtig waren, spielte Git eine zentrale Rolle. Es stellte sich nach und nach heraus, dass das Know-how im Umgang mit Git im Team sehr unterschiedlich stark ausgeprägt war. Es gab junge Entwickler, die schon immer mit Git gearbeitet haben, und es gab ältere Entwickler, die mit Systemen wie CVS oder Subversion gearbeitet hatten, bevor sie mit Git in Berührung kamen.

Letztere hatten sich nie intensiv mit Git auseinandergesetzt, und sie versuchten weitgehend so zu arbeiten, wie sie es mit den älteren Tools gewohnt waren. Bei Git fehlte ihnen insbesondere die Funktion des blockierenden Check-outs, um Merge-Konflikte zu vermeiden. Sie waren nicht gut darin, Merge-Konflikte aufzulösen. Wenn sie auftraten, vermieden die Entwickler die Konfliktauflösung und begannen die Arbeit am nächsten Ticket. Wie sich später herausstellte, war die Idee dahinter "die unangenehme Arbeit mache ich später mit allen Tickets in einem Schwung".

Zu viele Tickets im Endspurt

Dabei wurde ein Effekt nicht sichtbar: Je länger jemand mit dem Merging im Sprint wartete, umso größer war der Konflikt. Der Master-Branch entwickelte sich natürlich kontinuierlich weiter. Als dann kurz vor Sprint-Ende das Merging anstand, war die Aufgabe so groß geworden, dass es das Team bei vielen Tickets nicht mehr schaffte, sie im Sprint zu erledigen. Dass es als normal galt, dass unfertige Tickets in den nächsten Sprint rutschen ("so machen wir das immer"), gab es keinen Impuls, den Sachverhalt zu hinterfragen.

Eine Analyse der Durchlaufzeiten in Jira deckte die Problemursache nicht auf einfache Weise auf. Das lag daran,

1. dass die verwendeten Status (Spalten im Board) nicht differenziert genug waren, um erkennen zu können, "wo" ein langlaufendes Ticket feststeckt,
2. dass die Entwickler die betroffenen Tickets teilweise möglichst intransparent auf dem Board behandelten; vermutlich, um das Problem zu vertuschen, und
3. dass die Verwendung von Sub-Tasks in Jira die Problemursache zusätzlich verdeckte. Am Rande sei erwähnt, dass ich deshalb kein Fan von Sub-Tasks bin. Die Sub-Tasks verhinderten auch den Versuch, die Problemursache über Work-in-progress-Limits zu erkennen.

Zusammengefasst lag hier eine Situation vor, die es mir als agilem Coach sehr schwer machte, der Problemursache näherzukommen.

Am Ende war es einer der "Git-Muttersprachler", der erkannte, dass einige Teamkollegen große Defizite im Umgang mit Git hatten und deshalb Tickets lange liegen blieben. Er bot den Kollegen einige Stunden Pair Programming an. Dabei sah er, welches Know-how fehlte. Nachdem das Problem erkannt war, verlief die Lösungsfindung vergleichsweise einfach.

Das Team entschied sich, regelmäßige Git-Übungen durchzuführen. Es dauerte tatsächlich nur einen Sprint, bis das Problem verschwand. Das war möglich, weil die "Git-Junioren" die "Git-Senioren" um Hilfe beim Merging baten; bemerkenswert, weil die Junioren länger Software entwickeln als die Senioren. Es zeigte sich, dass Erfahrung nicht eindimensional ist und nicht notwendigerweise mit dem Alter einhergeht. Diversität und Anerkennung im Team sind wichtig, aber das sind Themen für einen anderen Blogbeitrag.

Fazit

Die Umstellung auf agiles Arbeiten ist keine Aufgabe für den Scrum Master oder Coach, sondern eine Umstellung, die das Team nur gemeinschaftlich schaffen kann. Wenn Entwickler ihre Führungsrolle annehmen, können sie manche Verbesserung erzielen, die sich dem einfachen Zugriff des Scrum Masters entziehen.

Tschüss. Stefan

(rme)