Erst das Problem, dann die Lösung!

Agi­le Frame­works sind Samm­lun­gen von ver­all­ge­mei­ner­ten Lösun­gen für typi­sche Pro­ble­me in agi­len Orga­ni­sa­tio­nen. Die Anwen­dung die­ser Lösun­gen wirkt dann am bes­ten, wenn das Pro­blem nicht nur theo­re­tisch ver­stan­den, son­dern real erlebt wur­de. Eine agi­le Trans­for­ma­ti­on ist kei­ne Ein­füh­rung eines Frame­works, son­dern eine gemein­sa­me Rei­se auf der Pro­ble­me ent­deckt und – mit Hil­fe der bekann­ten Frame­works – gelöst werden. 

Sehr zum Leid­we­sen mei­ner Frau bin ich kein guter Heim­wer­ker. Trotz­dem fas­zi­nie­ren mich Werk­zeu­ge. Hübsch auf­ge­reiht in unglaub­li­cher Viel­falt prei­sen sie ihre unbe­streit­ba­re Nütz­lich­keit im Bau­markt an. Und gele­gent­lich ver­lei­ten sie mich zum Kauf für den Fall, dass ich irgend­wann Ver­wen­dung dafür hät­te. Die­ser Fall tritt frei­lich nie ein oder oder wenn er ein­tritt, habe ich das Werk­zeug längst ver­ges­sen (mei­ne Frau behaup­tet zwar auch, das lie­ße sich durch Ord­nung im Werk­zeug­kel­ler ver­mei­den, aber das ist eine ande­re Geschichte). 

So ähn­lich ver­hält es sich mit der Viel­falt an agi­len Frame­works wie das Sca­led Agi­le Frame­work (SAFe), LeSS, Nexus oder das Spo­ti­fy-Modell. Die gibt es zwar nicht im Bau­markt, aber jede Bera­tungs­fir­ma hat der­lei im Ange­bot. Und auch hier wer­den Kun­den zum Kauf eines Modells und den dar­in ent­hal­te­nen Werk­zeu­gen und Prak­ti­ken ver­lei­tet. Nicht sel­ten ist das dann aller­dings eher ein vor­sorg­li­cher und theo­re­tisch moti­vier­ter Kauf so wie bei mir im Bau­markt. Man hat nicht wirk­lich alle Pro­ble­me ver­stan­den, für die die­se Model­le Lösun­gen bereit­hal­ten, aber sie sehen sehr prak­tisch und nütz­lich aus.

Alle die­se Frame­works ent­hal­ten gute Lösun­gen, die aber zu den Pro­ble­men der Orga­ni­sa­ti­on pas­sen müs­sen. Die­se Pro­ble­me müs­sen aber zual­ler­erst ver­stan­den und im prak­ti­schen All­tag vor­han­den sein. Dar­um plä­die­re ich stets dafür die agi­le Trans­for­ma­ti­on groß zu den­ken, klein zu star­ten und auf dem Weg schnell zu ler­nen. Wer klein star­tet, bei­spiels­wei­se mit einem oder zwei Scrum-Teams, und dann die Akti­vi­tä­ten nach und nach aus­wei­tet kommt unwei­ger­lich an die­sen Pro­ble­men vor­bei und ver­steht dann auch die Lösun­gen, wel­che die ver­schie­de­nen Frame­works dafür bereithalten.

Zuerst tritt auf die­ser Rei­se typi­scher­wei­se das Pro­blem auf, wie die Arbeit meh­re­rer Teams an einem gemein­sa­men Pro­dukt koor­di­niert wer­den kann. Die nahe­lie­gen­de und sehr klas­si­sche Lösung ist es, hier­ar­chisch das Pro­dukt in Kom­po­nen­ten zu zer­le­gen, an denen dann ein dedi­zier­tes Team arbei­tet. Die Koor­di­na­ti­on erfolgt dann meist durch den Pro­duct-Owner, der dafür sor­gen muss, dass je Sprint ein stim­mi­ges Gan­zes ent­steht. In die­sem Ansatz wird der Pro­duct-Owner schnell zum Eng­pass und sei­ne eigent­lich Arbeit an der Zukunft des Pro­dukts und mit den Sta­ke­hol­dern wird teil­wei­se ver­drängt durch die Arbeit der Koor­di­na­ti­on die­ser Komponententeams.

