Die Vorteile von Featureteams

Agile Metho­den und ins­be­son­de­re Scrum sehen bei einem klei­nen Pro­dukt mit einem ein­zi­gen Team ganz ein­fach aus. Sobald meh­re­re Teams an einem Pro­dukt arbei­ten, muss die Arbeit irgend­wie auf­ge­teilt wer­den. Der nahe­lie­gen­de, weil bekann­te, Ansatz ist es, das Pro­dukt mehr oder weni­ger logisch und sinn­voll in Kom­po­nen­ten zu zer­le­gen und die­se mit Kom­po­nen­ten­teams zu beset­zen. Aus Sicht des Kun­den sind die­se Kom­po­nen­ten aller­dings völ­lig irrele­vant. Im bes­ten Fall merkt er davon gar nichts. In den meis­ten Fäl­len aller­dings schon, weil zwi­schen sei­nem Nut­zen und den dafür not­wen­di­gen Funk­tio­nen des Pro­dukts in der Regel meh­re­re Kom­po­nen­ten­gren­zen und damit Über­ga­ben oder Abstim­mun­gen zwi­schen Teams ste­hen, die den Fluss unter­bre­chen. Schö­ner wäre es aus Kun­den­sicht, wenn die neue Funk­ti­on, das Fea­ture, von einem ein­zi­gen soge­nann­ten Fea­ture-Team umge­setzt wür­de ganz egal wel­che Kom­po­nen­ten betrof­fen sind.

Jeder der schon mal ein Haus gebaut oder reno­viert hat kennt das gut. Eigent­lich will man „nur“ Son­nen­schutz an den Fens­tern anbrin­gen las­sen. Lei­der geht das oft nicht aus einer Hand, son­dern erfor­dert neben dem Hand­wer­ker, der den eigent­li­chen Son­nen­schutz mon­tiert, einen Elek­tri­ker, der die Strom­ka­bel legt, einen Mau­rer, der alles ver­putzt und einen Maler, der alles wie­der streicht. Der Wert­strom von der Idee bis zum Nut­zen ist mehr­fach durch Über­ga­ben unter­bro­chen und muss mehr oder weni­ger auf­wän­dig (vom Bau­herrn) abge­stimmt und koor­di­niert wer­den. Wie viel unkom­pli­zier­ter und schnel­ler wäre es, den Son­nen­schutz mit allem was dazu zu tun ist ein­fach bei einem ein­zi­gen Hand­wer­ker beauf­tra­gen zu kön­nen! Genau das ist der Unter­schied aus Kun­den­sicht zwi­schen Kom­po­nen­ten­teams (die spe­zia­li­sier­ten Hand­wer­ker mit ihren jewei­li­gen Teil­auf­trä­gen) und Fea­tureteams (ein Team das den Auf­trag kom­plett abar­bei­tet egal wel­che Fähig­kei­ten dazu not­wen­dig sind).

component-vs-feature-teams.png

Da Kun­den­ori­en­tie­rung ein wesent­li­ches Prin­zip von Agi­li­tät ist, sind Kom­po­nen­ten­teams zwar die ein­fa­che­re, aber nur die zweit­bes­te Lösung, um die Arbeit an einem gro­ßen Pro­dukt auf­zu­tei­len. Egal wie die Kom­po­nen­ten geschnit­ten wer­den, es blei­ben die Über­ga­ben und die Koor­di­na­ti­on zwi­schen den Kom­po­nen­ten, um dem Kun­den sei­nen Nut­zen zu bie­ten. Zwar sind man­che Schnit­te sicher­lich bes­ser als ande­re. Der oft­mals in Soft­ware-Pro­duk­ten übli­che Schnitt in hori­zon­ta­le Schich­ten wie Front­end, Backend und Daten­bank ist zwar ganz prak­tisch für die jewei­li­gen Exper­ten. Aber aus Sicht des Kun­den ist die­ser Schnitt extrem unbe­frie­di­gend, weil jede nicht-tri­via­le Anfor­de­rung sich durch alle Schich­ten zie­hen wird und damit lang­sa­me und feh­ler­an­fäl­li­ge Über­ga­ben zur Fol­ge hat. Bes­ser sind ver­ti­ka­le Schnit­te die das Pro­dukt in logisch abge­schlos­se­ne Teil­pro­duk­te zer­le­gen. So wird ein Waren­wirt­schafts­sys­tem aus wenigs­tens den Kom­po­nen­ten Ein­kauf, Lager­hal­tung und Ver­kauf bestehen. Den­noch wird es auch hier Anfor­de­run­gen geben, die sich nicht auf eine Kom­po­nen­te beschrän­ken und dann wie­der koor­di­niert wer­den müssen.

