Erst das Problem, dann die Lösung!

Agile Frameworks sind Sammlungen von verallgemeinerten Lösungen für typische Probleme in agilen Organisationen. Die Anwendung dieser Lösungen wirkt dann am besten, wenn das Problem nicht nur theoretisch verstanden, sondern real erlebt wurde. Eine agile Transformation ist keine Einführung eines Frameworks, sondern eine gemeinsame Reise auf der Probleme entdeckt und – mit Hilfe der bekannten Frameworks – 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 Stake­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­tur­eteams, 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 Owner­ship, 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­tur­eteam, 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­ni­ties 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­niza­ti­on, a Ford or a Slo­an or a Wat­son or a Gates. […] The orga­niza­ti­ons that will tru­ly excel in the future will be the orga­niza­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 Uns­plash



Share This Post

Schreibe einen Kommentar