Die oberste Direktive und ihre praktischen Konsequenzen für Softwareteams

Moin.

Die oberste Direktive für Retrospektiven hat Norman Kerth 2001 in seinem Buch „Project Retrospectives“ formuliert:

„Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.“

„Unabhängig davon, was wir herausfinden, müssen wir verstehen und wirklich glauben, dass jeder das Beste getan hat, was er oder sie in Anbetracht der damaligen Kenntnisse, seiner oder ihrer Fähigkeiten und Fertigkeiten, der verfügbaren Ressourcen und der gegebenen Situation tun konnte.“

Die oberste Direktive ist insbesondere im Bereich agiler Softwareentwicklung bekannt geworden. Das ist bemerkenswert, weil in Kerths Buch die Worte „agil“ oder „Scrum“ nicht vorkommen.

Ich habe die Direktive oftmals in eine erste Retrospektive eingebracht, die ich mit einem neuen Team durchgeführt habe. Die Reaktionen fielen in den Teams sehr unterschiedlich aus. Da war auch schon einmal jemand dabei, der verächtlich schnaubte. Darauf angesprochen bekam ich manchmal als Antwort eine rhetorische Frage der Art: „Das meinst Du doch nicht ernst, oder?“ Darin schwingt eine klare Aussage mit: Die Leistung einer anderen Person ist nicht ausreichend.

In so einem Moment lasse ich mich nicht auf eine Diskussion über die Leistung anderer ein. Vielmehr halte ich folgende Fragen mit entgegengesetzten Aussagen für weiterführend:

1. Angenommen, die fragliche Person hat ihre beste Leistung geliefert, und ich bin mit dem Ergebnis nicht zufrieden. Was folgt für mich daraus?
2. Angenommen, die fragliche Person hat nicht ihre beste Leistung geliefert. Wie gehe ich damit um?

Fangen wir mit dem zweiten Punkt an: Jemand bringt nicht seine beste Leistung. Welche Gründe fallen mir ein?

Erstens: Die Kollegin oder der Kollege ist krank, hat irgendwelche persönlichen Probleme oder ist aus einem anderen Grund nicht in der Lage, seinen Fertigkeiten entsprechend zu arbeiten. In einem „gesunden“ Team ist die eigene Reaktion ganz einfach: Ich spreche die Person an und biete ggf. Hilfe an.

Zweitens: Die Kollegin oder der Kollege arbeitet absichtlich schlecht. Dafür gibt es ein Wort: Sabotage. Das ist einer der äußerst seltenen Fälle, in denen ich disziplinarische Maßnahmen für sinnvoll halte.

Damit komme ich zurück zum ersten Punkt: Wer seine beste Leistung liefert, kann dafür nicht kritisiert werden. Worin sollte die Kritik bestehen? Wenn ein Kleinkind nicht Rad fahren kann, gibt es daran nichts zu beanstanden. Wenn ein 95-jähriger Mensch keinen Marathon laufen kann, wer will es ihm verübeln (am Rande: wie viele 20-Jährige schaffen die Strecke?). Wer krank ist oder private Probleme hat, wird nicht seine (theoretischen) 100 Prozent leisten können.

Wenn sich das negativ auf das Teamergebnis auswirkt, sehe ich alle Mitglieder gemeinsam in der Verantwortung – und in der Pflicht, konstruktiv dagegen vorzugehen. Teaminterne Kritik an einzelnen Personen gehört nicht dazu. Stattdessen sehe ich Folgendes als vernünftige Leitlinie an:

• Wenn ich als Entwickler feststelle, dass ein anvisiertes Ziel wie das Sprintziel in Gefahr gerät, spreche ich es offen an, sobald ich es erkenne.
• Ich vermeide Schuldzuweisungen (Blaming and Finger-Pointing).
• Wenn ich selbst nicht über die Fertigkeiten verfüge, das Defizit zu behandeln, weil es beispielsweise Probleme in einer Komponente gibt, die in einer Programmiersprache geschrieben ist, die ich nicht beherrsche, geht eins immer: Ich biete Hilfe an. Dabei kann es sich um Pair Programming handeln, oder ich stelle mich als Sparringspartner zur Verfügung.

Im Endeffekt kann man alles auf zwei Punkte zurückführen. Aus der obersten Direktive folgt für die Zusammenarbeit im Team:

• Ich verzichte auf Schuldzuweisungen. Die Suche nach Problemursachen ist natürlich notwendig, sowohl um eine geeignete Lösung zu finden, als auch um zukünftige Probleme der gleichen Art zu vermeiden oder früher behandeln zu können.
• Ich biete Hilfe an, um Lösungen zu finden. Dabei spielen Zuständigkeiten keine Rolle. Ein Team erreicht oder verfehlt Ergebnisse und Ziele gemeinsam.

Nach einem Problem oder Scheitern die handelnde Person zu benennen und das nicht als Blaming oder Finger-Pointing zu verstehen, ist für die meisten Teams schwierig. Genau in solchen Fällen hilft es, im Team offen über die oberste Direktive zu sprechen.

Erst lesen, dann hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie (meist) mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Zur obersten Direktive habe ich gleich zwei Podcast-Folgen im Angebot; im ersten Beitrag gehe ich kurz darauf ein, was jeder selbst tun kann, wenn es an anderer Stelle im Team klemmt; im zweiten Beitrag gehe ich mit einem Gast in die Tiefen der obersten Direktive. Wer auch daran interessiert ist, findet den Podcast bei Spotify, Deezer, Amazon Music, Apple Podcasts und auf kutura.digital. Dort finden sich auch Workshops, die sich den Themen des Blogs widmen.

(rme)