Orga­niz­a­ti­ons which design sys­tems […] are cons­trai­ned to pro­du­ce designs which are copies of the com­mu­ni­ca­ti­on struc­tures of the­se organizations.
Conway’s Law benannt nach Mel­vin E. Conway

Unab­hän­gig vom Schnitt füh­ren Kom­po­nen­ten­teams zur Bil­dung von Silos, weil sich jedes Team nur für sei­nen Aus­schnitt des Pro­dukts ver­ant­wort­lich füh­len wird. Ver­stärkt wird die­ser Effekt durch das Gesetz von Con­way wonach „die Struk­tu­ren von Sys­te­men durch die Kom­mu­ni­ka­ti­ons­struk­tu­ren der sie umset­zen­den Orga­ni­sa­tio­nen vor­be­stimmt sind“ (Wiki­pe­dia). Orga­ni­sa­tio­nen ten­die­ren also dazu Sys­tems so zu schnei­den, dass sie der Orga­ni­sa­ti­ons- und Kom­mu­ni­ka­ti­ons­struk­tur ähneln. Wenn also der ver­ti­ka­le Kom­po­nen­ten­schnitt die­ser Orga­ni­sa­ti­ons­struk­tur folgt und mit Teams der jewei­li­gen Orga­ni­sa­ti­ons­ein­hei­ten besetzt wird, zemen­tiert das nur die Mau­ern der ohne­hin schon vor­han­de­nen Silos.

Fea­tureteams, also Teams die eine Kun­den­an­for­de­rung von der Idee bis zum rea­li­sier­ten Nut­zen egal in wel­cher Kom­po­nen­te des Pro­dukts umset­zen kön­nen, sind sicher­lich die bes­se­re Wahl. Aus Kun­den­sicht sowie­so, aber auch auch aus Sicht der Orga­ni­sa­ti­on. Da Kom­po­nen­ten­teams nur in ihrer Kom­po­nen­te arbei­ten kön­nen erfor­dert es immer einen nicht gerin­gen Pla­nungs­auf­wand, damit die­se Teams immer opti­mal aus­ge­las­tet wer­den, weil nicht jede Anfor­de­rung gleich viel Auf­wand je Kom­po­nen­te haben wird. Fea­tureteams bedin­gen aber eine hohe Rei­fe der Orga­ni­sa­ti­on, weil hier das Pro­dukt von allen gemein­sam gestal­tet und ver­ant­wor­tet wird. Orga­ni­sa­tio­nen die es bis­her gewohnt waren, Arbeit in kleins­te Schrit­te zu zer­le­gen und Men­schen in star­re Rol­len in defi­nier­ten Pro­zes­sen zu zwän­gen, wer­den sich hier anfangs gro­ße Schwie­rig­kei­ten haben. Es emp­fiehlt sich, dem Prin­zip Shu-Ha-Ri fol­gend, mit klei­nen Pro­duk­ten mit jeweils einem Team zu star­ten und dabei die Hal­tung und Prin­zi­pi­en von Agi­li­tät zu ver­in­ner­li­chen. Dann kann man sich an grö­ße­re Pro­duk­te mit ver­ti­ka­len Kom­po­nen­ten­teams wagen und nach und nach ein­zel­ne Teams zu Fea­tureteams ausbauen.

Teile diesen Beitrag

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

4 Kommentare

