Augen auf bei Betriebsblindheit in Softwareteams

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.

Seid Ihr auch betriebsblind? Blöde Frage, oder? Wenn man das wüsste, wäre man ja nicht betriebsblind. Also kann die Antwort nur lauten: Es könnte sein.

Mir begegnet Betriebsblindheit bei Softwareteams in Form von Arbeitsvereinbarungen oder Working Agreements. Wenn sie jedem Teammitglied bekannt sind, am besten gut dokumentiert und tatsächlich praktiziert werden, sind sie wertvoll und nützlich. Dann gibt es aber auch noch Vorgehensweisen, Regeln und Konventionen, die so sind, weil sie immer so waren. Oder der ursprüngliche Grund ist in Vergessenheit geraten. Beliebt ist auch die unreflektierte Übernahme von Best Practices, die man irgendwo aufgeschnappt hat.

Ein Beispiel meiner eigenen Betriebsblindheit: Im Jahr 2010 hat Vincent Driessen einen Beitrag mit dem Titel “A successful Git branching model” geschrieben. Sein Vorschlag hat den Namen gitflow bekommen. Ich habe den Artikel kurz nach Veröffentlichung gelesen und war sofort überzeugt. Wir haben die Vorgehensweise damals in unser Team übernommen und es hat uns weitergebracht.

Auf den Kontext kommt es an

In den folgenden Jahren habe ich gitflow hier und da empfohlen. Manche Teams haben es übernommen, andere nicht. Das ist normal. Allerdings ist eine Sache oft außer Acht geblieben: Welches Problem will man eigentlich lösen? Und wie gut gelingt das mit der vorgeschlagenen Vorgehensweise überhaupt?

Kurz gesagt: Rückblickend vermute ich, dass gitflow durch meine Empfehlung zu oft und manchmal aus keinem logischen Grund umgesetzt wurde. Erst als mir ein Entwickler mal sagte, dass gitflow für sein Team keine gute Wahl sei, weil … ist mir aufgefallen, dass ich etwas, das in einer bestimmten Umgebung gut funktioniert hat, wiederholt und unreflektiert in neuen Kontexten verwendet oder als Best Practice empfohlen habe; heute glaube ich nicht mehr an Best Practices.

Das gleiche Prinzip habe ich bei einigen Kunden gesehen. Ich vermute, es ist menschlich, und es ist im Allgemeinen eine gute Idee, erprobte und erfolgreiche Vorgehensweisen beizubehalten. Never change a winning team lautet nicht umsonst eine Redewendung. Andernfalls würde man jeden Tag alles infrage stellen und nichts mehr schaffen. Dummerweise ändert sich manchmal der Kontext und die sogenannte Best Practice ist nicht mal mehr eine Good Practice.

Hinterfragen hilft

Damit das nicht passiert, empfehle ich Frühjahrsputz bei Arbeitsvereinbarungen zu betreiben. Soll heißen: In größeren Abständen von einigen Monaten oder vielleicht einem Jahr sollte ein Team bekannte und unsichtbare Working Agreements hinterfragen:

• Wie arbeiten wir zusammen?
• Wie sieht Wertschöpfung in unserem Team aus?
• Wie gelangen Anforderungen, Wünsche, Storys, Ideen mit unserer Hilfe ins Produkt?
• Welche Absichten stecken dahinter und erreichen wir die Ziele überhaupt (noch)?

Es dürfen auch gerne sehr konkrete Fragen sein, die natürlich von Team zu Team verschieden sind, exemplarisch:

• Wie behandeln wir Hotfixes? Warum auf diese Weise? Welches Ziel wollen wir damit erreichen und erreichen wir es? Auf welche andere Weise könnten wir auch zum Ziel kommen? Welcher Weg ist der bessere?
• Wir arbeiten seit fünf Jahren kompromisslos testgetrieben. Warum haben wir das eingeführt? Funktioniert es? Brauchen wir es heute noch? Was wäre, wenn wir die Regel lockerten?
• Analog: Welche Coding Rules haben wir? Warum? Wozu? ...

Manchmal fällt bei solchen Fragen auf, dass es für einzelne Working Agreements kein gemeinsames Verständnis im Team gibt; also gibt es eigentlich kein Agreement. Dann geht es zunächst nicht um die Frage, was ist gut, was ist schlecht, sondern viel grundlegender um: Wie machen wir als Gruppe das eigentlich?

Man braucht keinen Teamleiter, Manager oder Coach, um diese Fragen zu stellen und die Working Agreements auf den Prüfstand zu stellen. Es genügt eine engagierte Entwicklerin oder ein engagierter Entwickler und los geht’s. Man schlägt das Thema im Daily vor oder stellt einen Termin in den Kalender ein. Wenn man eine Formulierung wählt, die neugierig macht oder gar provokant ist (“Nie wieder Test-driven” oder “ab jetzt nur noch Test-driven”), sind Reaktionen und Beteiligung wahrscheinlicher.

Lessons Learned

Der Dialog im Team sollte feststehende Meinungen und etablierte Glaubenssätze hinterfragen. Auch das kann man vom zuvor genannten Beispiel meiner eigenen Betriebsblindheit lernen:

Während gitflow zu seiner Zeit sehr beliebt wurde, gilt es offensichtlich Jahre später pauschal als schlecht. Wenn man heute nach dem Begriff googelt, findet man unter anderem einen Artikel von Atlassian, in dem es einleitend heißt: “Gitflow ist ein veralteter Git-Workflow der einst eine disruptive und neuartige Strategie für die Verwaltung von Git-Branches darstellte.”

Ich kann mich nicht daran erinnern, dass gitflow jemals das Adjektiv disruptiv verdient hätte; aber für ein wenig Buzzword-Bingo taugt die Vokabel immerhin. Kritischer sehe ich die Einordnung als veraltet und früher neuartig. Welche Rolle spielt das Alter? Vielleicht gibt es auch 20 Jahre später Teams und Aufgaben, die hervorragend mit gitflow arbeiten können. Es geht nicht um alt oder neu. Es gibt keine Best und keine Worst Practices. Vielmehr geht es darum, wie gut etwas für den individuellen Anwendungsfall und -kontext geeignet ist. Das kann jedes Team am besten selbst beurteilen und eine früher getroffene Verabredung in größeren Abständen hinterfragen. Vor allem dann, wenn Entscheidungsgründe und -kontext in Vergessenheit geraten sind. Auf zum Frühjahrsputz!

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Den Podcast gibt es bei Spotify, Deezer, Amazon Music, Apple Podcasts und auf kutura.digital. Dort findet man unter anderem Workshops, die die Themen des Blogs adressieren.

(rme)