Stiller Killer #2: Fluktuation

In der Soft­wa­reen­twick­lung kön­nen Zustände entste­hen, die den Pro­jek­ter­folg verzögern, gefährden oder gän­zlich unmöglich machen. Schon manch­es Pro­jekt musste wegen man­gel­nden Bewusst­seins über solche Risiken wieder­holt neu aufge­set­zt oder gän­zlich begraben wer­den. Selb­st dann jedoch bleiben die Ursachen häu­fig im Ver­bor­ge­nen. Ich nenne sie daher stille Killer – die unerkan­nte, zuweilen auch nur unter­schätzte Gefahr.

Die Fluk­tu­a­tion inner­halb von Soft­wa­reen­twick­lung­steams scheint oft­mals nicht als beson­ders beacht­enswert wahrgenom­men zu wer­den. Vielmehr wird das Kom­men und Gehen von Mitar­beit­ern als etwas Natür­lich­es, „Gottgegebenes“ meist rel­a­tiv gelassen hin­genom­men. Der Aufwand, das abge­wan­derte Per­son­al zu erset­zen, ist zwar ein Wer­mut­stropfen. Den­noch agiert man im Per­sonal­man­age­ment allzu häu­fig nach der Maxime jed­er ist erset­zbar. Und auf rein biol­o­gis­ch­er Ebene stimmt das sog­ar. Auf Entwick­lung­steams angewen­det jedoch kann diese Ein­stel­lung eine zer­störerische Wirkung zeitigen. 

Tat­sache ist, solange sich der Aus­tausch von Team­mit­gliedern in erträglichen Gren­zen bewegt, bleibt es unprob­lema­tisch. Die Mei­n­un­gen darüber, wo die Gren­ze liegt, gehen jedoch auseinan­der. Auch wird die Ein­schätzung, ob die Fluk­tu­a­tion­srate eines Unternehmens hoch oder niedrig ist, nicht anhand absoluter Größen getrof­fen. Vielmehr wer­den zur Beurteilung Ver­gle­ich­swerte wie die branchenübliche Fluk­tu­a­tion und die Kon­junk­tur herange­zo­gen. Gehaltsstufen und Tätigkeit­sebe­nen wirken sich eben­falls aus. Im Gast­gewerbe beispiel­sweise sind die Aus­tauschzyklen von Ser­vicemi­tar­beit­ern höher als bei Fachar­beit­ern im Maschinenbau. 

Rein sta­tis­tisch betra­chtet ist es sin­nvoll, die eigene Fluk­tu­a­tion­srate im Ver­gle­ich mit anderen zu bew­erten. Nichts­destotrotz gel­ten für Soft­wareteams engere Ausle­gun­gen, denn Soft­wa­reen­twick­lung ist Wis­sensar­beit. Ein Soft­wa­reen­twick­lung­steam lebt davon, langfristig Wis­sen aufzubauen. Das Kon­den­sat dieses Wis­sens schlägt sich schließlich direkt in der Güte der erzeugten Pro­duk­te nieder. Je nach Kom­plex­ität von Fach­lichkeit und Tech­nik steigt somit der Wert des Teams, und damit jedes einzel­nen Mitar­beit­ers, mit der Dauer der Teamzuge­hörigkeit. An diesem Punkt löst sich der alte Traum der Per­son­al­wirtschaft, jed­er Mitar­beit­er sei erset­zbar, in Luft auf – ob wir es nun wahrhaben wollen oder nicht. 

Ein Beispiel

Das fol­gende Beispiel ist aus der Real­ität gegrif­f­en, die Namen sind aus Daten­schutz­grün­den frei erfun­den. Betra­chtet wird das Jahr 2016, das Entwick­lung­steam zählt zu Jahres­be­ginn sieben Mit­glieder. Über die Monate sind mehrere Abgänge zu bekla­gen, aber auch Neuzugänge zu begrüßen. Abge­hende Mitar­beit­er sind in der fol­gen­den Darstel­lung rot markiert, hinzugekommene grün. Es lässt sich fest­stellen, dass die Team­größe am Jahre­sende unverän­dert ist. Allerd­ings haben sich die Namen stark verän­dert, lediglich zwei Mitar­beit­er sind bis zum Jahre­sende dabeigeblieben:

Abb.: Fluk­tu­a­tion eines Teams im Jahr 2016 (Beispiel)

Berechnung der Fluktuationsrate

Zur Berech­nung der Fluk­tu­a­tion­srate wer­den die Para­me­ter Team­größe, Zugänge und Abgänge miteinan­der in Beziehung geset­zt. Hier­für gibt es ver­schiedene Formeln, die je nach Sit­u­a­tion zu unter­schiedlichen Ergeb­nis­sen führen kön­nen. Bei unserem recht sim­plen Beispiel reicht es aus, den Anteil der aus­ge­tauscht­en Kol­le­gen im Ver­hält­nis zur Team­größe zu beurteilen. Dabei stellen wir fest, dass inner­halb des Betra­ch­tungszeitraums 5 von 7 Mitar­beit­ern erset­zt wur­den. Das entspricht ein­er Quote von 71,4 Prozent.

Die Ermit­tlung der Fluk­tu­a­tion als betrieb­swirtschaftliche Kenn­zahl ist eine Wis­senschaft für sich. Diese Ebene soll hier nicht betra­chtet wer­den. Für uns ist die sozial­dy­namis­che Kom­po­nente wichtiger, näm­lich wie sich das Kom­men und Gehen von Mitar­beit­ern auf die Grup­pen­dy­namik eines Teams und somit auf dessen Leis­tungs­fähigkeit auswirkt. Wir erin­nern uns: Soft­wa­reen­twick­lung ist Wissensarbeit.

