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üs­sen.

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 orga­niz­a­ti­ons.
Conway’s Law benannt nach Mel­vin E. Con­way

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 aus­bau­en.

Auf dem Laufenden bleiben

Du willst kei­nen Arti­kel mehr ver­pas­sen? Mit mei­nem News­let­ter bekommst du in der Regel ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

4 Kommentare

Hal­lo Mar­cus,
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 Arbeits­ge­bers.
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 bespro­chen.
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 sol­len…

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 Erfolgs­er­war­tung.“

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 umge­hen.

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 ent­ste­hen.

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 behe­ben.

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