Wie viel Agilität und wenn ja, wozu?

Auch Was­ser­fall ist agil. Die Schlei­fen in denen ein Pro­dukt ent­steht sind nur viel län­ger. Nach jeder Schlei­fe trifft ein Ergeb­nis auf einen Kun­den. Dann zeigt sich der Nut­zen oder eben nicht und es kann der Kurs kor­ri­giert wer­den. Bei Scrum alle zwei bis vier Wochen, bei klas­sisch Was­ser­fall eher nur zwei­mal im Jahr mit ent­spre­chend höhe­rem Auf­wand und Risi­ko. Bei­des kann je nach Pro­jekt und Kon­text ange­mes­sen sein. Es kommt ein­fach dar­auf an, wie anpas­sungs­fä­hig und reak­ti­ons­fä­hig ein Pro­jekt sein will und muss.

Die Grund­satz­fra­ge agil oder klas­sisch lässt sich lan­ge und lei­den­schaft­lich dis­ku­tie­ren. Genau­so gut könn­te man aber dis­ku­tie­ren, ob Was­ser mit 0 oder 100 Grad Cel­si­us bes­ser ist. Es kommt dar­auf an. Will man Nudeln kochen braucht man kochen­des Was­ser, aber zum Blan­chie­ren von grü­nen Boh­nen Eis­was­ser. Espres­so braucht 90 Grad, grü­ner Tee 70 Grad und zum Baden soll­ten es bes­ser um die 38 Grad sein. Es kommt ganz auf den Zweck an.

Agil bedeu­tet wen­dig. Wen­dig­keit ist aber kein Selbst­zweck, viel­mehr bestimmt der Kon­text des Pro­jekts das not­wen­di­ge Maß an Wen­dig­keit und Anpas­sungs­fä­hig­keit. Je kom­ple­xer und unsi­che­rer das Vor­ha­ben, des­to agi­ler soll­te es ange­gan­gen wer­den. Nur geste­hen sich die Unsi­cher­heit nur die wenigs­ten ehr­lich ein. Schon gar nicht wenn die Pla­nungs- und Geneh­mi­gungs­pro­zes­se im Vor­feld des Pro­jekts von Plan­bar­keit und Schein­ge­nau­ig­keit geprägt sind.

Je plan­mä­ßi­ger die Men­schen vor­ge­hen, des­to wirk­sa­mer trifft sie der Zufall.
Fried­rich Dürrenmatt

Selbst wenn die Unsi­cher­heit und Kom­ple­xi­tät rich­tig ein­ge­schätzt wird und ein agi­les Vor­ge­hen gewählt wird, bleibt die Anpas­sungs­fä­hig­keit beschränkt durch Abhän­gig­kei­ten zu ande­ren Pro­zes­sen und Sys­te­men. Selbst in kur­zen Abstän­den poten­ti­ell aus­lie­fer­ba­re Soft­ware her­vor­zu­brin­gen ist das Eine, Schnitt­stel­len­part­ner und Daten­quel­len in halb­jähr­li­chen Release­zy­klen sind näm­lich das Ande­re. Durch Simu­la­ti­on der noch nicht vor­han­de­nen Schnitt­stel­len lässt sich auch das teil­wei­se lösen, ver­schlech­tert sich auto­ma­tisch die Qua­li­tät der im Kon­takt mit dem Kun­den gewon­nen Erkenntnisse.

Unter­schei­de ohne zu tren­nen, ver­bin­de ohne zu egalisieren.
Her­bert Pietschmann

Eine Dis­kus­si­on über die bei­den Pole agil und klas­sisch ist also nur inso­fern sinn­voll, als sie die Ska­la absteckt, Unter­schie­de und Varia­ti­ons­brei­te her­aus­ar­bei­tet. Kei­nes­falls soll­te die­se Dich­to­to­mie aber insti­tu­tio­na­li­siert wer­den wie es der­zeit mit dem Hype der soge­nann­ten bimo­da­len IT pas­siert und zu Recht von vie­len kri­tisch gese­hen wird.

Break down bar­ri­ers bet­ween depart­ments. Peop­le in rese­arch, design, sales, and pro­duc­tion must work as a team.
W. Edwards Deming

