Mai / Juni 2012 • Nr. 3€ 8,90 Österreich € 9,90 Schweiz sfr 16,50

ww

w.O

BJEK

Tspe

ktru

m.d

eG

654

0F

Die Zeitschrift für Software-Engineering und -Management

mit Poster

Agile Testing

SC

HW

ER

PU

NK

T:

AR

CH

ITE

KT

UR SCHWERPUNKT: ARCHITEKTUR

Der Architekturbegriff in agilen Projekten

Referenzarchitektur: Register Factory

Open-Source-Komponenten: Architektur vs. Lizenzrecht

Agilität jenseit derLagerfeuer-Romantik:

Ein kritischer Blicküber den Tellerrand

FACHTHEMA

SONDERDRUCK

AGILITÄT JENSEITS DER

LAGERFEUER-ROMANTIK:

EIN KRITISCHER BLICK

ÜBER DEN TELLERRAND

ne Wasserfall drin (vgl. z. B. [App09] und[Sho]). Man macht nun ein „Daily Stand -up”, benennt einen „Product Owner”, lässtsich zertifizieren und dadurch wird das jah-relang praktizierte „Irgendwie”-Vorgehenzu Scrum. Oder man begründet wildesCode-und-Fix mit: „Wir sind agil”.

Paul: Das ist richtig, Peter, aber das istdoch ein Problem, das weit über das ThemaAgilität und Softwareprozesse hinausgeht –wobei Agilität natürlich mehr als nur einSoftwareprozess-Thema ist, aber das solluns hier nicht stören. Aus meinen Erfah -rungen heraus wage ich die etwas pessimis -tische Prognose, dass dieses Problem derFehlinterpretation nicht allgemein lösbarist, auch nicht für Agilität.

Es gibt immer ein paar (wenige) Leute,die die Idee hinter einem nicht-trivialenThema – wie z. B. Agilität – verstehen unddiese sinnvoll umsetzen. Es gibt aber auchimmer viele Leute, die das Thema fehlinter-pretieren, bis hin zur kompletten Karikaturseiner selbst – sei es, weil sie das Themanicht verstanden haben, oder sei es, weil sieeigene Interessen verfolgen. Aber das istnichts Spezifisches im Bereich der Soft -wareprozesse. Das liegt im Wesen des Men -schen. Vergleichbare Effekte kann man in

Agilität hat mittlerweile ihren festen Platz in der IT – kaum noch ein Unternehmen, das sichnicht mit agilen Methoden beschäftigt. Dennoch bleiben jede Menge Fragen offen und so man-cher kritische Beobachter fragt sich, ob Agilität wirklich all die vielfach idealisiert erscheinendenVersprechen einlösen kann, die ihr zugeschrieben werden. Seriöse Wirklichkeit oder doch nurLagerfeuer-Romantik? Und wie passt das überhaupt in die Realität vieler Unternehmen? In diesem Artikel wagen wir einen Blick über den Tellerrand und versuchen eine Betrachtung voneinem etwas allgemeineren Standpunkt aus.

m e h r z u m t h e m a :blog.codecentric.deadesso.de

78 79

■ Peter ist der konstruktive Zweifler, derAgilität zwar positiv gegenübersteht,aber verschiedenste Aspekte kritischhinterfragt.

■ Paul ist eher der agile Praktiker, derversucht, Agilität zu leben, dabei aberauch nicht glaubt, dass Agilität dieAntwort auf alle Fragen der IT ist.

Agilität falsch verstandenPeter: Hallo Paul, ich habe noch einmalüber das Thema Agilität nachgedacht:Agile Methoden sind zwar en vogue, wer-den aber meiner Meinung nach scheitern.Nicht, dass ich die Ideen falsch finde. VieleIdeen sind ja gar nicht so schlecht. Aber ichbin mir sicher, dass Agilität scheitern wird,denn es ist sehr leicht, das alles falsch zuverstehen.