ÜBERMÄSSIGE FLUKTUATION WIRKT ZERSTÖRERISCH

In unserem Beispiel sind zum Jahre­sende knapp 3/4 des Teams erset­zt. Und obwohl die Team­größe während des Zeitraums nahezu kon­stant bleibt, wird dieses Team ver­mut­lich nicht gut funk­tion­ieren. Warum ist das so?

Phasen des Teambuildings nach Tuckman

Der amerikanis­che Psy­chologe Bruce Tuck­man for­mulierte in den Sechziger­jahren sein Phasen­mod­ell der grup­pen­dy­namis­chen Entwick­lung von Teams. Dem­nach find­et das, was wir als Team­build­ing beze­ich­nen, immer in vier Phasen statt, näm­lich Form­ing, Storm­ing, Norm­ing und Per­form­ing. Wir wollen diese kurz erklären.

Forming

Das Team entste­ht und macht sich mit seinem Umfeld und den anste­hen­den Her­aus­forderun­gen ver­traut. Üblicher­weise wer­den in der Start­phase Diskus­sio­nen darüber geführt, wie die geset­zten Ziele erre­icht wer­den sollen. Die Mit­glieder des Teams arbeit­en noch weit­ge­hend berührungs­frei und ver­hal­ten sich so, wie sie es aus früheren Pro­jek­ten gewohnt sind.

Storming

In dieser Phase lernt das Team die unter­schiedlichen Charak­tere sein­er Mit­glieder ken­nen und begin­nt, diese einzuord­nen. Es stellt sich her­aus, wer mit wem „gut kann“, und wo Per­sön­lichkeit­en aufeinan­der­prallen. Es kann sein, dass sich inner­halb des Teams Unter­grup­pen formieren. Außer­dem kön­nen Kon­flik­te mehr oder weniger offen zutage treten.

Norming

Ide­al­er­weise ler­nen die Team­mit­glieder nun, auf pro­duk­ti­vere Weise miteinan­der umzuge­hen, Kon­flik­te zu lösen und Per­sön­lichkeit­sun­ter­schiede auszu­gle­ichen. Die gemein­same Zielset­zung, die im Form­ing definiert wurde, erlebt nun eine höhere Ebene der Zusammenarbeit.

Performing

In der Aus­führungsphase sind die grundle­gen­den Nor­men geset­zt, und das Team hat Wege der Zusam­me­nar­beit für sich etabliert. Rollen und Posi­tio­nen sind klar her­aus­gear­beit­et, so dass Arbeitsabläufe effizien­ter von­stat­ten gehen. Nun ist das Team weniger mit sich selb­st als mit der Aus­führung sein­er eigentlichen Auf­gaben beschäftigt.

Dieser kurze Abriss soll genü­gen um zu ver­ste­hen, dass Team­build­ing mehr ist als das bloße Grup­pieren von Men­schen mit bes­timmten Fähigkeit­en. Es ist ein Prozess, der den Beteiligten Zeit, Energie und ein nicht zu unter­schätzen­des Maß an sozialer und emo­tionaler Reife abver­langt. Wie lange es dauert, lässt sich wed­er fes­tle­gen noch abschätzen. Wir kön­nen aber davon aus­ge­hen, dass fast immer mehrere Monate benötigt wer­den, ein Team so reifen zu lassen, dass die Zusam­me­nar­beit effek­tiv funk­tion­iert. In Wahrheit ist der Vor­gang kom­plex, vielschichtig und anstren­gend – wie immer, wenn Men­schen mit unter­schiedlichen Hin­ter­grün­den aufeinandertreffen. 

Never change a running system

Ein Team, das den Zus­tand Per­form­ing erre­icht hat, kann als ein funk­tion­ieren­des Sys­tem betra­chtet wer­den, bei dem ein Räd­chen ins andere greift. Die einzel­nen Kom­po­nen­ten, die Team­mit­glieder, sind gut aufeinan­der abges­timmt. Der Nachricht­e­naus­tausch inner­halb des Teams erfol­gt peer-to-peer, im Mul­ti- oder Broad­cast-Modus, je nach­dem, welch­er Modus ger­ade angemessen ist. Die soziale Intel­li­genz des Teamwe­sens ist in der Lage, unter­schiedliche Kom­mu­nika­tion­sebe­nen und Nachricht­en­for­mate zu adap­tieren und aufeinan­der abzu­bilden. Das ist das Ergeb­nis eines lan­gen Lernprozesses. 

Komplexe Systeme sind fragil

Jede Verän­derung eines so funk­tion­ieren­den Sys­tems wird immer eine Störung des Gesamt­sys­tems her­vor­rufen, gle­ich­wohl ob es sich um eine Ver­größerung oder Verkleinerung han­delt. Selb­st wenn die Größe des Sys­tems unverän­dert bleibt und nur einzelne Teile aus­ge­tauscht wer­den, wird das Zusam­men­spiel ins­ge­samt nicht mehr so sein wie vorher. Wie heißt es so schön? Nev­er change a run­ning system.

In unserem Beispiel­team sind am Jahre­sende fünf von sieben „Kom­po­nen­ten“ erset­zt wor­den. Aus grup­pen­dy­namis­ch­er Sicht bedeutet das, dass ein völ­lig anderes, neues Sys­tem gebildet wurde. Das Team wird unweiger­lich in sein­er Evo­lu­tion zurück­ge­wor­fen. Es begin­nt wieder bei Phase 0, dem Form­ing, unab­hängig auf welch­er Stufe es vorher stand.

