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ür­ren­matt

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 Erkennt­nis­se.

Unter­schei­de ohne zu tren­nen, ver­bin­de ohne zu ega­li­sie­ren.
Her­bert Piet­sch­mann

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 zusam­men.

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 Chrur­chill

Du willst keinen Artikel mehr verpassen?

Mit mei­nem News­let­ter bekommst du ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

13 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 Anla­gen­bau.
Soweit die Blö­de­lei im Kon­text.

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 beschrie­ben.
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 über­prü­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 unge­wöhn­lich.

Ü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 pas­siert.
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üh­len.

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 vor­zu­be­rei­ten.
Gera­de in Infra­struk­tur­pro­jek­ten sind die aus­rei­chend bekannt, um für die nächs­ten paar Wochen vor­aus­zu­den­ken.

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 dazwi­schen.
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 kom­men.
Den rich­ti­gen Punkt fin­det man aber nur durch Erfah­rung und ste­ti­ge Übung.

A pro­pos Schuld­zu­wei­sung:
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 Kun­den.

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ön­nen.

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 wer­den.

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 Reak­ti­ons­fä­hig­keit.

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 Was­ser­fall-Vor­ge­hen.

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 Was­ser­fall-Vor­ge­hen.

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 jeden­falls).

Hal­lo Mar­kus,

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än­zen.

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 eig­net.

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 gefor­dert).

Bes­te Grü­ße
Patrick

Vie­len Dank für den sehr guten Bei­trag.
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“ kom­pli­ziert.

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 visua­li­sie­ren.
(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 über­ein­stimmt.)

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