So war das nämlich schon immer mitSoftware-Prozessmodellen – sie wurdenimmer schon falsch verstanden. DerWasserfall hat ja in der Originalausgabevon Winston Royce (vgl. [Roy70]) auchFeedback-Loops, eben gerade, weil man siebenötigt. Trotzdem hat der Wasserfall, ent-gegen seiner Originalabsicht, eine unbe-wegliche IT produziert, weil seine Ideenfalsch umgesetzt wurden und man auf ab -geschlossene Phasen besteht. Der „RationalUnified Process” (RUP) (vgl. [Kru03]) stehtebenso in der Kritik, aber dort steht nir-gendwo geschrieben, dass man nur eineIteration machen soll und 1.000 Artefakteerstellen muss.

Viele Scrum-Coachs berichten, dass sie invielen havarierten Scrum-Projekten unter-wegs sind, „Scrumerfall” oder auch„ScrumBut” genannt. Es steht zwar Scrumdrauf, es ist aber der alte, falsch verstande-

Vielfach erscheint die Diskussion umAgilität immer noch religiös geprägt: VieleBefürworter vermitteln Agilität eher dog-matisch, man ist entweder „dafür” oder„dagegen”, alt ist „schlecht” und neu ist„gut”. Ein Hinterfragen der Werte undPraktiken und ein Abgleich mit anderenAnsätzen ist in einem solchen Umfeldschwierig.

Auf der anderen Seite begegnen einemimmer wieder sehr fragwürdige Interpreta -tionen und Umsetzungen von Agilität, dieeinem erfahrenen IT-Menschen – je nachSituation – ein kräftiges Runzeln oderSchweiß perlen auf die Stirn treiben. Was istdenn nun richtig, was ist falsch und warumist es so schwer, das alles vernünftig zu grei-fen?

Letztlich gibt es Unternehmsrealitäten,ge paart mit den Erkenntnissen aus 40 Jah -ren Software-Engineering, bei denen sichdie Frage stellt, wie Agilität dazu passt.Sind all die bekannten und bewährtenTechniken nur noch für den Papierkorbtauglich oder ist die Agilität eine Traum -welt ohne Realitätsbezug?

Wir haben diese und weitere Fragenintensiv diskutiert und sind für uns zu eini-gen „Outside-the-Box”-Antworten gekom-men, die wir in der allgemeinen Diskussionbislang nur selten so gehört haben. Wirdenken, dass diese Sichten eine weitereFacette in der Diskussion pro und contraAgilität darstellen können und versuchendeshalb, im weiteren Verlauf diesesArtikels, die wichtigsten Punkte unsererDiskussion nachzuzeichnen. Um das Ganzefür den Leser etwas abwechslungsreicherzu gestalten, haben wir es in ein imaginäresGespräch zwischen zwei Personen gepackt:

f achar t i ke l

Uwe Friedrichsen

(uwe.friedrichsen@codecentric.de)

hat langjährige Erfahrungen als Architekt,

Projektleiter und Berater. Aktuell ist er bei der

codecentric AG als CTO tätig und beschäftigt sich

insbesondere mit agilen Verfahren und neuen

Architekturansätzen.

Sven Johann

(johann@adesso.de)

ist Softwareentwickler bei der adesso AG mit den

Interessensschwerpunkten leicht- und schwerge-

wichtige Softwareentwicklungsprozesse. Aktuell

beschäftigt er sich mit sehr kurzen Release-Zyklen

durch Continuous Delivery.

d i e au toren

3/2012

allen Bereichen des Lebens beobachten.Man muss doch nur einmal in RichtungPolitik oder Religion schauen. Was dage-gen helfen kann, sind Ausbildung undTraining. Beides sind Faktoren, die erwie-senermaßen dazu beitragen, dass Men -schen nicht mehr so schnell Opfer verque-rer Fehlinterpretationen zu werden. Vielmehr kann man da aber eigentlich nichttun.

Agilität im historischenKontextPeter: Wie ist Agilität eigentlich entstan-den? Historisch gesehen gibt es schon seitmehreren Jahrzehnten inkrementelle Ent -wicklung, kollaborative Program mierungusw. (vgl. [Bas03]). Da sieht Agilität fürmich nach Rückbesinnung plus Weiter -entwicklung aus.