Damit nicht genug, wenn wir die Zeit­punk­te betra­cht­en, an denen die Per­son­al­wech­sel stat­tfan­den, stellen wir fest, dass in vier Monat­en des Jahres 2019 Kol­le­gen das Team ver­lassen haben und/oder neue Kol­le­gen hinzugekom­men sind. Dabei ist es zweitrangig, von welch­er Art die Wech­sel sind und in welchem Umfang sie erfol­gen. Das entschei­dende Ele­ment ist tat­säch­lich, dass eine Verän­derung stattge­fun­den hat. Nach jed­er Verän­derung begin­nt das Form­ing von neuem, gefol­gt von Storm­ing usw. Das ist ein Naturge­setz. Wir kön­nen somit davon aus­ge­hen, dass dieses Team während des ganzen Jahres nicht aus der Form­ing­phase her­aus­gekom­men ist. Allen­falls pen­delte es zwis­chen Form­ing und Storm­ing hin und her.

Gibt es Gegenmittel?

Wir haben gel­ernt, Soft­wa­reen­twick­lung ist Wis­sensar­beit. Was wäre also nahe­liegen­der, als das Wis­sen eines Teams so zu kon­servieren, dass notwendi­ge oder unfrei­willige Per­son­al­wech­sel sich weniger nachteilig auswirken? Doku­men­ta­tion ist hier das Wort der Stunde. Wenn wir alles doku­men­tieren, also die fach­lichen Anforderun­gen, die tech­nis­che Infra­struk­tur und nicht zulet­zt den Quell­code, dann soll­ten wir diesem Anspruch doch gerecht wer­den können.

Umfassende Dokumentation

Um es gle­ich vor­wegzunehmen, das wird ver­mut­lich nicht gut funk­tion­ieren, aus mehreren Grün­den. Wer schon ein­mal ver­sucht hat, eine umfassende Doku­men­ta­tion aus einem Soft­wareteam her­auszuk­itzeln, weiß, wie schwierig das ist. Doku­men­ta­tion ist rel­a­tiv ein­fach, solange sie sich auf einem hohen Abstrak­tion­sniveau bewegt. Um Team­mit­glieder aus­tauschen zu kön­nen, müssen wir aber viel weit­er in die Tiefe gehen. Und all die Wis­sensin­seln, Kopf­mono­pole und alles Spezial­wis­sen trans­par­ent darzustellen ist schi­er unmöglich. 

Es ist unmöglich, alles zu dokumentieren

Langlaufende Soft­waresys­teme wer­den sehr schnell der­art kom­plex, dass die Bere­iche zwis­chen den einzel­nen Fak­ten der Fach­domäne, die nir­gend­wo schriftlich erfasst sind, immer umfan­gre­ich­er wer­den. Es sind die dynamis­chen Zusam­men­hänge, dort, wo viele Fak­toren aufeinan­dertr­e­f­fen und sich wis­senstech­nis­che Syn­ergien ergeben, die nur über Erfahrung mit genau diesem Sys­tem erlernt wer­den kön­nen. Und das braucht Zeit. Die neuen Kol­le­gen ler­nen diese Dinge nicht, indem sie die Sys­tem­doku­men­ta­tion studieren. Zu den kom­plex­en fach­lichen Zusam­men­hän­gen kommt dann noch die tech­nis­che Ebene, die ihrer­seits tiefes sys­tem­be­zo­genes Wis­sen erfordert, mit weit­eren Her­aus­forderun­gen bezüglich der Dokumentation. 

Das heißt aber nicht, dass wir gar nicht doku­men­tieren sollen, im Gegen­teil! Natür­lich ist Doku­men­ta­tion richtig und wichtig, ist sie doch untrennbar­er Bestandteil eines guten und voll­ständi­gen Soft­ware­pro­duk­ts. Nur dür­fen wir nicht erwarten, dass sie das Mit­tel ist, um dem Fluch der Fluk­tu­a­tion zu entkom­men. Dazu bedarf es mehr. 

Wartbare Software

Wenn wir über Doku­men­ta­tion reden, reden wir im sel­ben Atemzug über Cod­e­qual­ität. Tat­säch­lich ist der Quell­code ein wesentlich­er Teil der Doku­men­ta­tion. Gut ver­fasster, präg­nant for­muliert­er, schnörkel­los­er Code erk­lärt dem Entwick­ler das Sys­tem mit seinen fach­lichen Regeln und tech­nis­chen Zusam­men­hän­gen. Uncle Bob hat dieser Philoso­phie mehrere Büch­er gewid­met, die in der Fach­welt eine gewisse Akzep­tanz erlangt haben. Und hier haben wir eine wesentliche Stellschraube für unser Prob­lem gefun­den: sauber­er Code zusam­men mit einem vernün­fti­gen Maß an Doku­men­ta­tion hil­ft tat­säch­lich, die neg­a­tiv­en Effek­te in fluk­tu­ieren­den Teams abzu­mildern. Aber Achtung: das ist leichter gesagt als getan, und in der Prax­is tat­säch­lich sel­ten anzutr­e­f­fen. Pro­jek­tver­ant­wortliche sind somit aufgerufen, diesen Anforderun­gen sowohl durch die Qual­ität der Per­son­alauswahl als auch durch ihre eige­nen Führungsqual­itäten Rech­nung zu tra­gen — noth­ing in life is for free, und nie­mand würde behaupten, dass es ein­fach wäre!

Fluktuation vermindern