Hal­lo Marcus,
Du schöpfst mit Dei­nen Bei­spie­len ger­ne aus unse­rer täg­li­chen Arbeits­pra­xis und den Dis­kus­sio­nen in der Com­mu­ni­ty unse­res gemein­sa­men Arbeitsgebers.
Es wäre schön wenn die Erkennt­nis­se, die auch in vie­len ande­ren Foren zu fin­den sind, bei uns schnel­ler auf­ge­nom­men wür­den. Aber wahr­schein­lich gehört es eben auch zum Ler­nen jeder ein­zel­nen Orga­ni­sa­ti­on, alle Feh­ler zu wie­der­ho­len. Dass durch feh­len­de Ver­net­zung gros­se Orga­ni­sa­tio­nen – bestehend aus vie­len klei­nen Orga­ni­sa­tio­nen – schlecht bis nicht ler­nen haben wir bei­de ja bereits vor Mona­ten besprochen.
Wenn die­se Din­ge immer mehr zum Ärger­nis in der täg­li­chen Arbeit wer­den, was kann man dann tun?
Magst Du nicht einen Arti­kel schrei­ben über Frust­be­wäl­ti­gung anläss­lich einer agi­len Trans­for­ma­ti­on? Auch wenn ich weiss dass alle mit­ge­nom­men wer­den müs­sen ist es doch frus­trie­rend, dass aus­ge­rech­net die lang­sams­ten die Geschwin­dig­keit bestim­men sollen…

Lie­ber Micha­el, das wäre in der Tat schön, wenn das Ler­nen schnel­ler vor­an gin­ge. Ein Rezept zur Frust­be­wäl­ti­gung habe ich lei­der auch nicht. Ich hal­te es mitt­ler­wei­le mit Götz W. Wer­ner und sei­nem Mot­to: „Beharr­lich im Bemü­hen, beschei­den in der Erfolgserwartung.“

Ste­hen Fea­tureteams nicht grund­sätz­lich im Kon­flikt mit der ursprüng­li­chen Defi­ni­ti­on von Scrum Teams?

Ein wesent­li­cher Aspekt eines Scrum Teams ist die Selbst­or­ga­ni­sa­ti­on. Task/Stories erle­di­gen zu kön­nen, ohne dabei von ande­ren Teams abhän­gig zu sein. Denn die­se Abhän­gig­keit bedeu­tet immer Rei­bungs­ver­lus­te. Bei Fea­tureteams müs­sen meh­re­re Teams ihre Ände­run­gen an der­sel­ben Kom­po­nen­te koor­di­nie­ren. Im schlimms­ten Fall ste­hen die Anfor­de­run­gen, die ver­schie­de­ne Teams umsetz­ten müs­sen, sogar im Kon­flikt zuein­an­der. Die Gefahr besteht, dass inner­halb einer Kom­po­nen­te noch­mals ver­ti­ka­le Silos ent­ste­hen – um die­se Kon­flik­te zwi­schen ver­schie­de­nen Teams zu umgehen. 

Nach mei­ner Inter­pre­ta­ti­on von Con­ways Law, soll­te man genau des­halb die­se Situa­ti­on ver­mei­den. Im Wesent­li­chen sagt die­ses ja aus, dass um Teams auto­ma­tisch Silos ent­ste­hen wer­den. Dar­um soll­ten auch Teams, Kom­po­nen­ten und Orga­ni­sa­ti­ons-Struk­tur kor­re­lie­ren, damit dar­aus mög­lichst weni­ge Kon­flik­te entstehen.

Kom­me ich regel­mä­ßig in die Situa­ti­on Fea­tures über meh­re­re Teams ver­brei­ten zu müs­sen, dann deu­tet das mei­ner Mei­nung auf ein Archi­tek­tur-Pro­blem hin. Die Silos kor­re­lie­ren nicht mit den Anfor­de­run­gen. Die Ver­let­zung des Sin­gle-Repon­si­bi­li­ty-Prin­zips führt genau zu sol­chen Pro­ble­men. Ziel soll­te es sein die­ses Pro­blem zu beheben.

Span­nen­de Gedan­ken. Wie immer kommt es drauf an. Natür­lich ist es toll, wenn jedes Team seins hat und es eine kla­re Ver­ant­wor­tung gibt. Dar­un­ter lei­det aber auch die Fle­xi­bi­li­tät und letzt­lich die Wert­schöp­fung. Was pas­siert näm­lich, wenn in einer Kom­po­nen­te mal weni­ger zu tun ist und umge­kehrt an einem ande­ren Eck mehr zu tun wäre um die wirk­lich wich­ti­gen Sachen umzu­set­zen? Dann macht jedes Team immer noch seins und das führt dazu, dass auch an Sachen gear­bei­tet wird, die glo­bal gese­hen nicht so wich­tig wären.

Ich sehe auch kei­nen Wider­spruch zur Selbst­or­ga­ni­sa­ti­on. Die beinhal­tet doch auch die Koor­di­na­ti­on mit ande­ren Teams.

Schreibe einen Kommentar