Paul: Damit liegst du aus meiner Sichtrecht gut. Mitte bis Ende der 90er Jahrewar der Höhepunkt der großen Vor -gehensmodelle, die in ihrer ganzen Prachtselbst DIN-A0-Plotter an ihre Grenzengebracht haben, gepaart mit einen archi-tekturzentrierten Vorgehen. Es gab Regel -werke, die erst nach einem monatelangenTayloring halbwegs handhabbar wurden –wenn sich denn jemand daran traute.

Menschen waren darin nur zutiefst miss -trauenswürdige Geschöpfe, die den schö-nen Prozess durch ihre Dummheit gefähr-den. Der Kunde und seine Anforderungensind ganz aus dem Fokus geraten. DasPendel war weit über eine sinnvolle Mittehinaus ausgeschlagen.

Da kam Agilität mit seiner Forderung aufeine Rückbesinnung auf die eigentlichenWerte: den Kunden und seine Anfor -derungen, Lösungen schaffen, Menschenund Vertrauen als Motor für erfolgreicheZusammenarbeit. Das war keine hellseheri-sche Genialität, das war nur die Erkennt -nis, dass man über das Ziel hinausgeschos-sen war und jetzt eine Gegenbewegungnötig war, um wieder zur sinnvollen Mittezu gelangen.

Natürlich sind auch dabei wieder einigeLeute über das Ziel hinausgeschossen. Dieagilen Dogmatiker von heute sind dieLeute, die das Pendel in das andere Extremzu zerren versuchen: keine Dokumentation,keine Planung und kein Ausbalancierenvon nicht-fachlichen Anforderungen. DieMitte zu treffen, ist halt sehr schwer.

Es ist ja auch viel einfacher, eine extremePosition einzunehmen: Die ist leicht ver-

ständlich, man kann klare Abgrenzungenund Feindbilder aufbauen und man kannschön polarisieren – so ähnlich, wie dieBoulevard-Medien es tun. Mit einerPosition einer balancierten Mitte geht dasnicht, da leidet die Popularität.

Agilität hui, der Rest pfuiPeter: Die Berichterstattung ist im Allge -meinen auch (immer noch) sehr einseitig.Agilität ist „gut”, andere Vorgehensweisenstehen für das „Böse”, also die schlechteSeite, den Sündenbock, das Scheitern (vgl.[Kru07]). Aber ganz so trivial kann dasdoch nicht sein. Obwohl mir persönlichnoch kein gescheitertes agiles Projektbegegnet ist, muss es sie doch geben. Es istunmöglich, dass alle agilen Konzepte inallen Kontexten ohne Adaptierung an diejeweilige Situation funktionieren – sonstwäre es ja die lang ersehnte „Silver Bullet”(vgl. [Bro95]), die es nie geben wird, wiewir wissen. Wie kommt es, dass dieseMeinung so stark vorherrscht?

Paul: Ich kann hier auch nur mutmaßen,aber ich sehe vorwiegend zwei Fak toren.Der eine Faktor ist Evangelistentum undder andere ist Selbstmarketing.

Beginnen wir mit dem Evangelistentum:Auch wenn Agilität eigentlich nicht mehreine junge Bewegung ist, ist sie erst vorrelativ kurzer Zeit in der breiten Masseangekommen. Um überhaupt so weit zukommen, müssen die dafür notwendigenUmdenkprozesse befeuert werden. DiesesBefeuern übernehmen insbesondere amAnfang einer neuen Idee so genannte

„Evangelisten”, also Menschen, die ehereindimensional die Vorteile ihrer Ideeanpreisen. Um eine Idee erfolgreich zumachen, sind diese Menschen letztlichunverzichtbar (vgl. [Man]).