Die ent­schei­den­de Fra­ge lau­tet also nicht, agil oder klas­sisch, son­dern viel­mehr, wie agil das Pro­jekt, Pro­dukt oder „die IT“ ins­ge­samt sein soll, darf oder muss. Neben der ehr­lich ein­ge­schätz­ten Unsi­cher­heit spielt bei die­ser Ent­schei­dung das Ver­trau­en der Betei­lig­ten zuein­an­der eine ganz wesent­li­che Rol­le. Wo die Kul­tur und Zusam­men­ar­beit eher durch Angst, Absi­che­rung und Schuld­zu­wei­sun­gen geprägt ist, wird aus einer nega­ti­ven Rück­mel­dung der Kun­den schnell Kri­tik. Anstatt gemein­sam und ver­trau­ens­voll aus dem Irr­tum zu ler­nen und die Rich­tung zu ändern, wird nach einem Schul­di­gen gesucht. Das führt zu noch mehr Miss­trau­en und Absi­che­rung und damit zu noch län­ge­ren und ins­ge­samt wenig lehr­rei­chen Feed­back­schlei­fen. Angst und Agi­li­tät pas­sen eben nicht gut zusammen.

Suc­cess is not final, fail­u­re is not fatal: it is the cou­ra­ge to con­ti­nue that counts.
Win­s­ton Chrurchill

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.

12 Kommentare

100% Zustim­mung. Ein m.E. wich­ti­ger zusätz­li­cher Aspekt: Die Labels allei­ne hel­fen nicht. Ich (Agi­list, also 100° C ;) ken­ne zahl­rei­che Imple­men­tie­run­gen von Agi­le, die nicht agil sind in Wesen und Kern. Und vie­les, was sich Was­ser­fall nennt, ist nur hirn­lo­ses Pla­nen ohne Blick auf die Rea­li­tät. Wer die Werk­zeu­ge anwen­det ohne Ver­ständ­nis u. Selbst­kri­tik, der hat immer schlech­te Kar­ten, den­ke ich, egal, was er/sie macht.

Dan­ke für Dei­ne Zustim­mung und Ergän­zung, Sascha. Gera­de um die­se ein­fäl­ti­ge Benut­zung der Labels geht es mir: Wir müs­sen erst ver­ste­hen, was das Pro­jekt sinn­vol­ler­wei­se braucht und dann kom­pe­tent ent­schei­den, wie wir die Arbeit pas­send orga­ni­sie­ren. Das ist natür­lich um eini­ges schwie­ri­ger als Koch­re­zep­te anzu­wen­den, dar­um ret­ten sich ja so vie­le in mög­lichst grif­fi­ge Labels. Und hirn­lo­ses Pla­nen in Schein­ge­nau­ig­keit macht so und so kei­nen Sinn.

Da waren sie wie­der, mei­ne Reiz­wor­te: Klas­sisch und Was­ser­fall in einem Satz. :-)

Pro­jekt­mä­ßig bin ich sicher eher der „Warm­du­scher“ bei 42°C, also eher gemä­ßigt agil. Anders gesagt: Klas­si­sches PM im Anlagenbau.
Soweit die Blö­de­lei im Kontext.

Daß das Aus­maß an Agi­li­tät, bzw. bes­ser das sorg­fäl­ti­ge Abwä­gen zwi­schen Wen­dig­keit und Ste­tig­keit eine gro­ße Rol­le im Pro­jekt spielt, hast Du hier sehr tref­fend beschrieben.
In jedem Pro­jekt sind (idea­ler­wei­se, im Übri­gen abwei­chend von fast allen Vor­ga­ben der ISO9000) neue Regeln zu ver­ein­ba­ren und regel­mä­ßig zu überprüfen.

In den Pro­jek­ten, die ich ken­ne, pas­siert das meist im Tur­nus von etwa 4 Wochen. Neben Design Reviews, in denen die Ergeb­nis­se von Engi­nee­ring­ar­bei­ten bespro­chen und frei­ge­ge­ben wer­den, fin­det in die­sem Takt auch meist ein detail­lier­tes Pro­jekt­sta­tus­ge­spräch (eigtl ein Team­ge­spräch, bei dem alle Betei­lig­ten die tech­ni­schen und orga­ni­sa­to­ri­schen Details abstim­men) zwi­schen Kun­de und Lie­fe­rant statt; je nach Bedarf wird die­ser Takt aber auch angepaßt.

