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­tur­eteams (ein Team das den Auf­trag kom­plett abar­bei­tet egal wel­che Fähig­kei­ten dazu not­wen­dig sind).

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­niza­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.
Con­way’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­tur­eteams, 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­tur­eteams 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­tur­eteams ausbauen.