Wunsch vs. Wirklichkeit, Teil 1: (Fach)Wissen innerhalb des Teams

Eigentlich sollte dieser Artikel den Titel „Drei Gründe, warum Softwareteams es nicht schaffen, regelmäßige Lieferung und hohe Qualität einzuhalten, Teil 1: Fehlendes (Fach)Wissen innerhalb des Teams“ tragen … aber ihr seht selbst.

Es könnte so einfach sein, ist es aber nicht. Kennt ihr den Song noch? Das ist mir als Erstes in den Sinn gekommen, als ich über das zu Grunde liegende Thema des Blogposts nachgedacht habe. Denn wäre es so einfach und ein Softwareteam befähigt, alle Entscheidungen selbstständig treffen zu können, würde ich diesen Blogpost hier nicht schreiben. Aber ihr ahnt es schon: Das ist natürlich Wunschvorstellung.

In der Theorie ist z. B. das Scrum Framework als Liefermodell der richtige Ansatz, möchte man meinen. Vernünftig angewendet, gibt es am Ende eines jeden Sprints immer ein fertiges Inkrement, das qualitätsseitig keine Einbußen hinnehmen muss.

Also: Regelmäßige Lieferung … Check. Hohe Qualität … Check.

Wunschvorstellung adieu

Distanzieren wir uns von der Wunschvorstellung und betrachten die Praxis. Denn die ist in vielen Organisationen ein gutes Stück von der Wunschvorstellung entfernt – und Software-Teams sind nur eines der beteiligten Elemente. Genau hier fängt es an, spannend zu werden.

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

In den mehr als 15 Jahren, in denen Mayflower die unterschiedlichsten Softwareprojekte aktiv begleitet und gestaltet hat, ist eine Menge Wissen zusammengekommen. Daraus möchte ich drei exemplarische Beispiele aufgreifen und jedem dieser Beispiele bzw. Gründe einen eigenen Blogpost widmen. Vielleicht erkennt der eine 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

Nun genug der vielen Worte – beginnen wir also mit dem ersten Grund, der schuld daran sein kann, dass Softwareteams es nicht schaffen, regelmäßige Lieferung und hohe Qualität einzuhalten.

Grund 1: Fehlendes (Fach)Wissen innerhalb des Teams

Mangelnde Softwarequalität ist oft das Symptom eines ganz anderen Problems: nämlich fehlendes Fachwissen innerhalb des Teams. 

Dieses fehlende Fachwissen ist per se aber natürlich nicht transparent und greifbar und manifestiert sich oft erst im Ergebnis. Im Falle eines digitalen Produktes eben in Form von schlechter Softwarequalität des Inkrements.

Welche Ausmaße kann so ein Defizit an Wissen haben? Dazu gehe ich auf ein paar Beispiele näher ein, die verdeutlichen, warum sie unmittelbar mit der Qualität zusammenhängen.

Fehlendes Domänen-Fachwissen

Um User-zentrierte, qualitativ hochwertige Software entwickeln zu können, benötigen Entwickler Domänen-Fachwissen. Das schließt Dinge wie Fachbegriffe und deren Bedeutung, Kontextwissen über die Fachdomäne, Wissen über den Endkunden, Stakeholder und ihre Bedürfnisse (Jobs-to-be-done), aber auch tiefes Produktwissen mit ein.

Wie lautet die Produktvision? Warum wurde das Design genau so gewählt und welche Absicht verfolgt man damit? Auch Dinge wie eine klare Abgrenzung von sich überschneidenden Domänen sind von Bedeutung. 

Kurzum: Entwickler müssen zu Experten innerhalb der eigenen Fachdomäne werden und sich auch mit zusätzlichen Themen – neben der Codeerstellung – beschäftigen. Sicher keine leichte Aufgabe.

Lösungsansatz

Wie kann man fehlendem (Fach)Wissen innerhalb des Teams begegnen? Mit systematischem, langfristigem Aufbau des Gleichen. Da gibt es ein paar hilfreiche Kniffe.