Aktu­ell fin­det das Gespräch wöchent­lich statt, inklu­si­ve Durch­spra­che der Ergeb­nis­se bzw. Pro­duk­te der letz­ten Woche.
In Inbe­trieb­nah­me- bzw. Go-Live-Pha­sen sicher nicht ungewöhnlich.

Übri­gens bei den Che­mie­pro­jek­ten in der hei­ßen Pha­se täg­lich: Nach­be­spre­chung Vor­tag, Pla­nung des aktu­el­len Tages, Vor­schau auf die Woche. Län­ge­re Pla­nung ergibt in die­ser Pha­se kei­nen Sinn, da zuviel pas­siert und ‑Ihr ahnt es- Wen­dig­keit gefragt ist. (Von agil spricht da übri­gens nie­mand. Der Begriff kam erst lan­ge nach die­ser Erkennt­nis auf.)

Letzt­lich muß ich die Tak­tung aber auch an den Pro­jekt­in­halt anpas­sen. Ich kann so agil arbei­ten wol­len wie ich mag – wenn das Pro­jekt nun mal meh­re­re Wochen braucht, um über­haupt Reak­tio­nen auf Steue­rungs­maß­nah­men zu zei­ti­gen, lau­fe ich Gefahr, in Hek­tik zu ver­fal­len, weil schein­bar lan­ge nichts Inter­es­san­tes passiert.
Da ist es bes­ser, auch pro­zes­su­al Ruhe zu bewah­ren und lie­ber in grö­ße­ren Schrit­ten zu den­ken und zu fühlen.

Die gewon­ne­ne Hirn­ka­pa­zi­tät kann man nut­zen, um gemein­sam zu pla­nen, bestehen­de Plä­ne anzu­pas­sen oder über den Hau­fen zu wer­fen, und sich auf anste­hen­de Her­aus­for­de­run­gen vorzubereiten.
Gera­de in Infra­struk­tur­pro­jek­ten sind die aus­rei­chend bekannt, um für die nächs­ten paar Wochen vorauszudenken.

Agi­lis­mus und Was­ser­fall-Anbe­tung sind mei­ner Mei­nung nach die bei­den Extre­me, die jedes für sich völ­lig unrea­lis­tisch sind.
Die Wahr­heit liegt dazwischen.
Und jedes Pro­jekt hat sei­nen eige­nen Agi­li­täts­grad, bei dem die Ergeb­nis­se „al den­te“ auf den Tisch kommen.
Den rich­ti­gen Punkt fin­det man aber nur durch Erfah­rung und ste­ti­ge Übung.

A pro­pos Schuldzuweisung:
Egal ob Klas­sisch oder Agil – Stän­dig nach Schul­di­gen zu suchen, führt eine Orga­ni­sa­ti­on in den Abgrund, egal an wel­che Model­le sie glaubt.

Hi Mar­cus,

ein wenig Dog­ma­tik hat doch noch nie­mand gescha­det, oder? :-) Ich habe nicht nur ein mal gehört: Das Pro­jekt läuft nicht –> Ihr macht jetzt agil.

Per­sön­lich (und auch als PL, PO) fin­de ich die schnel­le Reak­ti­ons­fä­hig­keit klas­se, wenn sie sich bedarfs­ge­recht ein­set­zen lässt. Ich habe bis­her erlebt, dass der Spaß­fak­tor (mit dem rich­ti­gen Team) immens ist. Und neben dem Spaß auch die Schaf­fung von Nut­zen für den Kunden.

Es ist aber noch gar nicht lan­ge her, wo ich zum agi­len Vor­ge­hen ver­don­nert wur­de. In dem Unter­neh­men hat das an den eta­blier­ten Grund­pfei­lern gerüt­telt. Als das Team das ers­te mal mit der Eigen­ver­ant­wor­tung kon­fron­tiert wur­de – uiui – ich den­ke, ihr könnt´s euch vor­stel­len. Letzt­end­lich haben wir eine agi­les Pro­jekt im Was­ser­fall­man­tel geführt.