Viel der von dir erwähnten eindimensio-nalen Berichterstattung kommt aus diesemUmfeld. Ab einem bestimmten Verbrei -tungs grad kommt dann natürlich der Zeit -punkt, zu dem sich der Nutzen der Evan -gelisten erschöpft hat und eher dieRealisten gefragt sind, die das Thema diffe-renzierter beleuchten. Diese findet manmeiner Meinung nach heute aber immerhäufiger und die Zahl der Evangelistennimmt mit der Verbreitung der Agilität ab.Selbstmarketing ist der zweite Punkt. Vieleder Protagonisten haben sich Agilität aufihre eigene Fahne geschrieben und da ist esdoch nur verständlich, dass Agilität beiihnen „gut” sein muss. Wer schreibt sichschon etwas „Böses” oder auch nur „nichtso Gutes” auf die Fahne (siehe auch Abbil -dung 1)?

Gründe für AgilitätPeter: Das ist alles? Es muss doch nochandere Gründe geben, warum plötzlichsehr viele dieses Vorgehen gut finden.

„Es existiert eine enge Beziehung

zwischen Agilität und dem Management

komplexer Umfelder – und

Softwareprojekte sind meist komplex.”

Paul: Die gibt es auch. Agiles Vorgehenist für viele heutige Projektumfelder eine

f achar t i ke l

Abb. 1: Faktoren, die der Agilität häufig schaden.

Arbeiten nicht möglich.Misstrauensbasierte Umfelder basieren

auf einer CYA-Strategie (Cover Your Ass),d. h. das Ziel, sich nur keine Blöße zu gebenund sich gegen jeden möglichen Angriffabzusichern, ist wesentlich wichtiger, alsein gutes und erfolgreiches Ergebnis zu pro-duzieren.

Das ist aber genau das, was Agilität nichtwill. Man will ein möglichst gutes Produktabliefern, man möchte keine endlosenVerträge und Spezifikationen, man möchteseine Energie in die Erschaffung einerLösung stecken und nicht in die Ab -sicherung jedweder Eventualitäten.

Diese Nichtablenkung von der Lösungs -herstellung funktioniert aber nur in einerauf Vertrauen basierenden Zusammen -arbeit. Ich kann es mir nur leisten, nichtCYA zu machen, wenn ich mir sicher bin,dass mein Gegenüber mich nicht bei dernächstbesten Gelegenheit in die Pfannehaut. Ich kann zum Beispiel nur auf epischeSpezifikationen verzichten, wenn ich dar-auf vertrauen kann, dass mein Gegenüberdie daraus resultierenden Lücken nichtgnadenlos zu seinem Vorteil ausnutzt.

Ist das nicht gegeben, ist echte Agilitätnicht möglich. Punkt. Natürlich kann mantrotzdem iterativ arbeiten, alle vier Wochendem Kunden etwas Lauffähiges vorführenoder ein tägliches Stand-up-Meeting ma -chen, aber richtig agil ist das nicht. Hast duein von Politik und Misstrauen durchsetz-tes Projekt, wird das mit Agilität nichts.

Peter: Sag ich doch, bei Großprojektengeht das nicht!

Paul: Du spielst auf die in Großprojektentypischerweise sehr ausgeprägte politischeDimension an. Die macht es in der Tat sehrschwer. Es gibt aber auch noch andereBesonderheiten, die Großprojekte sehrschwer machen und häufig scheitern lassen.So neigen diese dazu, riesige Wasserfall-Projekte mit einem ausgeprägten Pha -sendenken zu sein. Wenn das schon beideutlich überschaubareren Projekten auf-grund der Komplexität nicht funktioniert,dann ist ein solches Vorgehen beiGroßprojekten erst recht zum Scheiternverurteilt (siehe auch Abbildung 2).

Hier kann eine agile Vorgehensweisegute Dienste leisten. Anstatt zu versuchen,zu Anfang alles festzuschreiben, was erwie-senermaßen für die meisten Systeme nichtmöglich ist (vgl. beispielsweise [Weg95],[Weg97]), fange ich besser mit etwasKleinem an und ergänze das sukzessive invielen überschaubaren Iterationen, wobei

80 81

Fehler zu machen. Es wird also eine ReiheIrrwege und blutiger Nasen geben, bis mandas Thema wirklich verstanden hat undnachhaltig agil wird.

