Muss ein Scrum Master etwas von Softwareentwicklung verstehen?

Inhaltsverzeichnis

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.

Heute versuche ich mich an einer Antwort auf die Frage. "Muss ein Scrum Master etwas von Softwareentwicklung verstehen?"

So wie die Frage gestellt ist, lautet meine Antwort: Nein. Aber erstens, es schadet auch nicht, wenn er oder sie etwas davon versteht, und es kommt zweitens darauf an, was man zu Softwareentwicklung zählt. Ich werde es an einem Beispiel erläutern.

Für eine erfolgreiche Zusammenarbeit im Team ist die interne Kommunikation essenziell. Also macht ein Scrum Master einen guten Job, wenn er auf die Kommunikation achtet und gegebenenfalls mit dem Team daran arbeitet. Ich nehme an, diese Aussage ist allgemein genug formuliert, dass jede Leserin und jeder Leser zustimmt.

Spannend wird es bei der Frage, wo Kommunikation in einem Software-Team stattfindet. Zu den trivialen Antworten gehören Meetings wie Daily Scrum, Review, Retrospektive, Refinement und so weiter.

Und was ist mit Pull Requests?

Pull Requests sind ein wichtiger Teil der Teamkommunikation. Ich habe mit Teams gearbeitet, die in Meetings ganz friedlich und handzahm waren, sich aber in Pull Requests wahre Schlachten geliefert haben; ein einziges Hauen und Stechen. Die “guten” Programmierer gegen die “schlechten” Programmierer. Blaming und Fingerpointing wie aus dem Lehrbuch. Da wurde nichts, was auch nur ein My unter “Perfekt” war, akzeptiert. (Dass Perfektionismus einer der erstaunlich vielen Wege in die Hölle ist, ist ein Thema für einen anderen Blogartikel.) Pull Requests haben sich zum Teil über Wochen gezogen.

Die Folge? Mundtot gemachte Teammitglieder, die zu keiner eigenständigen Bewegung mehr in der Lage waren. Ihren Fokus richteten sie auf Selbstschutz, nicht mehr auf produktive Arbeit. Commitments im Planning? Gab es nur noch äußerst selten.

Was hat das mit dem Scrum Master zu tun?

Wenn der Scrum Master die Auffassung vertritt, dass er den Quellcode der Software zu meiden hat, wie der Teufel das Weihwasser, verpasst er diesen Teil der Teamkommunikation. Da das Niedermachen eines anderen im etwas geschützteren Raum des Pull Request (Schreiben statt Sprechen, asynchron statt synchron, nicht von Angesicht zu Angesicht) leichter ist als in den Teammeetings, kann sich dieses negative Verhalten lange wie ein Schwelbrand entwickeln. Wenn die Flammen zutage treten, ist es (zu) spät und es brennt im sprichwörtlichen Sinn die Hütte; und der Scrum Master wundert sich.

Wenn ich mit einem Software-Team arbeite, schaue ich mir auch gelegentlich ein paar Pull Requests an. Kürzlich wollte ich das bei einem Kunden machen und war verblüfft, dass ich keinen Zugriff hatte. Es gab nur eine begrenzte Zahl von Lizenzen für das verwendete System, und für den Scrum Master hatte man keine Lizenz gekauft. Zu kurz gedacht.

Was kann ich als Entwickler tun?

Eine Lösung ist einfach: Lade den Scrum Master zu (einigen) Pull Requests ein. Wer in einer Firma arbeitet, die Lizenzkosten scheut, sollte sich dafür einsetzen, das Geld auszugeben. Was immer geht: Bearbeite die Pull Requests wie im Peer Programming gemeinsam mit dem Scrum Master.

Tschüss. Stefan

(rme)