Agil kann genau­so Was­ser­fall sein, wie Was­ser­fall agil. Pas­sen muss es! Das beschreibt dein Arti­kel sehr gut.

Grü­ße
Sven

Auch wenn der ers­te Satz sicher vor allem pro­vo­zie­ren soll: Was­ser­fall ist nicht agil. Im Duden heißt es zu agil: „von gro­ßer Beweg­lich­keit zeu­gend; reg­sam und wen­dig“ Was­ser­fall hat nicht den Anspruch, wen­dig zu sein, son­dern vor­ab alles pla­nen zu kön­nen, um dann nur umset­zen zu müs­sen. Pla­nung und Umset­zung und Tes­tung und Live­gang sind seri­el­le Auf­ga­ben, die getrennt von­ein­an­der erle­digt wer­den können.

Grund­sätz­lich gehe ich bei dem Gedan­ken mit, dass die Rah­men­be­din­gun­gen beein­flus­sen, wie sehr ich die Pha­sen von Pla­nung und Umset­zung etc. tren­nen und seria­li­sie­ren kann und davon abhän­gig kann und soll­te das Vor­ge­hen gewählt werden.

Die Fra­ge lau­tet für mich also weder, agil oder klas­sisch, noch, wie agil das Pro­jekt, Pro­dukt oder „die IT“ ins­ge­samt sein soll, darf oder muss, son­dern wie genau ich vor­her wis­sen kann, wel­che Lösung mir am Ende den größ­ten Nut­zen bringt, was am Ende gebraucht wird. Dar­aus ent­springt auch eine mög­li­che benö­tig­te Reaktionsfähigkeit.

Wenn Din­ge nur ein­fach oder kom­pli­ziert sind, kann ich mit Wis­sen und Zeit vor­ab pla­nen und dann umset­zen. Sind sie kom­plex und von vie­len nicht ver­läss­lich plan­ba­ren Fak­to­ren (Men­schen und deren Ent­schei­dung z.B.) abhän­gig, eig­nen sich agi­le Vor­ge­hens­wei­sen, auch wenn die orga­ni­sa­to­ri­schen Bedin­gun­gen das nicht gut her­ge­ben. Die Fra­ge dann ist, wie man mit der Ein­schrän­kung umge­hen kann.

Natür­lich ist Was­ser­fall eher plan­ge­trie­ben und genau des­halb eben weni­ger wen­dig / agil als agil ;-) Aber wir sind uns ja einig: es kommt auf das Vor­ha­ben an. Und in der Tat sind vie­le Vor­ha­ben ehr­lich betrach­tet kom­plex, wer­den aber als kom­pli­ziert ein­ge­schätzt (weil machen wir immer so) und so getan als ob sie gut plan­bar wären.

Da sind wir uns einig. Brau­che ich ein reak­ti­ons­star­kes Vor­ge­hen, wäh­le ich eine agi­le Vor­ge­hens­wei­se, wenn nicht, dann nicht – und dann ist es ein plan­ge­trie­be­bes seri­el­les Wasserfall-Vorgehen.

Um ehr­lich zu sein fin­de ich die gan­ze Dis­kus­si­on zu „auf­ge­setzt theo­re­tisch“, weil sich m.E. der Begriff „agi­les Vor­ge­hen“ klar absetzt von „Was­ser­fall-Vor­ge­hen“. Es gibt ein grund­sätz­li­ches Ver­ständ­nis und da sind agi­les Vor­ge­hen und Was­ser­fall zwei gegen­über­lie­gen­de „Enden“

Für das kon­kre­te Vor­ge­hen und den benö­tig­ten Grad an Wen­dig­keit muss der Kon­text betrach­tet wer­den. Wenn ich aber für jede Dis­kus­si­on erst den Kon­text klä­ren und man sich auf eine Grund­la­ge eini­gen muss, kommt man nicht vor­an. Gera­de die Dis­kus­si­on ob Was­ser flüs­sig oder hart ist zeigt die Absur­di­tät die­ses Anspruchs. Zumal hart nicht das Gegen­teil von flüs­sig ist und ich nicht behaup­tet habe, dass Was­ser nicht auch hart sein kann. Was­ser ist flüs­sig und nicht fest. Was­ser­fall ist trä­ge und starr und eben nicht agil.