Ein weiterer Faktor ist die Art desLernens. Gerade auch im agilen Umfeldmuss man bereit sein, Dinge lange genug zuerproben, bis man ihre Effekte wirklichverstanden hat, da sich viele Effekte im agi-len Umfeld erst mit deutlicher Verzögerungzeigen und es vielfach keine unmittelbarenUrsache-Wirkung-Zusammenhänge gibt.Das erfordert die schwierige Balance, vor-schnelles Ändern zu vermeiden und unpas-sende Verfahren nicht zu spät anzupassen.Viele agile Prinzipien werden vorschnellvon Teams verworfen, weil sie sich nichtgenug Zeit geben zu lernen. Sie denkennach kurzer Zeit, sie hätten es verstanden,sehen nicht ad hoc den gewünschten Effektund verwerfen das Prinzip oder ändern esab:

Pair Programming? Warum soll ich zweiEntwickler an eine Aufgabe setzen, dieauch einer allein erledigen kann? Wegdamit. Daily Scrum? Wir sitzen doch ehschon zusammen. Retrospektiven: Wieso?Wir hätten nichts besser machen können.Und so weiter. Da gehen dann eine MengeWissen und möglicher Erfolg vorschnellverloren.

Ein externer Experte kann helfen, eineReihe von Irrwegen zu vermeiden, weil ersich schon seine „blutige Nase” geholt hatund diese Erfahrungen einbringen kann.Aber eine Erfolgsgarantie stellt auch ernicht dar, was man ja auch in der Praxisbeobachten kann: Es gibt genügendgescheiterte agile Projekte, die brav nachLehrbuch von einem agilen Expertenbegleitet worden sind.

Agilität in großen ProjektenPeter: Hm, blutige Nasen, Irrwege, zugeben,dass man was falsch gemacht hat … Wennich mir meine Projekte in diversenGroßunternehmen anschaue, dann kann ichnicht glauben, dass so etwas funktioniert.Denn in großen bis sehr großen Projektengibt es doch immer Interes sen gruppen, dieso etwas nicht zulassen werden. Mache ichetwas falsch und gebe es zu, wird das gegenmich verwendet. Ist doch so!

Paul: Das ist ein sehr wichtiger Punkt:Um ein agiles Projekt erfolgreich durchzu-führen, ist es besonders wichtig, in einemvertrauensvollen Umfeld zu arbeiten. InUmfeldern, in denen Vertrauen sehr schwerbis unmöglich ist, ist ein vernünftiges agiles

gute Wahl: Die meisten heutigen Projekt -umfelder haben im Sinne der Systemtheoriehohe komplexe Anteile und Agilität bün-delt eine ganze Reihe seit vielen Jahrenbekannter und erprobter Mittel, umKomplexität handhabbar zu machen.

Das ist übrigens eher ungeplant so ent-standen. Initial wurden unter Agilität ein-fach nur eine Reihe von Werten und Vor -gehensweisen gebündelt, von denen ihreMacher wussten, dass sie in ihren Um -feldern gut funktioniert haben. So gesehen,ist Agilität eher als empirische Sammlungentstanden. Erst später wurde klar, dass eshier eine enge Beziehung zum Managementkomplexer Umfelder gibt.

Das beantwortet aber vielleicht auch einStück weit deine Frage, wo Agilität nichthilft (Stichwort: keine „Silver Bullet”):nämlich überall dort, wo wir keineKomplexität im Sinne der Systemtheoriehaben. Eine nicht komplexe Aufgabenstel -lung agil zu verwalten, ist eher kontrapro-duktiv. Habe ich z B. eine stabile Umge -bung mit stabilen Anforderungen, danngibt es keinen Grund für ein agiles Vor -gehen (vgl. [Kru08]). Das führt dann meistzu Situationen, in denen die Aufwändeletztlich deutlich höher werden als beimEinsatz klassischer Vorgehens weisen.