Wissen transparent machen

Nicht umsonst ist eine der Säulen von Scrum Transparenz. Auch beim benötigten Wissen rund um das Produkt und dessen Fachdomäne. Was im Alltag durchaus eine Herausforderung sein kann, ist die Frage, wie dieses Wissen aktuell und verständlich aufbereitet für alle im Team zugänglich gemacht werden kann.

Hier können Canvases eine große Hilfe darstellen. Canvases gibt es für alle möglichen Bereiche und sie können Wissen in kompakter Form darstellen. Schaut Euch z. b. in Miro die Templates näher an, oder werft einen Blick auf Canvas Revolution, um Euch inspirieren zu lassen.

Fachexperten einbeziehen

Eines der Prinzipien des Manifests für agile Softwareentwicklung lautet: „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.“ Das ist in der Praxis nicht immer so. Dennoch sollten Fachexperten zu Rat gezogen werden, wenn es möglich ist. Das kann dem Team viel Mühe und Zeit ersparen.

Dinge im Pair tun

Jetzt werden manche sagen: „Wie zu zweit. Was das kostet! Und dann dauert es ja noch länger!“ Stimmt – aber wer den Blogpost bis hierhin aufmerksam gelesen hat, weiß wie die Alternative dazu aussieht. 

Pairing ist und bleibt ein sehr gutes Mittel, um Wissen im Team weiterzugeben und dauerhaft qualitativ hochwertige Software entwickeln zu können.

Fehlende Anwendung von Programmier- und Test-Methoden

Was bei dem fehlenden Domänenfachwissen beginnt, setzt sich im Bereich der Codeerstellung und Tests fort.

Lösungsansatz

Wie lassen sich neue Programmier- und Test-Methoden im Team etablieren, ohne die Teammitglieder zu überfrachten und das Sprintziel aus den Augen zu verlieren?

Pair-Programming/Mob-Programming

Wer mehr zum Thema wissen möchte, dem lege ich den Blogpost meines Kollegen Christopher ans Herz.

Das Team schult sich selbst

Wissen ist unterschiedlich im Team verteilt. Das ist normal und nicht weiter schlimm, sofern dieses Wissen nach und nach verteilt wird. Dazu stehen ganz unterschiedliche Formate zur Verfügung, wie z. B. das bereits erwähnt Pair- und Mobprogramming, kurze Lightning-Talks, um Wissen in kleinen Päckchen weitergeben zu können, oder auch Team-Workshops oder Coding Dojos.

Das Team holt sich externe Wissenträger temporär ins Team dazu

Wenn das Wissen im Team nicht vorrätig ist, nicht aufgebaut werden kann und auch in der restlichen Organisation nicht verfügbar ist, bleibt noch der externe Trainer.

Oft wird der Aufwand unterschätzt, sich in ein neues Expertenthema einzuarbeiten. Besonders dann, wenn noch gar kein Wissen und keinerlei Praxiserfahrung vorhanden ist. An dieser Stelle kann man leicht Gefahr laufen, gleich zu Beginn aufgrund des fehlen Fachwissens falsche Entscheidungen zu treffen und von sich von dort aus beginnend eine Menge Zeit und Ressourcen auf falsche oder ungeeignete Lösungsansätze zu vergeuden.

Externe Experten helfen auf jeden Fall bei der Entscheidungsfindung und geben dadurch einen gewissen Grad an Sicherheit. Mayflower bietet Trainings zu unterschiedlichen Themen, wie z. B. Architecture Foundations  an.

Wissensaufbau und Wissenstransfer in den Arbeitsalltag einbauen

Last, but not least sollte das Team einen Weg finden, das Wissen und dessen Transfer in den Arbeitsalltag zu integrieren.

Auch hier stehen verschiedenen Varianten zur Wahl. Neben den oben erwähnten Methoden hilft es organisatorisch, je nach Umfeld, Zeit je Sprint dafür zu reservieren. Ein sehr gutes Invest für die zukünftige Qualität des Produktes.