Ähn­lich schwer wiegt das Pro­blem, dass die­se Teams glo­bal gese­hen aus Grün­den der Aus­las­tung nicht immer an den für das Pro­dukt wich­tigs­ten Din­gen arbei­ten. Die Arbeit wird nur sel­ten gleich­mä­ßig über alle Kom­po­nen­ten des Pro­dukts ver­teilt sein und daher wird das Team für bei­spiels­wei­se die Kom­po­nen­te der Nut­zer­ver­wal­tung an Din­gen arbei­ten, die eigent­lich im Moment, glo­bal betrach­tet, kei­ne Prio­ri­tät haben, weil der Fokus auf der Über­ar­bei­tung des Shops liegt. Dabei kann das Team für die Nut­zer­ver­wal­tung aber lei­der nicht hel­fen, weil es eine ande­re Kom­po­nen­te ist.

Die­se Pro­ble­me lösen dann Fea­tureteams, deren Wir­kungs­be­reich sich eben nicht auf eine Kom­po­nen­te des Pro­dukts beschränkt, son­dern die viel­mehr in der Lage sind, eine Anpas­sung, ein Fea­ture, über alle Kom­po­nen­ten hin­weg Ende-zu-Ende umzu­set­zen. Auch die­se Teams müs­sen sich koor­di­nie­ren, aber dafür reicht in der Regel ein gemein­sa­mes Sprint-Plan­ning und ein regel­mä­ßi­ges Scrum of Scrums wäh­rend des Sprints. Die­ses Modell erfor­dert aller­dings eine höhe­re Rei­fe der Teams, die natür­lich mehr über das gesam­te Pro­dukt wis­sen müs­sen, um dar­in Anpas­sung vor­neh­men zu kön­nen. Das höhe­re Maß an Owners­hip, näm­lich in Bezug auf das gan­ze Pro­dukt und nicht nur zu einer Kom­po­nen­te, führt zu einem höhe­ren Grad der Selbst­or­ga­ni­sa­ti­on und ent­las­tet den Pro­duct-Owner von koor­di­na­ti­ven Aufgaben.

Es kommt also bereits bei die­ser ele­men­ta­ren Form der Ska­lie­rung, meh­re­re Teams an einem Pro­dukt, ganz wesent­lich dar­auf an, wie die Arbeit auf­ge­teilt wird. Wer hier die ver­trau­te Auf­tei­lung in Kom­po­nen­ten wählt und dazu in der Metho­den­kis­te von SAFe ein „Pro­gram Incre­ment Plan­ning“ (PI-Plan­ning) fin­det, löst zwar vor­der­grün­dig das Pro­blem der Ver­wal­tung von Abhän­gig­kei­ten, packt es aber eben nicht an Wur­zel an.

Wenn nun nicht nur ein Pro­dukt, son­dern meh­re­re Pro­duk­te in einem Port­fo­lio in ihrer jewei­li­gen Wei­se agil arbei­ten stellt sich aber­mals die Fra­ge nach Koor­di­na­ti­on und gemein­sa­mer Aus­rich­tung, nun aller­dings auf höhe­rer, stra­te­gi­scher Ebe­ne. Hier könn­ten dann bei­spiels­wei­se Objec­ti­ves and Key-Results zum Ein­satz kom­men, um einer­seits den Pro­duk­ten eine gemein­sa­me stra­te­gi­sche Aus­rich­tung zu geben ohne sie ande­rer­seits zu sehr in ihrer Auto­no­mie zu beschrän­ken. Auch in SAFe fin­den sich hier­zu Ant­wor­ten auf der Port­fo­lio-Ebe­ne (und auch in Form des PI-Plan­nings) und in gewis­ser Wei­se sind die Tri­bes im Spo­ti­fy-Modell auch eine Lösung für die­ses Pro­blem. Vie­le Wege füh­ren nach Rom. Ent­schei­dend ist aber, dass nach der Lösung aus­ge­hend von einem prak­tisch auf­tre­ten­den Pro­blem gesucht wird und nicht vor­sorg­lich oder aus theo­re­ti­scher Fas­zi­na­ti­on für die Metho­dik auf bun­ten Folien.