Man muss sich dabei aber vor Augen hal-ten, dass die meisten heutigen IT-Projekteganz klar komplex im Sinne der System -theorie sind: Unklare Anforderungen,dyna mische Anforderungsänderungen,komplexe Beziehungen allerorten usw.Deshalb ist ein agiles Vorgehen im Großeneigentlich fast immer sinnvoll. Das bedeu-tet aber nicht, dass man jede Detailaufgabe,wie etwa das Aufsetzen einer Entwick -lungs- und Build-Umgebung für ein Pro -jekt, automatisch agil gestalten muss. Aufder Ebene ist es dann immer noch sinnvollzu differenzieren, um welche Art von Auf -ga ben stellung es sich handelt.

Einführung von AgilitätPeter: Okay, aber wie soll ich da am bestenbeginnen? Was sind die Voraussetzungen?Da Agilität ja eine Art „Mindset” ist, kannman mit Sicherheit nicht Ruck-Zuck Erfolgdamit haben, oder? Das Problem ist doch,dass man, statt vorgegebenen Prozess vor -schriften zu folgen, seinen eigenen Weg fin-den muss.

Paul: Nach meiner Erfahrung sollte mansich nur nicht der Illusion hingeben, dassman sofort perfekt agil sein wird. Manmuss Agilität lernen, und Lernen bedeutet,

f achar t i ke l

3/2012

ich immer darauf achte, aus dem bisherGemachten zu lernen und die nächstenSchritte daran anzupassen.

Großprojekte sind letztlich immerschwierig, nicht nur aufgrund der typischenProjektpolitik. Einige erfolgreiche großeProjekte, die mit agilen Vorgehensweisenumgesetzt worden sind, zeigen einem aber,dass sich Agilität und Großprojekte nichtausschließen.

Was kommt nach Agilität …Peter: Na schön, aber alles in allem hörtsich das sehr schwer an. Da muss manerfahren sein. Du erwähnst die Theoriekomplexer Systeme, ist da die nächste Stufeder Prozessmodelle am Horizont?

„Die Akteure in einem Softwareprojekt

brauchen Talent, Wissen und Training.

Ansonsten nützt auch das schönste und

beste Prozessmodell nichts.”

Paul: Ich weiß auch nicht, was die nächsteStufe ist, die ein Prozessmodell erreichenwird. Persönlich glaube ich nicht, dass esirgendwann das Prozessmodell geben wird.Eigentlich ist weitestgehend alles da, waswir benötigen. Die Kunst ist nur, die derkonkreten Situation angemessenen Bau -steine auszusuchen und sie angemessenmiteinander zu kombinieren. Das hat aberaus meiner Sicht sehr viel mit persönlicherKompetenz – auch Können genannt – zutun. Ich definiere Können als eine Kombi -nation aus Wissen, Erfahrung und Talent.In meiner Definition (die letztlich auchnicht von mir stammt, sondern die ichirgendwo einmal gelesen habe und be -sonders treffend fand) wird der eigentlicheKnackpunkt sehr gut sichtbar: das Talent.

Du kannst so viel wissen, wie du willst,

und üben bis zum Umfallen, wenn du keinTalent hast, wirst du nie wirklich gut sein.Das gilt nicht nur für Fußball spielen (viele100.000 Jugendliche wissen praktisch allesüber Fußball und trainieren ganz viel undlanden trotzdem nicht in der Bundesliga),sondern auch für die IT und im Speziellenauch für die sinnvolle Anwendung vonProzess modellen.

Das Gemeine an der Sache ist: Talent istnicht übertragbar, es ist personengebunden.Und damit sind wir wieder zurück amAnfang: Diejenigen, die Agilität richtig ver-stehen und umsetzen, sind immer Könner,die anderen sind häufig die, die noch nichtkönnen – sei es, dass ihnen Wissen,Training oder Talent fehlt.

… und was bleibtPeter: Was bleibt uns neben all der (völlignormalen) Verwirrung und den Missver -ständnissen an der Agilität erhalten?

„Agilität hat wichtige Impulse gebracht,

die in Zukunft überleben werden.”