Eine weit­ere, sehr wirkungsvolle Stellschraube ist eigentlich auch die nahe­liegend­ste: Sorge dafür, dass die guten Mitar­beit­er bleiben! Auch das ist leicht gesagt. Wir ken­nen jedoch eine Rei­he von Fak­toren, die Mitar­beit­er zum bleiben bewegen.

Gehaltsstrukturen

In einem Soft­wa­reen­twick­lung­spro­jekt sind die Soft­ware Engi­neers das wertvoll­ste Asset. Sie soll­ten entsprechend gepflegt und gewürdigt wer­den. Sie haben alle benötigten Fähigkeit­en, um ein Soft­ware­pro­jekt zu pla­nen, umzuset­zen und auszuliefern. Der Soft­ware Engi­neer verkör­pert nicht nur die Rolle des Pro­gram­mier­ers, son­dern auch die Rollen des Busi­ness Ana­lysten, Pro­jek­tleit­ers, Head-of-every­thing und CxOs in Per­son­alu­nion, denn diese sind Bestandteil sein­er Aus­bil­dung. Zumin­d­est the­o­retisch, denn natür­lich kommt es auch ein biss­chen auf die Größe des Pro­jek­tes an. Nichts­destotrotz wurde der Beweis für diese Behaup­tung in der Prax­is oft genug erbracht. Wir ken­nen die One Man Suc­cess Sto­rys zur Genüge. Also noch ein­mal: der Soft­ware Engi­neer ist das wertvoll­ste Asset. Das ist auch der Grund, warum in führen­den Unternehmen, die ihre Ein­nah­men direkt aus Soft­ware­pro­duk­ten gener­ieren, die Entwick­ler sechsstel­lige Jahres­ge­häl­ter mit nach Hause nehmen.

In Deutsch­land ist das allerd­ings kaum umzuset­zen, da die Gehaltsstufen meist streng an Posi­tio­nen gekop­pelt sind. Dass ein Entwick­ler mehr ver­di­ent als der Abteilungsleit­er ist hierzu­lande beina­he undenkbar. Zwar gibt es auch bei uns einige Unternehmen, die soge­nan­nte hor­i­zon­tale oder fach­liche Kar­ri­eren fördern, bre­it durchge­set­zt hat sich dieses Mod­ell aber noch nicht. Leis­tungs­gerechte Bezahlung wird so zur Unmöglichkeit, die Abwan­derung der besten Köpfe ist vor­pro­gram­miert. Unglück­licher­weise gehen in der Regel immer die guten Mitar­beit­er, die weniger motivierten bleiben.

Mitarbeiterzufriedenheit

Die Mitar­beit­erzufrieden­heit ist in mod­er­nen Unternehmen eine ele­mentare Ken­ngröße. Es gibt Mod­elle, Meth­o­d­en und Metriken, um die Mitar­beit­erzufrieden­heit betrieb­swirtschaftlich zu berück­sichti­gen. Damit kann man sich wis­senschaftlich auseinan­der­set­zen, muss man aber nicht. Die agile Welt der Soft­wa­reen­twick­lung bietet alles, was es dazu braucht. 

Agile Organisation

Fast jed­er ken­nt heutzu­tage den Begriff der Agilen Organ­i­sa­tion, und viele wür­den Stein und Bein schwören, Teil ein­er agilen Organ­i­sa­tion zu sein. Nun, wenn es so ist, warum haben wir dann ein Prob­lem mit Fluk­tu­a­tion? Es gilt der Leitgedanke der agilen Welt „if it’s not fun, it’s not agile“. Und salopp gesagt, wenn es keinen Spaß macht, dann gehen die Mitar­beit­er eben. Falls der aufmerk­same Leser an dieser Stelle eine leichte Ver­wirrung ver­spürt, das lässt sich schnell erk­lären: Es gibt näm­lich zwei Arten von Agilität — die echte Agilität und die vorge­spiegelte Agilität, das soge­nan­nte Car­go Agile.

Car­go Agile ist das, was die meis­ten aus ihrem Arbeit­sall­t­ag ken­nen, auch wenn der Begriff vielle­icht nicht jedem geläu­fig ist. Es ist die Art von Agilität, bei der die äußer­lich erkennbaren Merk­male agiler Organ­i­sa­tio­nen umge­set­zt wer­den, beispiel­sweise Iter­a­tio­nen mit regelmäßi­gen Sprint Reviews, Ret­ro­spek­tiv­en und Pla­nungsmeet­ings. Im fort­geschrit­te­nen Car­go Cult wird sog­ar noch ein Mitar­beit­er als Scrum Mas­ter bestellt, und das agile The­ater ist per­fekt. Mit Agilität hat das aber nichts zu tun. Es ist in etwa so, als würde man sich ein Rolex-Pla­giat ums Handge­lenk binden, um wohlhabend zu wirken, ohne es wirk­lich zu sein.

Echte Agilität erken­nt man an ihren Frücht­en. His­torisch gewach­sene Hier­ar­chien mag es dabei zwar geben, doch wer­den sie nicht in Form von Befehls­ket­ten gelebt. Führungskräfte im Geiste des Ser­vant Lead­er­ship ver­ste­hen sich als Enabler, die ihre Auf­gabe darin sehen, Boden und Umfeld für die Entwick­lung­steams so zu bere­it­en, dass diese ihre Arbeit effizient gestal­ten kön­nen. Die Teams hinge­gen ver­ant­worten selb­stor­gan­isiert die Bere­it­stel­lung von Lösun­gen. Sie haben das meiste Wis­sen darüber und deshalb auch die meiste Kon­trolle bei allen Entschei­dun­gen, soweit sie die Umset­zung betr­e­f­fen. Recruit­ing und Team­build­ing fall­en eben­falls in die Ver­ant­wor­tung von Empow­ered Teams.

