qualität

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:

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