Gesamtes System (inklusive Code) hat zu hohe Komplexität

Ein Grund, der nicht gern beleuchtet wird, sind gewachsene Systeme. Sie wurden über die Jahre des Auf- und Umbaus, Dutzenden von unterschiedlichen Teams die mit der Weiterentwicklung, Wartung und Pflege beauftragt wurden, zu einem Komplexitäts-Monster, mit dem sich schlicht nicht mehr wirtschaftlich arbeiten lässt.

Aber zum Glück gibt es heutzutage auch Möglichkeiten, um genau diesen Sachverhalt prüfen zu können. Schließlich will keine Organisation unnötig Ressourcen an einem System vergeuden, wenn es hierzu auch Alternativen gibt. Mehr dazu in den Lösungsansätzen.

Lösungsansatz

Ihr habt schon länger das Gefühl, dass euer Legacy-System einen Punkt erreicht hat, in dem es sich nicht mehr lohnt, Zeit und Ressourcen in neue Features zu investieren? Das System wird im Grunde durch das Fehlen einer Alternative nur noch am Leben gehalten. 

Eine Modernisierung steht schon seit geraumer Zeit auf dem Plan, es fehlt euch aber eine Kenngröße, mit der ihr genau dieses Gefühl ausdrücken und Entscheider davon überzeugen könnt, die lange geplante Modernisierung endlich anzugehen. Vielleicht helfen euch diese zwei Kenngrößen weiter.

Cyclomatic Complexity

Dabei handelt es sich um eine Software Metrik, an Hand derer ermittelt werden kann, wie komplex ein Programm ist. Dazu werden die Anzahl von linearen, unabhängigen Pfaden im Source Code ermittelt. Und das wiederum kann ein sehr deutlicher Wert sein, anhand dessen sich ablesen lässt, ob ein Programm grundsätzlich mit vertretbarem Aufwand erweitert bzw. gepflegt werden kann. Oder ob eine grundlegende Modernisierung nicht doch die bessere Wahl ist.

Das Thema ist natürlich stark vereinfacht, um den Rahmen dieses Blogposts nicht zu sprengen. Aber ich versuche das Thema anhand dieses Beispiels zu verdeutlichen:

Die Komplexität (M) berechnet sich wie folgt:

M = E − N + 2P

wobei

• E = Anzahl der Bedingungen innerhalb eines Graphen (the number of edges of the graph) → Pfeile in der Grafik
• N = Anzahl der Nodes (the number of nodes of the graph) → Kreise in der Grafik
• P = Anzahl der verbundenen Komponenten (the number of connected components) → rote Start und blaue Endpunkte in der Grafik

Bezogen auf dieses Beispiel sähe die Rechnung so aus: 10 – 8 + 2 = 4 Komplexität

Gleicht man dieses Ergebnis (Komplexität = 4) mit folgender Intepretation ab, kommt man zu dem Schluss, dass bei diesem sehr einfachen Programm ein geringes Risiko bei einer Anpassung besteht:

NPath complexity

Mit anderen Worten, sollte man sich bei einer Komplexität > 50 sehr zeitnah Gedanken über eine Modernisierungsstrategie machen!

Neben der Cyclomatic Complexity möchte ich noch die  NPath complexity erwähnen. Bei der NPath complexity wird der Fokus auf Anzahl der Ausführungspfade gelegt, die je nach Anwendungsfall ebenso einen guten Anhaltspunkt für Komplexität von Code geben kann.

Wenn ihr noch mehr Infos zum Thema Softwaremodernisierung haben möchtet schaut gerne mal auf unserer Modernisierungs-Seite vorbei, oder lasst uns doch bei einem virtuellen Kaffee austauschen und eure Herausforderungen besprechen.

Summary

Oft liegt eine Mischung der oben genannten Punkte in ganz unterschiedlichen Ausprägungen vor. 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. 

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? Hinterlasse mir gerne einen Kommentar an diesem Blogpost.