Wunsch vs. Wirklichkeit, Teil 2: Unstimmigkeiten im Team

Vor welchen Herausforderungen stehen Softwareteams in den unterschiedlichen Organisationen? Wie sehen diese Herausforderungen aus, die der regelmäßigen Lieferung und hohen Qualitätsstandards der Software im Weg zu stehen scheinen?

Im vorherigen Blogpost meiner 3-teiligen Blogpost-Serie habe ich den ersten Grund Fehlendes (Fach)Wissen innerhalb des Teams erläutert.

Neben dem Fachwissen braucht es aber noch eine weitere sehr wichtige Zutat, damit Softwareteams dauerhaft gute Ergebnisse liefern können.

Vielleicht erkennt der ein oder andere eine ähnliche Herausforderung innerhalb seiner Organisation wieder und bekommt durch die Lösungsansätze neue Impulse für sein Umfeld.

Drei Gründe, warum Softwareteams es nicht schaffen, regelmäßige Lieferung und hohe Qualität einzuhalten

Im zweiten Teil der Serie beschäftigen wir uns mit einem Team-internen Thema:

Grund 2: Das Softwareteam versteht sich nicht gut

Neben den fachlichen und methodischen Skills aus dem ersten Blogpost dürfen natürlich auch die zwischenmenschlichen Aspekte nicht außer Acht gelassen werden. Welcher direkte Zusammenhang zwischen der Stimmung, bzw. dem Vertrauen im Team und dessen Outcome bzw. Performance besteht, wurde bereits in einem anderen unserer Blogposts beschrieben. Ich möchte nun anhand von Beispielen uns der Praxis erläutern, wie sich diese Beziehung unmittelbar auf die Qualität und Lieferfähigkeit auswirken können.

Hero Programing

Was in Comics und Superhelden-Serien ganz gut funktioniert – nämlich dass ein einzelner „Superheld“ losfliegt und quasi im Alleingang die Situation löst – ist in einem Softwareteam ein großes Anti-Pattern. Hero Programming, oder auch das Hero Anti-Pattern, bezeichnet ein Verhalten, dass das ganze Team sowie dessen Sprintziel gefährden kann und zudem die Zusammenarbeit im Team auf eine harte Probe stellt.

Beispiel

Das Team hat super Arbeit geleistet. Das Inkrement ist zwei Tage vor dem Sprintende fertig, getestet und sowohl der Product Owner als auch die Stakeholder sind mehr als zufrieden mit dem Ergebnis.

Jetzt wird es gefährlich, denn der „Hero“ lauert schon und möchte, meist sogar mit den besten Absichten, ein paar Sachen optimieren, die seiner Meinung nach so natürlich nicht bleiben dürfen.

Das könnte z. B. die Bezeichnungen von Variablen, die Struktur des Codes, das i-Tüpfelchen auf der neuen Funktion oder was auch immer sein. Allerdings läuft die Optimierungsaktion nicht transparent und nach Abstimmung mit dem Team, sondern still und heimlich nach der Arbeit oder sogar Nachts. Mit garantierter böser Überraschung am nächsten Morgen.

Was erhofft sich der Hero? Anerkennung aus dem Team, Schulterklopfen, Lob vom Product Owner und den Stakeholdern.

Was passiert stattdessen regelmäßig: Das Inkrement funktioniert nicht mehr richtig und das Team muss es ausbaden. Sehr ärgerlich!

Lösungsansatz

Wenn so etwas passiert und man als Team daraus lernt und ein solches Verhalten ablehnt und dafür sorgt, dass es sich nicht wiederholt, ist alles gut.

Richtig gefährlich wird es, wenn ein solches Verhalten (es klappt ja auch oft) belohnt und gefördert wird. Dann bestärkt man diese Heros und schafft eine Kultur der „Superhelden“, die man als Team nicht möchte.

Also wenn ihr als Team keine Devs haben möchtet, die stark die Richtung vorgeben, ohne es im Team abzusprechen, thematisiert dieses Thema z. B. bei der nächsten Retro!

Team gerade noch im Aufbau

Teams sind nicht von Beginn an performant. Im Gegenteil: Es braucht seine Zeit, bis sich ein Team findet. Dabei durchlebt es vier bis fünf Phasen; von den Teamphasen nach Tuckman habt ihr sicher schon gehört:

• Forming
• Storming
• Norming
• Performing
• Adjourning

Zu diesem Themenbereich gibt es bereits ausreichend Blogposts und auch Videos. Auch wenn diese Teamphasen inzwischen recht bekannt sind, ist es der Umgang innerhalb von Team oftmals nicht optimal.

Gemeint ist damit, dass jedes Teamsetup individuell und anders ist. So könnte ein Team z. B. schon mehrere Jahre zusammengearbeitet haben, doch nun kommt in ein neues Projekt mit einem neuen Scrum Master. Wie wird dieser neue Scrum Master das Team nun behandeln und fördern?