Paul: Ich denke, egal wie es mit der Agilitätweitergehen wird, sie hat wichtige Impulsegebracht, die überleben werden: Sie hat bei-spielsweise eine Re-Fokussierung auf dieWertschöpfung anstatt auf die Methodegebracht und die Möglichkeit einer voll-

ständigen à priori Planung selbst mäßigkomplexer Vorhaben in Frage gestellt.

So macht Agilität klar, dass alleBeteiligten während eines Projekts dazuler-nen und dass es keinen Sinn macht, einenarmen Menschen am Anfang irgendwo hin-zusetzen, damit er alle Anforderungen vor-ab als Hochzeitsfrage („... der spreche jetztoder schweige für immer!”) behandelt –insbesondere, weil das ja in der Regel un -möglich ist, wie bereits zuvor beschrieben.

Als Gegenentwurf dazu hat Agilität denmöglichen Produktivitätsgewinn durchkurze Feedback-Zyklen mit viel Kommu ni -kation gezeigt. Man tut das, wovon manzum aktuellen Zeitpunkt weiß, dass es imgegebenen Kontext das Wichtigste undRichtigste ist, schaut sich das Ergebnis an,lernt daraus und macht den nächstenSchritt.

Agilität hat auch sinnvollere Preismo del -le salonfähig gemacht. Klassischerweisesehen viele Preismodelle so aus: Ich macheeine Ausschreibung, in die ich hineinschrei-be, dass der Preis zu einem großen Teil denZuschlag bestimmt.

So hat sich ein System etabliert, in demjeder weiß, dass man nur durch Ände-rungsanforderungen (Change Requests)Marge machen kann. Also bietet man zumDumping-Preis an und setzt dann einenabgebrühten Projektmanager auf dasProjekt, der sich jede Kleinigkeit – vondenen es erfahrungsgemäß im Laufe desProjekts jede Menge geben wird – in Formvon saftigen Änderungsanforderungen ver-silbern lässt.

Agile Projekte versuchen hingegen, denMehrwert für den Kunden in das Zentrumihrer Betrachtungen zu stellen. So wirddann beispielsweise statt exakter Anfor -derungen ein „Leistungsversprechen” for-muliert. Damit kann man auch weiterhinalle Aspekte festmachen, die einem Kundenwichtig sind: Zeit, Budget, Qualität undScope. Nur ist der Scope dann kein dickesPflichtenheft mehr, sondern ein Ver -sprechen des Dienstleisters, dass er in derZeit eine bestimmte Arbeit erbringt, mit

f achar t i ke l

Abb. 2: Ist Agilität im Kontext von Großprojekten überhaupt möglich?

Die codecentric AG ist auf die Entwicklung maßgeschneider-ter IT-Lösungen spezialisiert. Die Gesellschaft gehört zu denführenden deutschen Anbietern in den Bereichen Agilität, Architektur, Java Performance,Java und Enterprise Content Management.

codecentric bietet Entwicklung, IT-Beratung und Services entlang des gesamten Lebens -zyklus von Anwendungen und Infrastrukturen: von der individuellen Software-Lösung überdie Performance-Optimierung von Java-Anwendungen bis hin zur Unterstützung organisa-torischer Prozesse im Unternehmen.

82 83

haben, und es gibt noch viel, viel mehr dazuzu sagen, aber wir hoffen, dass wir diewichtigsten Ideen vermitteln konnten.

■ Agilität ist keine „Silver Bullet”, abersehr gut für den Umgang mit komple-xen Situationen geeignet, wie man siein heutigen IT-Projekten typischerweiseantrifft.

■ Agilität in Großprojekten ist problema-tisch, insbesondere wegen der dort typi-

dem Ziel, für den Kunden den maximalenMehrwert zu erzeugen.