Streben nach Exzellenz

Ein Kennze­ichen agiler Organ­i­sa­tio­nen ist das beständi­ge Streben nach Exzel­lenz nicht nur auf der tech­nis­chen, son­dern eben­so auf der fach­lichen, organ­isatorischen und zwis­chen­men­schlichen Ebene. Agile Unternehmen fördern im Ser­vant Lead­er­ship die Weit­er­en­twick­lung und Fort­bil­dung ihrer Mitar­beit­er und räu­men entsprechende Möglichkeit­en ein. In der agilen Soft­wa­reen­twick­lung wer­den erprobte Meth­o­d­en wie Pair- oder Mob Pro­gram­ming, Cod­ing Dojos und Tech Talks gefördert, wodurch die selb­stor­gan­isierte Weit­er­en­twick­lung der Teams kon­tinuier­lich begün­stigt wird. Die fes­tangestell­ten Mitar­beit­er absolvieren Schu­lun­gen und besuchen Fachkon­feren­zen. Freiberu­fliche Kol­le­gen wer­den durch ein solch­es Umfeld ermutigt, gle­ichzuziehen. Wenn durch solche Maß­nah­men die Mess­lat­te auf einem hohen Niveau gehal­ten wird, darf sich ein Pro­jekt State of the Art nennen.

State of the Art

Ein State-of-the-Art-Pro­jekt zieht von sich aus fähige Mitar­beit­er an. Schwächere durch­laufen in kurz­er Zeit eine Entwick­lung zum Pos­i­tiv­en, um an das Niveau der Avant­gardis­ten her­anzukom­men, oder ver­lassen das Team. Das ist nor­males grup­pen­dy­namis­ches Ver­hal­ten. Auf diese Weise reg­uliert sich das Umfeld von selb­st auf ein höheres Niveau. Die Chance, dass die guten Mitar­beit­er nicht weit­erziehen son­dern dem Pro­jekt langfristig erhal­ten bleiben, wird in State-of-the-Art-Pro­jek­ten max­imiert. Und das ist es, was wir erre­ichen wollen, denn fähige Mitar­beit­er sind unser wertvoll­stes Asset. 

In diesem Sinne: Let’s get excellent!

Wikipedia: Fluk­tu­a­tion

Stiller Killer #1: Technische Schulden

Im Soft­wa­reen­twick­lung­sprozess kön­nen Zustände entste­hen, die den Pro­jek­ter­folg verzögern, gefährden oder gän­zlich unmöglich machen. Schon manch­es Pro­jekt musste wegen man­gel­nden Bewusst­seins über solche Risiken wieder­holt neu aufge­set­zt oder gän­zlich begraben wer­den. Selb­st dann jedoch bleiben die Ursachen häu­fig im Ver­bor­ge­nen. Ich nenne sie daher stille Killer – die unerkan­nte, zuweilen auch nur unter­schätzte Gefahr.

Der Begriff der Tech­nis­chen Schulden ist heute den meis­ten, die in irgen­dein­er Weise mit Soft­wa­reen­twick­lung zu tun haben, geläu­fig. In agilen Entwick­lerteams wird er für gewöhn­lich regelmäßig the­ma­tisiert. Unter dem Kürzel TD für Englisch Tech­ni­cal Debt wird die Tech­nis­che Schuld gerne bemüht, um Verzögerun­gen oder Fehler­rat­en zu begrün­den. Und obwohl das Konzept der Tech­nis­chen Schuld in den let­zten Jahren auf unrühm­liche Weise pop­ulär gewor­den ist, gibt es einen Umstand, der allzu leicht überse­hen wird: die Entste­hung von Tech­nis­ch­er Schuld ist unvermeidbar.

Technische Schuld ist ein Naturgesetz

Wir sind nicht hellsichtig, und Zeit ist ein knappes Gut (glauben wir)

Soviel wir uns auch bemühen, wir kön­nen nicht jedes Detail vorausah­nen. Auch kön­nen wir uns nicht beliebig viel Zeit nehmen, immer die ide­ale Lösung zu entwer­fen. So manche weitre­ichende Entschei­dung tre­f­fen wir inner­halb von Sekun­den. Manch­mal bemerken wir zu spät, dass uns zur opti­malen Umset­zung schlicht Wis­sen fehlte.

Architektur erodiert

Und dann ist da noch etwas, das Dr. Car­o­la Lilien­thal als Architek­turero­sion beze­ich­net. Damit ist gemeint, dass selb­st ein ide­al­er Entwurf mit der Zeit seine Gültigkeit ver­lieren kann, und aus ein­er ehe­mals guten mit der Zeit eine weniger gute Imple­men­tierung wird. Eine Architek­tur, die gestern noch per­fekt war, ist heute falsch, da die Umstände sich verän­dert haben. Geset­zliche Vor­gaben oder neue Ver­fahren im Zahlungsverkehr sind gute Beispiele dafür. Davon abge­se­hen entste­ht Ero­sion häu­fig auch dadurch, dass ver­schiedene Entwick­ler mit unter­schiedlichem Hin­ter­grund und Sachver­stand den Code mit der Zeit in ein Sta­di­um zunehmender Unord­nung über­führen. Kurz gesagt: der Code wird mit der Zeit immer schlechter. In vie­len Soft­ware­pro­jek­ten ist das eine fest­ste­hende Tatsache.