Wenn schließ­lich vie­le Teams agil arbei­ten über meh­re­re Pro­duk­te hin­weg, drängt die Fra­ge nach gemein­sa­men Stan­dards bei­spiels­wei­se für den Betrieb der Pro­duk­te, für die Archi­tek­tur, für Con­ti­nuous Inte­gra­ti­on / Con­ti­nuous Deploy­ment oder für Secu­ri­ty, um nur die nahe­lie­gen­den zu nen­nen. Die pri­mä­re Orga­ni­sa­ti­ons­struk­tur ori­en­tiert sich rich­ti­ger­wei­se an den Pro­duk­ten, denn die Mit­ar­bei­ter sol­len sich pri­mär ihrem Pro­dukt und der Wert­schöp­fung beim Kun­den zuge­hö­rig füh­len (idea­ler­wei­se in einem Fea­tureteam, weil sie sich sonst pri­mär der Kom­po­nen­te zuge­hö­rig füh­len). Spe­zia­lis­ten­si­los in der Orga­ni­sa­ti­on für die­se quer­schnitt­li­chen Aspek­te sind also in die­sem Sin­ne kei­ne gute Lösung. Hier kom­men nun quer zur pri­mä­ren Pro­dukt­or­ga­ni­sa­ti­on Com­mu­nities of Prac­ti­ce, Chap­ters oder Gil­den je nach bevor­zug­tem Frame­work ins Spiel. Ihre Auf­ga­be ist immer die­sel­be: Eine gemein­sa­me Exper­ti­se (IT-Betrieb, Secu­ri­ty, Archi­tek­tur, etc.) aus­zu­bau­en, zu pro­fes­sio­na­li­sie­ren und auch zu standardisieren.

Die­se Lis­te von typi­schen Pro­ble­men und die ange­bo­te­nen Lösun­gen in agi­len Frame­works lie­ße sich noch län­ger fort­set­zen. Es geht mir aber gar nicht dar­um, das The­ma erschöp­fend zu behan­deln oder gar eine Art Meta-Modell der agi­len Frame­works zu erstel­len. Alle Frame­works ent­hal­ten gute Lösun­gen. So wie es eben im Bau­markt gute Werk­zeu­ge gibt. Um die­se erfolg­reich anwen­den zu kön­nen, muss man aber das rich­ti­ge Pro­blem haben und die­ses Pro­blem rich­tig ver­stan­den haben. Zudem haben alle Lösun­gen auch Neben- und Wech­sel­wir­kun­gen und manch­mal brau­chen die­se Lösun­gen auch bestimm­te Vor­aus­set­zun­gen zur erfolg­rei­chen Anwendung.

It is no lon­ger suf­fi­ci­ent to have one per­son lear­ning for the orga­niz­a­ti­on, a Ford or a Slo­an or a Wat­son or a Gates. […] The orga­niz­a­ti­ons that will tru­ly excel in the future will be the orga­niz­a­ti­ons that dis­co­ver how to tap people’s […] capa­ci­ty to learn at all levels in an organization.

Peter Sen­ge, The Fifth Discipline

Die fixe Idee, ein­fach ein erprob­tes Modell aus­zu­wäh­len und aus­zu­rol­len wird daher nicht mit Erfolg gekrönt sein, son­dern hat das Poten­ti­al, das gewähl­te agi­le Frame­work und das Kon­zept von Agi­li­tät im All­ge­mei­nen zu ver­bren­nen. Sinn­vol­ler erscheint es mir, sich nach und nach, gleich­sam vom Klei­nen ins Gro­ße, gemein­sam das Pro­blem­ver­ständ­nis zu erar­bei­ten und davon aus­ge­hend Lösun­gen zu fin­den – in den bekann­ten Frame­works und dar­über­hin­aus. Ent­schei­dend dafür ist eine angst­freie Lern­kul­tur und die aus dem Lean Manage­ment stam­men­de fun­da­men­ta­le agi­le Prak­tik der kon­ti­nu­ier­li­chen Ver­bes­se­rung, bei­spiels­wei­se in Form von Retro­spek­ti­ven in Scrum. Das ist das trag­fä­hi­ge Fun­da­ment einer leben­di­gen agi­len Orga­ni­sa­ti­on. Es ist gar nicht nötig, mit dem bes­ten Frame­work zu star­ten; ein guter Anfang reicht völ­lig, solan­ge auf dem Weg kon­se­quent gemein­sam gelernt wird. 

Pho­to by Nata­li­no D’A­ma­to on Unsplash

Teile diesen Beitrag

Schreibe einen Kommentar