Btw. Wenn du von Pro­jek­ten aus­gehst, dann ist Was­ser­fall erst recht nicht agil, weil an einen abge­schlos­se­nen Was­ser­fall Zyklus ein neu­er Zyklus ange­hängt wer­den kann, das ist dann aber ein „neu­er Was­ser­fall“ und nicht eine (trä­ge) Beweg­lich­keit des alten Was­ser­falls m.E.

Ein Con­tai­ner­schiff wür­de man auch nicht als agil bezeich­nen, selbst wenn das eine im Ver­gleich zu einem ande­ren wen­di­ger wäre. Und hier wür­de es noch eher pas­sen als bei einem Wasserfall-Vorgehen.

Ja, die Dis­kus­si­on drü­ben auf Twit­ter hat eine etwas phi­lo­so­phi­sche (aber nicht weni­ger reiz­vol­le) Rich­tung genom­men, die ich jetzt nicht unbe­dingt hier ver­tie­fen will. Und ja, einen Was­ser­fall an den nächs­ten anzu­schlie­ßen macht den Was­ser­fall an sich noch nicht, son­dern nur das Gesamt­kon­strukt der meh­re­ren Was­ser­fäl­le hin­ter­ein­an­der (ein wenig jedenfalls).

Hal­lo Markus,

Die ent­schei­den­de Fra­ge lau­tet also nicht, agil oder klas­sisch, son­dern viel­mehr, wie agil das Pro­jekt, Pro­dukt oder „die IT“ ins­ge­samt sein soll, darf oder muss.“ Ja, die­ser Aus­sa­ge stim­me ich zu, möch­te Sie aber noch ergänzen.

Bar­ry Boehm von der Uni­ver­si­ty of Sou­thern Cali­for­nia und Richard Tur­ner von der Geor­ge Washing­ton Uni­ver­si­ty schla­gen in ihrem Arti­kel „Using Risk to Balan­ce Agi­le and Plan-Dri­ven Methods“ ein Modell vor, um zu tes­ten wie sehr sich ein Unter­neh­men für eine agi­le Vor­ge­hens­wei­se eignet.

D.h. es stellt sich nicht nur die Fra­ge wie agil darf es sein, son­der auch die Fra­ge wie agil kön­nen wir über­haupt (falls gefordert).

Bes­te Grüße
Patrick

Vie­len Dank für den sehr guten Beitrag.
M.E. ist der ent­schei­den­de Punkt, dass die Metho­de, das Füh­rungs-/Steue­rungs­prin­zip zur Auf­ga­be zum Kon­text pas­sen muss.
Das gilt für das gesam­te Vor­ha­ben (Pro­jekt, Pro­dukt), aber ggf. auch für die Modu­le. (Hier hel­fen die „Ward­ley-Maps“)

Eine gute Ori­en­tie­rung lie­fert das Cyne­fin-Frame­work oder auch das Stacey-Port­fo­lio mit der Unter­schei­dung zwi­schen kom­plex und „nur“ kompliziert.

Unter
http://www.process-and-project.net/spa
haben wir ein klei­nes Tool zur Ver­fü­gung gestellt, um die eige­nen Akti­vi­tä­ten ein­mal bzgl. Durch­füh­rungs­form, Erfolg und Grad der Kom­ple­xi­tät zu visualisieren.
(kos­ten­frei und ohne wei­te­re Ver­pflich­tun­gen o.ä. – Wir möch­ten ein­fach sehen, wie gut die Theo­rie mit der Pra­xis übereinstimmt.)

Vie­len Dank. Der Kon­text ist tat­säch­lich ent­schei­dend. Dar­um mag ich die kon­text­freie Dis­kus­si­on um Metho­den oder Best-Prac­ti­ces nicht. Ohne Bei­pack­zet­tel mit Anwen­dungs­ge­bie­ten, Neben­wir­kun­gen und Wech­sel­wir­kun­gen macht das kei­nen Sinn.

Schreibe einen Kommentar