frei nach C. Lilien­thal: der „Kor­ri­dor geringer Tech­nis­ch­er Schuld“

Es ist also schw­er, TDs in Soft­waresys­te­men ganz zu ver­mei­den. Wohl aber gibt es Möglichkeit­en, die Schä­den zu min­imieren, indem wir ihr Aus­maß inner­halb eines „Kor­ri­dors geringer tech­nis­ch­er Schulden“ (Lilien­thal) hal­ten. Doch zunächst wollen wir ver­suchen zu umreißen, was Tech­nis­che Schuld für uns bedeutet.

Definition

Tat­säch­lich gibt es zur Def­i­n­i­tion von TD unter­schiedliche Betra­ch­tungsweisen. Die ein­fach­ste ist, jed­wede unsachgemäße Pro­gram­mierung als TD zu beze­ich­nen. Unsachgemäß bedeutet hier: den Stand der Kun­st mis­sach­t­end oder schlichtweg schäbig programmiert. 

Eine andere Auf­fas­sung besagt, dass es immer eine bewusste Entschei­dung sein muss, Tech­nis­che Schulden aufzunehmen – schlechte Pro­gram­mierung oder man­gel­hafte Architek­tur fie­len dann also nicht darunter. Hier wür­den wir kurzfristig und bewusst ein TD akzep­tieren, um ein anderes Ziel, beispiel­sweise einen bevorste­hen­den Releaseter­min, schneller zu erreichen. 

Als Ver­all­ge­meinerung bei­der Sicht­en ließe sich definieren, dass Tech­nis­che Schuld poten­ziell jed­er Zus­tand ein­er Soft­ware ist, der eine naht­lose Weit­er­en­twick­lung ver­hin­dert.

Gründe und Auswirkungen

Aufgeschobene Refactorings

Sobald durch eine anste­hende Erweiterung die Umstruk­turierung beste­hen­der Teile der Soft­ware erforder­lich wird, dro­ht ein Schulden­loch. Ob es sich auf­tut und wir hine­in­fall­en hängt davon ab, ob das Refac­tor­ing durchge­führt wird oder nicht. Wenn ja, ist alles gut – keine TD aufge­baut. Wenn wir es nicht tun, haben wir von dem Moment an eine TD, die mit jedem kom­menden Change Request ihre Zin­sen ein­fordern wird. Der Zins­eszin­sef­fekt ist bekan­ntlich ein expo­nen­tielles Phänomen. Das gilt auch in der Softwareentwicklung.

Häu­fig wird mit der Umset­zung von Erweiterun­gen begonnen, ohne vorher zu prüfen, ob die beste­hende Architek­tur den neuen Anforderun­gen stand­hält. Nötige Refac­tor­ings wer­den so erst spät erkan­nt, wenn über­haupt. Nach zwei oder drei Erweiterungszyklen ist das Dilem­ma oft­mals bere­its so weit fort­geschrit­ten, dass Maß­nah­men zur Behe­bung sehr deut­lich zu Buche schla­gen wür­den. Die Lösung heißt dann allzu oft „Augen zu und durch“ – und so manövri­ert sich das Pro­jekt selb­st immer tiefer in den Schulden­berg hinein. In dieser Phase begin­nen die Schmerzen groß genug zu wer­den, um Aufmerk­samkeit „von oben“, also des Man­age­ments oder des Kun­den zu gewin­nen. Die Frage lautet dann, warum selb­st kleine Fea­ture-Erweiterun­gen „so lange“ dauern. 

Featuritis

Es ist eine Bin­sen­weisheit, dass viele Soft­ware­pro­jek­te mit Bazil­lus Fea­tu­ri­tis infiziert sind. Das giftige Stof­fwech­sel­pro­dukt dieses Erregers ist TD. Eine der Schwierigkeit­en bei der Diag­nose von TD ist die lange Inku­ba­tion­szeit. Während funk­tionale Soft­warefehler meist frühzeit­ig zutage treten, wirken sich TDs eine Zeit lang eher unter­schwellig aus. Wenn ihre unschö­nen Symp­tome wie erschw­erte Wart­barkeit und steigende Defect-Rat­en sich endlich zeigen, ist das Soft­ware­pro­dukt bere­its der­art herun­tergewirtschaftet, dass ein Gegen­s­teuern nicht mehr ohne deut­lichen Mehraufwand zu bew­erk­stel­li­gen ist. Das liegt daran, dass TD ein Aspekt der inneren Soft­ware­qual­ität ist, beziehungsweise ein Man­gel der­sel­ben. Die innere Qual­ität eines Pro­duk­ts ist von außen nicht direkt sicht­bar. Sie wird nur dann wahrgenom­men, wenn sie so dürftig ist, dass sie zu Fehlfunk­tio­nen oder steigen­den Aufwän­den führt.

Das Gesetz von Conway

Nach dem vielz­i­tierten Gesetz von Con­way, englisch Conway‘s Law, entsprechen die Struk­turen eines Soft­waresys­tems zwangsläu­fig denen der Organ­i­sa­tion, die es her­vorge­bracht hat. Ver­schiedene Stu­di­en haben dieses Pos­tu­lat aus den Achtziger­jahren bestätigt. Das bedeutet am konkreten Beispiel, ein zen­tral­is­tisch-hier­ar­chisch organ­isiertes Unternehmen wird sich mit Microser­vice-Architek­turen, wo Dezen­tral­isierung, Ereignis­s­teuerung, Infor­ma­tion­saus­tausch und Entkop­plung eine große Rolle spie­len, ver­mut­lich schw­er­tun. Tech­nis­chen Schulden fall­en in dieselbe Kat­e­gorie. Steile Hier­ar­chien, Führung in Form von Kom­man­dostruk­turen anstatt Ser­vant Lead­er­ship sowie fach­liche und soziale Inkom­pe­tenz begün­sti­gen den Nährbo­den für das Wach­s­tum von TD. 