Oder ein Team ist komplett neu und bekommt zudem noch einen neuen, ggf. noch wenig erfahrenen Scrum Master. Dieser tut sich schwer dabei zu erkennen, in welcher Phase sich das Team befindet. Und was es braucht, um sich durch die einzelnen Phasen zu begleiten.

Lösungsansatz

Achtet darauf in welcher Phase sich eurer Team gerade befindet und was es braucht, um am Ende in die Performing-Phase zu gelangen. Berücksichtigt das auch bei der Sprintplanung. Holt auch ggf. Unterstützung aus eurer Company bei einem erfahrenden Scrum Master oder in Form eines externen Profis. Das Thema Phychologische Sicherheit spielt auch hier eine nicht zu unterschätzende Rolle.

Eine Situation, die unbedingt vermieden, werden sollte ist, dass das Team den Willen zur Verbesserung (Inspect & Adapt) verliert. Wenn es zudem keine realistische Chance darauf gibt, dass sich die festgefahrene Situation verbessern wird, bleibt als letzte Chance dann leider oft nur noch das Team aufzulösen. Das bietet die Möglichkeit, dass die einzelnen Teammitglieder in einem neuen Teamsetup zu alter Stärke zurückfinden. Das ist der Endlosschleife ohne echte Performance vorzuziehen.

Hier ist ein starker Scrum Master gefragt. Der die Konflikte nicht nur erkennt, sondern auch adressiert und bei der Lösungsfindung unterstützt. Bei Bedarf kann es bei sehr schwierigen Konflikten durchaus helfen, auf eine externe Moderation des Teams zurückzugreifen oder auch, sich externe Hilfe zu besorgen.

Fehlende Transparenz

Bei fehlender Transparenz könnte man darüber streiten, was zuerst da war. Teamkonflikte oder die fehlende Transparenz, die zu ihren geführt haben. So oder so ist fehlende Transparenz oft der Tropfen, der das sprichwörtliche Fass zum Überlaufen bringt. Denn fehlende, oder nur oberflächliche Transparenz führt dazu, dass dieser Zustand als unzureichend und unvollständig angesehen wird, um Abhängigkeiten aufzudecken und Entscheidungen im Team gemeinsam treffen zu können.

Nun kann etwas Gefährliches passieren: Anstatt, dass sich alle im Team am Riemen reißen und es versuchen besser zu machen, wird dieser unzureichende Zustand quasi der neue Standard, an dem sich alle orientieren. Teils aus Frust, teils aus der Überzeugung heraus, dass die Tickets ja ohnehin nur für mich wichtig sind. Und derjenige, der das Ticket erstellt, kennt ja schließlich auch die Dinge, die zwischen den Zeilen stehen. So entsteht eine gefährliche Abwärtsspirale.

Lösungsansatz

Der einfachste Lösungsansatz ist hier natürlich, dass sich jeder an die eigene Nase fasst und bei sich selbst beginnt. So einfach wie es klingt, ist das aber leider beileibe nicht. Denn die Gewohnheit, die inzwischen vorherrscht, ist träge und lässt sich nur ungern vertreiben. Es braucht daher sowohl ein Team, dass sich seiner eigenen Verantwortung bewusst ist und diese auch prüft und einfordert. Als auch einen starker Scrum Master, der auf diese Verantwortung regelmäßig aufmerksam macht und zusätzlich auf eine gute, im Team abgestimmte und regelmäßig reviewte Definition of Done und Definition of Ready pocht. Hier gilt die Devise „steter Tropfen höhlt den Stein!“.

Was sicher auch helfen kann, ist es, eine Retro unter das Motto „Was wäre wenn ..?“ zu stellen. Also z. B. „Was würde langfristig passieren, wenn wir die Transparenz im Team schleifen lassen und jeder nur noch das absolute Minimum in den Tickets dokumentiert?“. Das kann durchaus helfen, diesem Szenario proaktiv entgegenzuwirken.

Summary

Oft liegt eine Mischung der oben genannten Punkte vor, in ganz unterschiedlichen Ausprägungen. Doch führen sie in Summe immer zum gleichen Ergebnis: Sie sorgen für ungenaues Schätzen der Entwickler. Was sich wiederum negativ auf die Fertigstellung des Inkrements und dessen Qualität auswirkt. Und hier schließt sich der Kreis zur oben genannten Manifestierung im Ergebnis.

Ein Defizit von fehlendem (Fach)Wissen im Team wird oft erst ganz am Ende bemerkt, nämlich dann, wenn das Produkt mit den echten Kunden bzw. Stakeholdern in Kontakt kommt. Natürlich kann die Qualität des Produktes im nächsten Sprint verbessert werden, es ist nur schlicht teurer und wirft die Sprintplanung gehörig durcheinander. Ohne Eingriff entsteht eine Abwärtsspirale. Welche weiteren Gründe noch dazu führen können, regelmäßige Lieferung von Software in hoher Qualität im Team zu erschweren, werde ich im nächsten Blogpost dieser dreiteiligen Serie erläutern.

Du teilst meine beschriebenen Erfahrungen? Oder hast selbst ganz andere gemacht? Schreibe mir gerne einen Kommentar an diesem Blogpost.