Womit diese Arbeit im Detail ausgefülltwird, kann der Kunde steuern. Durch kurzeIterationen sieht er zum einen schnell, ob derDienstleister sein Leistungsversprechen auchhält, und er hat zusätzlich noch dieMöglichkeit, neue oder veränderte Anfor -derun gen – z. B. auf Basis von Erkennt nissenaus der letzten Iteration – einzubringen. DerKunde hat wie zuvor Sicherheit in allenDimensionen und erhält den maximalenMehrwert für sein eingesetztes Geld, wenndenn Kunde und Dienstleister ehrlich sindund sich gegenseitig vertrauen – aber dashatten wir ja schon (siehe Abbildung 3).

FazitPeter und Paul haben viele der genanntenAspekte noch wesentlich intensiver disku-tiert und auch noch diverse weitereAspekte, wie z. B. das Zusammenspiel vonArchitektur und Agilität (Stichwort:„Emergenz”). Das würde dann aber denRahmen dieses Artikels sprengen.

Wir hoffen, wir konnten Ihnen für IhreÜberlegungen und Diskussionen rund um dasThema Agilität ein paar neue Ideen und Anre -gungen jenseits der ausgetretenen Diskus -sionspfade liefern und helfen, das Thema ineinem etwas größeren Kontext zu verankern.

„Agilität ist keine Silver Bullet.”

Natürlich waren es nur einige ausge-wählte Aspekte, die wir hier diskutiert

f achar t i ke l

Literatur & Links

[App09] J. Appelo, ScrumButs Are the Best Part of Scrum, September 2009, siehe

www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html

[Bas03] V. Basili, C.Larman, Iterative and Incremental Development – A Brief History, IEEE

Software 2003

[Bro95] F. Brooks, The Mythical Man Month, Addison-Wesley 1995

[Gal02] J. Gall, Systemantics – The Systems Bible, 3rd Ed., General Systematics Press 2002

[Kru03] P. Kruchten, The Rational Unified Process, Addison-Wesley 2003

[Kru07] P. Kruchten, Voyage in the Agile Memeplex, ACM Queue 2007

[Kru08] P. Kruchten, Podcast LPZ IT-Radar, Universität Leipzig 2008

[Man] M.L. Manns, L. Rising, Fearless Change: Patterns for Introducing New Ideas, siehe:

www.cs.unca.edu/~manns/intropatterns.html

[Roy70] W. Royce, Managing the Development of Large Software Systems, IEEE WESCON 1970

[Sho] J. Shore, The Decline and Fall of Agile, siehe:

jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

[Weg95] P. Wegner, Interactive Foundations of Object-Based Programming, IEEE Computer

28(10): 70-72, 1995

[Weg97] P. Wegner, Why Interaction Is More Powerful Than Algorithms, Communications of the

ACM 40(5): 80-91, 1997

Abb. 3: Positive Aspekte, die Agilität der IT gebracht hat.

scherweise sehr ausgeprägten politi-schen Dimension, die Agilität aufgrundeiner fehlenden Vertrauenskultur un -mög lich macht.

■ Es gibt nach wie vor in vielen ProjektenProbleme mit dem Verständnis oder derAnwendung von Agilität. Das liegtdann in der Regel aber nicht an derAgilität an sich, sondern an viel allge-meineren Problemen, die uns häufigschon die gesamte IT- bzw. Mensch -heitsgeschichte begleiten.

■ Viel wertvolles und essenzielles Wissengeht verloren, wenn man sich nicht selbstintensiv mit dem Thema auseinander-setzt und sich stattdessen auf Meinungenund Zusammenfassungen anderer ver-lässt, wie man schön am Schicksal desWasserfall-Modells sehen kann: In seinerOriginalfassung hatte dieser Ansatz vieleinteressante Aspekte wie Feedback-Zyklen und den involvierten Kunden. Alldieses wertvolle Wissen ist aber verloren-gegangen und am Ende blieb das übrig,was heute so häufig als Feindbild derAgilität herhalten muss.

Wenn wir Ihnen einen Rat im Zusam -menhang mit Agilität geben können: Ve r -trauen Sie niemandem blind (auch uns nicht),sondern machen Sie sich Ihr eigenes Bild.Agilität hat so viele Facetten, die passen nichtin einen Artikel, eine Präsentation und schongar nicht auf einen Bierdeckel … ■