Wege aus der Schuldenfalle

Schuldeingeständnis

Ist ein Pro­jekt ein­mal in einen Zus­tand tech­nis­ch­er Über­schul­dung einge­treten, gibt es den­noch Wege hin­aus. Sie erfordern im ersten Schritt ein Schuldeingeständ­nis der Beteiligten: Prod­uct-Own­er, Devel­op­ment-Team und Pro­jek­tleitung müssen sich über ihre jew­eili­gen Anteile im Klaren sein und gemein­sam an der Lösung arbeit­en. Ein Coach kann dabei hil­fre­ich sein. Vielle­icht gibt es einen fähi­gen Scrum Mas­ter, der die Parteien dabei unter­stützt, einen gang­baren Weg zu finden.

Schadenanalyse

Sind sich PO, PL/Kunde und Dev-Team einig, kann der neg­a­tive Effekt von TD zumin­d­est abgemildert, manch­mal sog­ar beseit­igt wer­den. Jeden­falls gilt es nun, beherzt zu han­deln. Zunächst muss das Aus­maß der Tech­nis­chen Schulden umris­sen wer­den, damit die Aufwände zu ihrer Behe­bung einge­plant wer­den kön­nen. Nicht sel­ten gibt es hier­bei uner­wartete Ergeb­nisse: mehrere Wochen bis Monate an Kon­so­li­dierungsar­beit­en sind für ein Pro­jekt schw­er zu verkraften. Mut, eine der fünf agilen Tugen­den, ist hier beson­ders gefragt. In ein­er solchen Lage müssen wir uns fol­gen­des immer vor Augen hal­ten: erstens haben wir diesen Zus­tand selb­st verur­sacht, und zwar kollek­tiv auf allen Ebe­nen. Zweit­ens, wenn wir den Mut jet­zt nicht auf­brin­gen, den Zus­tand zu verbessern, wird es später noch härter.

Coaching

Eben­falls schwierig wird es, wenn die oben genan­nten Con­way-Gründe vor­liegen. Dann haben wir es mit einem echt­en Härte­fall zu tun. Unter solchen Umstän­den ist es uner­lässlich, einen erfahre­nen Coach hinzuzuziehen, der Führung und Entwick­lung miteinan­der in Ein­klang brin­gen hilft.

Vorsicht ist besser als Nachsicht: Technische Schulden einplanen

Um die Entste­hung von TD möglichst von vorn­here­in zu ver­hin­dern, gilt es, die dro­hen­den Schulden­löch­er rechtzeit­ig zu erken­nen. Ide­al­er­weise prüfen wir die beste­hende Imple­men­tierung, bevor wir mit der Weit­er­en­twick­lung begin­nen. Das schließt auch die Makroar­chitek­tur mit der Kom­mu­nika­tion zwis­chen beteiligten Sys­te­men mit ein. In diesem Fall kön­nten die Refac­tor­ing-Aufwände bere­its in der Pla­nung berück­sichtigt werden. 

Ver­säu­men wir, eine Vor­analyse durchzuführen oder ist es nicht möglich, kön­nen wir immer noch während der Entwick­lung TDs iden­ti­fizieren. Nun ist zu prüfen, wie wir damit umge­hen wollen.

Die edel­ste Option wäre, die TDs sofort zu beheben und zu akzep­tieren, dass sich der Pla­nung­shor­i­zont entsprechend nach hin­ten ver­schiebt. Das kann eine agile Pro­jek­tor­gan­i­sa­tion leicht verkraften. Im klas­sis­chen Man­age­men­tum­feld kann es jedoch passieren, dass wir damit aller­gis­che Reak­tio­nen aus­lösen. Hier wäre ein Kom­pro­miss, die TD zunächst zu akzep­tieren, um das Fea­ture – not­falls mit Workarounds um die TD herum – plan­mäßig funk­tion­al fer­tigzustellen. Nun aber müssen wir sofort ein Tick­et erstellen, um die TD anschließend so schnell wie möglich ein­pla­nen und auflösen zu kön­nen. Eine gute Release­pla­nung sollte diesen Fall auch im klas­sis­chen Umfeld abfed­ern können. 

Organisatorische Maßnahmen

Qualität mit einplanen

Organ­isatorische Maß­nah­men betr­e­f­fen alle Ebe­nen der Pro­jek­tor­gan­i­sa­tion. Am Ende jedoch läuft es darauf hin­aus, dass die Pro­jek­tleitung für das Gelin­gen oder Scheit­ern Sorge tra­gen muss. Die PL bes­timmt maßge­blich die Pro­jek­tkul­tur, und damit auch, wie mit Her­aus­forderun­gen umge­gan­gen wird, ger­ade wenn sie Geld kosten. Nicht zulet­zt bes­timmt sie, welche Qual­itäts­maßstäbe anzule­gen sind und wie die Sicherung der Soft­ware­qual­ität erfol­gen soll.

Project Staffing

Zunächst ein­mal sollte unser Pro­jekt mit fähi­gen Men­schen aus­ges­tat­tet sein: wir benöti­gen beispiel­sweise ein Prod­uct-Man­age­ment-Team und einen Führungsstab, die wis­sen, wie Soft­wa­reen­twick­lung­sprozesse funk­tion­ieren. Wir brauchen ein Devel­op­ment-Team, das auf dem Stand der Tech­nik und bere­it ist, sich stetig weit­erzuen­twick­eln. Und wir soll­ten einen Pro­jek­t­coach engagieren, beispiel­sweise einen Scrum Mas­ter, der dafür sorgt, dass die Organ­i­sa­tion der Zusam­me­nar­beit im Pro­jekt rund läuft. 

Wenn die Qual­ität­sziele gesteckt sind und das Pro­jekt gut gestafft ist, sind die Grund­la­gen geset­zt. Nun gibt es eine Rei­he von Tools, um die innere Qual­ität des Soft­ware­pro­duk­ts zu gewährleisten.

Architekturwissen vom Elfenbeinturm ins Entwicklerteam 

Eines der wichtig­sten Werkzeuge ist die Fähigkeit des Entwick­lerteams, die Soft­ware mit Hil­fe ein­er zweck­mäßi­gen Makro- und Mikroar­chitek­tur gut zu struk­turi­eren. Dadurch wird die langfristige Wart­barkeit gewährleis­tet, und Tech­nis­che Schulden kön­nen leichter ver­mieden oder behoben werden. 

Eine beliebte Falle ist hier­bei, die Soft­ware-Architek­tur als eine eigene, von der Pro­gram­mier­ar­beit getren­nte Diszi­plin zu betra­cht­en. Es emp­fiehlt sich jedoch vielmehr, dafür zu sor­gen, dass die Entwick­ler über pro­fun­des Architek­tur­wis­sen ver­fü­gen und dieses in ihrer täglichen Arbeit stetig anwen­den. Mit der dazuge­höri­gen Diszi­plin lässt sich dann die Architek­turero­sion in Gren­zen halten.

Poka-Yoke-Entwicklungsprozess – Fehler besser vorher vermeiden statt später beheben

Um durch Unacht­samkeit oder Toll­patschigkeit entste­hende Tech­nis­che Schuld von vorn­here­in zu berück­sichti­gen, emp­fiehlt es sich, den Entwick­lung­sprozess so zu gestal­ten, dass alleine dadurch die Entste­hung von TD bere­its eingeschränkt wird. Dieses Vorge­hen ist als Poka Yoke bekan­nt. Beispiel­sweise imple­men­tieren wir Domain Dri­ven Design als fes­ten Bestandteil des Prozess­es. Dadurch wird sichergestellt, dass Änderun­gen in der Fach­domäne adäquat in der Soft­ware abge­bildet wer­den. Als näch­stes sollte Clean Code gelebt wer­den. Dadurch min­imiert sich das Aufnehmen von Tech­nis­chen Schulden von selb­st. Für den pas­sion­ierten Clean Coder gehört kon­tinuier­lich­es Refac­tor­ing zu den Stan­dard­mit­teln, um ger­ade auch die Tech­nis­chen Schulden klein zu hal­ten. Eben­so sind effek­tiv durchge­führte Codere­views ein fes­ter Bestandteil der Clean-Code-Praxis.

SonarQube für statische Codeanalyse nach der SQALE-Methode

Als tech­nis­ches Tool hat sich in vie­len Pro­jek­ten Sonar­Qube etabliert, das in die Build-Pipeline inte­gri­ert wer­den kann, um mit Hil­fe von sta­tis­ch­er Code­analyse unter anderem das Aus­maß an TD zu bemessen. Dabei wird der Grad der Tech­nis­chen Schuld in Man­nta­gen beziffert. 

Allerd­ings dür­fen wir uns nicht darüber hin­wegtäuschen lassen, dass Sonar­Qube seman­tis­che Qual­ität­skri­te­rien wie Les­barkeit und Ver­ständlichkeit des Source­codes genau­so wenig messen kann wie dessen sach­liche Kor­rek­theit. Wichtige Design­prinzip­i­en wie das Sin­gle Respon­si­bil­i­ty Prin­ci­ple sind eben­falls schw­er automa­tisiert zu prüfen. Daher ist Sonar­Qube zwar eine gute Unter­stützung, sollte jedoch keines­falls als alleinige Quelle der Wahrheit dienen.

Fazit

Fassen wir zusammen:

  • Tech­nis­che Schuld entste­ht laufend während der Entwick­lung. Das ist natür­lich und ganz normal.
  • Obwohl die Tech­nis­che Schuld als Buzz­word in der Soft­wareszene hin­länglich bekan­nt ist, find­en ihre Ursachen und Auswirkun­gen wenig Beach­tung. Allzu oft wer­den sie ignoriert.
  • Die besten Pro­gram­mier­er und Architek­ten kön­nen Tech­nis­che Schulden nicht abwen­den, wenn der Entwick­lung­sprozess und/oder die Unternehmen­skul­tur wirk­same Maß­nah­men konterkarieren.
  • Ein großer Anteil tech­nis­ch­er Schulden lässt sich bere­its durch rein organ­isatorische Maß­nah­men unterbinden. Neben ein­er fähi­gen Pro­jek­t­mannschaft müssen somit auch kul­turelle und prozes­suale Voraus­set­zun­gen geschaf­fen werden.
  • Soft­ware­pro­jek­t­coach­ing ist ein pro­bates Mit­tel, um die Ver­schul­dung von Anfang an klein zu hal­ten, oder ein Soft­ware­pro­jekt aus der TD-Sack­gasse herauszuführen.

In diesem Sinne, hap­py engineering 🙂

Wikipedia: Tech­nis­che Schulden