WHITE PAPER

Agiles Management fr erfolgreiche ITProjekte

Agiles Management fr erfolgreiche IT-Projekte

Kurzfassung
Nur eins von drei IT-Projekten verluft im Durchschnitt erfolgreich. Versptungen, Kostenexplosionen und stndige Anforderungsnderungen sind scheinbar normale Rahmenbedingungen der Softwareentwicklung. Weder die Kunden noch die Lieferanten sind damit zufrieden aber lassen sich diese Mngel beseitigen? Agiles Projektmanagement bietet neue Wege zur erfolgreichen Umsetzung von ITProjekten. Traditionelle Techniken des Projektmanagements wie detaillierte Planun gen und strenge Hierarchien werden durch Flexibilitt, Kreativitt und Kommuni kation abgelst. Ziel ist es, den Kunden durch die Auslieferung werthaltiger Software innerhalb mglichst kurzer Frist zufrieden zu stellen. Die grundlegenden Prinzipien agiler Softwareentwicklung wurden Ende des vorigen Jahrzehnts entwickelt. Darauf basierende Methoden wie Extreme Programming (XP) oder Scrum wurden schnell populr und sind heute bei vielen Softwareherstellern im Einsatz (beispielsweise Google, Sun Microsystems oder SAP). Infopark wendet ebenfalls unterschiedliche Techniken agiler Softwareentwicklung erfolgreich an. Die Praxis beweist deren besondere Eignung fr Web-Projekte: Erfolgsquote und Produktqualitt werden deutlich gesteigert, Termine und Kosten bleiben unter Kontrolle. Es lohnt, sich damit genauer zu beschftigen.

1. Geplant ins Chaos

Nur jedes dritte IT-Projekt ist erfolgreich
Die Programmierung neuer Software wird in der Regel detailliert geplant. Auftraggeber und Entwicklerteam legen vor Beginn der Arbeit exakt fest, welche Funktionen in welcher Form realisiert werden sollen. Anschlieend wird die erarbeitete Spezikation buchstabengetreu abgearbeitet. Dabei kann eigentlich nichts schiefgehen, oder? Die Praxis zeigt das Gegenteil. Nach Angaben der Standish Group (Chaos Report 2004) wird im Durchschnitt weniger als ein Drittel aller Projekte erfolgreich abgewickelt. In jedem zweiten Fall dagegen wurden der Zeit- und/oder der Kostenrahmen gesprengt. Etwa jedes fnfte Vorhaben scheiterte sogar komplett. Dass dieses Verhltnis seit lngerem besteht, unterstreichen die Auswertungsergebnisse der Standish Group fr die Jahre 1994-2004:

Erfolgsquote abgeschlossener Projekte in % (Standish Group, Chaos Report 2004)

Auch Umfragen im nationalen Rahmen besttigen diese Tendenzen (siehe z.B. www.gulp.de/kb/it/projekt/planungsmaengel_f.html). Immer wieder werden folgende Symptome als typisch fr IT-Projekte benannt: Projekt dauert lnger als erwartet Kosten sind hher als erwartet Anforderungen ndern sich Inhaltliche Umsetzung erfolgt mangelhaft Technologieentwicklung berholt das laufende Projekt.

Welche Begrndung gibt es dafr?

Grenzen konventionellen Projektmanagements

Die Ursachen fr diese unbefriedigenden Resultate liegen in der Sucht, alle Arbeitsschritte und Ergebnisse so exakt wie nur mglich vorzugeben. Diese sogenannte Wasserfall-Methode des Projektmanagements berzeugt auf den ersten Blick durch ihre Logik und Organisation. Die Praxis beweist allerdings, dass der Mensch nicht besonders dafr geeignet ist. Eine Erhebung des OFFIS e. V. (Oldenburger Forschungs- und Entwicklungsinstitut fr Informatik-Werkzeuge und -Systeme, www.ofs.de) aus dem Jahr 2005 besttigt sogar die Aussage, dass Projekte ohne spezielle Vorgaben eine hhere Erfolgsquote aufweisen als Projekte mit konkreten Vorgehensmodellen. Der Grund ist einfach: Wir knnen nicht in die Zukunft sehen. Es ist schlicht unmglich, vor Beginn einer Softwareentwicklung alle Anforderungen vorherzusehen und den Aufwand fr die Arbeitsschritte genau zu prognostizieren. Jeder Versuch, das zu tun, gert entweder zu allgemein oder zu detailliert und ist unausweichlich mit Fehlern behaftet. Whrend des Projekts gewonnene Erkenntnisse werden viel zu selten genutzt denn dafr msste die Spezikation gendert werden. Kein Plan berlebt die erste Feindberhrung.
Helmuth Graf von Moltke

Durch die starke Arbeitsteilung im Team konzentriert sich jeder Mitarbeiter nur auf die vorgegebenen Aufgaben und ist nicht bereit, darber hinaus Verantwortung zu bernehmen. Die Kommunikation im Team wird negativ beeinusst, der Blick ber den Tellerrand fr die ganzheitlichen Anforderungen geht verloren. Ein weiterer Nachteil ist der groe Dokumentationsaufwand, der enorme Ressourcen bindet. Offensichtlich wird ein anderer, mehr der menschlichen Natur entsprechender Ansatz bentigt, um IT-Projekte zur allseitigen Zufriedenheit abzuwickeln. Infopark nutzt dazu mit Erfolg unterschiedliche Techniken agiler Softwareentwicklung, die in den nchsten Kapiteln nher erlutert werden.

2. Das Konzept agiler Softwareentwicklung

Freirume fr kreatives Handeln
Die grundlegenden Ideen agiler Softwareentwicklung entstanden in den 1990er Jahren. Die Entwicklung von Software sollte durch Verschlankung und Entbrokratisierung verbessert und beschleunigt werden. Ziel ist es, das konventionelle Anforderungskorsett aufzubrechen und die kreativen Potenziale aller Beteiligten zu erschlieen. Dafr werden neue Denkanstze und Werte bentigt. Im Manifest der Agilen Softwareentwicklung sind diese wie folgt formuliert: Menschen und Kommunikation sind wichtiger als Methoden und Werkzeuge. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Lauffhige Software ist wichtiger als umfangreiche Dokumentation. Reagieren auf Vernderung ist wichtiger als Planerfllung.
Manifest der Agilen Softwareentwicklung (www.agilemanifesto.org)

Die rechts stehenden Kriterien werden dabei nicht vernachlssigt, aber im Zweifelsfall bekommen die links genannten Werte den Vorzug. Dabei ist Agilitt nicht zu verwechseln mit Anarchie. Im Gegenteil, aufgrund der gesteigerten Verantwortung jedes Einzelnen sind Disziplin und Initiative besonders gefragt. Prioritt hat generell die Erfllung der Kundenbedrfnisse. Es ist nicht entscheidend, mit welchen Mitteln das Vorhaben umgesetzt wird. Wichtig ist, welcher Endzustand zu einem bestimmten Zeitpunkt erreicht ist und welcher konkrete Nutzen damit verbunden ist.

Wichtige Prinzipien
Ein Projekt wird nicht einfach dadurch agil, indem man es so bezeichnet. Alle Beteiligten mssen bestimmte Prinzipien akzeptieren und auch bereit sein, danach zu arbeiten. Solche Prinzipien sind beispielsweise Kundennhe Transparenz Flexibilitt und Teamfhigkeit.

Auf den genannten Werten und Prinzipien basieren alle agilen Softwareentwicklungsprozesse. Sehr oft wird das Scrum-Modell angewendet, daneben haben Extreme Programming (XP), Adaptive Software Development oder Crystal weite Verbreitung erfahren. Infopark setzt bei IT-Projekten verschiedene agile Techniken aus diesen populren Modellen ein. Diese werden durch eigene Erfahrungen und State-of-the-ArtMethoden erweitert. Was das konkret bedeutet, erlutert der nchste Abschnitt.

3. Mittel und Methoden agilen Projektmanagements

Kontinuierlicher Prozess
Klassische Softwareentwicklung unterscheidet verschiedene Phasen (Anforderungsanalyse, Entwurf, Test, Programmierung), die gewhnlich in chronologischer Folge abgearbeitet werden. Auch bei agilen Methoden spielen diese Phasen eine wichtige Rolle, nur folgen sie hier nicht zeitlich nacheinander. Statt dessen wird die Software kontinuierlich geplant, getestet und entwickelt (adaptiver Prozess). Dabei wird angestrebt, mglichst frh zu einer ausfhrbaren Version der Software zu gelangen. Diese wird dann in regelmiger Abstimmung mit dem Kunden erweitert und verfeinert, bis ein allseits befriedigender Stand erreicht ist. Natrlich entsteht so ein Prototyp nicht von selbst. Auch agile Softwareentwicklung bentigt ein bestimmtes Ma an Organisation.

Angestrebten Nutzen klar denieren

Am Beginn des Projektes werden in einer Anforderungsanalyse die grundlegenden Projektziele und der damit verbundene Nutzen bestimmt. Dabei wird bercksichtigt, dass der Funktionsumfang einer Software von der berwiegenden Zahl der Anwender nur zu etwa einem Drittel ausgeschpft wird. Zwei Drittel der verfgbaren Mglichkeiten werden dagegen selten oder gar nicht bentigt. Der unverhltnismig groe Aufwand fr deren Realisierung bringt selten einen entsprechenden Mehrwert.

Aufwand-Nutzen-Relation in IT-Projekten

Daraus ergibt sich die logische Folge, bei der Softwareentwicklung zuerst die Anforderungen umzusetzen, die mit mglichst geringem Erstellungsaufwand den hchsten Nutzen erbringen.

Unterteilung in Stories
Um den Planungsaufwand niedrig zu halten, wird bei agiler Softwareentwicklung keine detaillierte Spezikation erstellt. Fr die Beschreibung der Ziele werden sogenannte Stories genutzt. Jede Anforderung wird in einer Story nach dem Muster Als XXX kann ich XXX, um XXX festgehalten. Dabei kann der Teil um XXX auch entfallen, wenn der Zweck deutlich genug bestimmt ist. Die Formulierung der Story ist situationsabhngig nderbar. Fr die Protokollierung gibt es keine Vorgaben, es gengen formlose, aber przise Beschreibungen auf einfachen Karten (Story Cards). Diese Story Cards werden fr alle Beteiligten gut sichtbar an einer zentralen Stelle platziert. Sie dienen im gesamten Projektablauf als wichtiges Kommunikationsmedium zwischen Kunde und Entwickler.

Beispiele fr Story Cards bei Infopark

Abstrakte Aufwands- und Risikobewertung

Die Abschtzung des zeitlichen und personellen Aufwands fr die Realisierung einer Story ist auch fr erfahrene Mitarbeiter problematisch. In der agilen Softwareentwicklung werden dafr keine konkreten Gren (Zeit, Geld) genutzt. Die Aufwandsbewertung erfolgt statt dessen in abstrakten Einheiten, beispielsweise unter Verwendung einer nicht-linearen Punkteskala. Die verwendeten Abstufungen sollten einfache Vergleichsabschtzungen zwischen den Stories zulassen, beispielsweise (nach Mark Cohn): eine Skala mit den Werten 1, 2, 3, 5, 8: fr Story C (Aufwand = 3) bentigen wir genau so lange wie fr Story A (Aufwand = 1) und Story B (Aufwand = 2) zusammen oder eine Skala mit den Werten 1, 2, 4, 8: fr Story C (Aufwand = 4) bentigen wir doppelt so lange wie fr Story B (Aufwand = 2).

Ergibt die Abschtzung in diesen Fllen einen Wert grer als 8, muss die Story weiter untergliedert werden. Im Projektverlauf werden die Aufwandsabschtzungen mit den tatschlichen Ergebnissen verglichen und bei Bedarf korrigiert. Dadurch sind zunehmend genauere Schtzungen ber die verbleibenden Aufwnde mglich. Fr die Risikobewertung bezglich Zeitplan, Kosten und Funktionalitt gengen zwei (gering hoch), maximal drei Stufen.

Sprints und Planning Game

Ein grundlegendes Prinzip agilen Projektmanagements ist das Vorgehen in kurzen berschaubaren Etappen konstanter Lnge (maximal zwei bis vier Wochen). Statt eines langen Projektmarathons wird eine Reihe kurzer Sprints absolviert. Diese Sprints (auch Iterationen genannt) sind das zentrale Element vieler Modelle agiler Softwareentwicklung, unter anderem auch des Scrum-Modells. Zu Beginn jedes Sprints sind die Anforderungen zu bestimmen, die innerhalb des festgelegten Zeitraums umgesetzt werden sollen. Dazu werden innerhalb eines sogenannten Planning Game den einzelnen Stories Prioritten zugeordnet. Das erfolgt durch den Kunden und die Entwickler gemeinsam. Die Prioritten werden dabei nach folgenden Kriterien vergeben:

Risiko
Hoch Gering Gering Hoch

Nutzen
Hoch Hoch Gering Gering

Prioritt
1 2 3 Diese Kombination ist mglichst zu vermeiden

Im Ergebnis entsteht ein Sprint Backlog, das beschreibt, welche Stories im aktuellen Sprint realisiert werden. Dann kann mit der Umsetzung begonnen werden. Die Entwickler zerlegen dazu jede Story in einzelne Arbeitspakete und schtzen deren Aufwand ab. In tglichen kurzen Besprechungen (Daily Scrum) werden diese Arbeitspakete innerhalb des Teams aufgeteilt. Weiterhin teilt jeder Entwickler mit, was er am Vortag fertiggestellt hat und welche Probleme oder neue Ideen dabei aufgetreten sind.

Abschluss eines Sprints

Erweist sich der geschtzte Aufwand fr eine Story als zu gering, wird die Story entweder aufgeteilt oder komplett auf den nchsten Sprint verschoben. Auch die Repriorisierung von Stories whrend eines Sprints ist mglich. Am Ende jedes Sprints steht eine neue ausfhrbare Version der Software. Diese ist Gegenstand eines Akzeptanztests (des Sprint-Reviews). Gemeinsam mit dem Kunden wird im Review bestimmt, wie weit die Anforderungen erfllt wurden und welche Leistungsmerkmale im nchsten Sprint realisiert werden sollen. nderungen gegenber bisherigen Planungen sind dabei willkommene Chancen zur Verbesserung der Produkteigenschaften (Feedback-Loops). Nicht selten erweist sich im Verlaufe des Projektfortschritts, dass die Realisierung ursprnglich vorgesehener Ziele einen zu geringen Nutzen erbringen wrde. Es wird dann gemeinschaftlich entschieden, ob diese Funktionen trotzdem zur Verfgung gestellt werden oder ob auf sie verzichtet werden kann, ohne dass Einschrnkungen in der Benutzbarkeit der Software entstehen.

Vernderungen sind willkommen Projektfortschritt mit Sprints

Wenn alle auf diese Weise gemeinsam festgelegten Ziele korrekt implementiert sind, ist das Projekt fertiggestellt. Der Kunde erhlt auf diese Weise ein Produkt, an dessen Entstehung er aktiv beteiligt war und das genau seinen Anforderungen entspricht.

4. Vorteile und Anforderungen

Nutzen fr beide Seiten
Das im vorigen Abschnitt beschriebene iterative Vorgehen in enger Kommunikation mit dem Kunden ein grundlegendes Element agiler Softwareentwicklung erweist sich in der Praxis aus vielen Grnden vorteilhaft: Die Orientierung auf den maximalen Nutzen fhrt zu schnellen Erfolgen. Es gibt schnelles Feedback speziell zur Umsetzung der wichtigsten Funktionen. Fehler in der Konzeption bzw. Umsetzung werden schnell erkannt und knnen sofort beseitigt werden. Das Risiko von Fehlentwicklungen wird minimiert. Eine gleichmige Auslastung des Projektteams wird gesichert. Zeitplan und Kosten bleiben unter Kontrolle der typische fehlerbehaftete Finalstress wird vermieden. Neu gewonnene Erkenntnisse ieen stndig in die Entwicklung ein. Durch die intensive Kommunikation kann der Umfang der Dokumentation auf ein vernnftiges Ma reduziert werden.

Das Team entscheidet

Auch die agile Softwareentwicklung kann keine hundertprozentige Erfolgsgarantie bieten. Die Bereitschaft zur Flexibilitt, Offenheit und intensiver Kommunikation muss bei allen Projektbeteiligten vorhanden sein. Nur dann werden die beschriebenen Methoden ihre positive Wirkung voll entfalten. Die richtige Zusammensetzung der Teams und deren uneingeschrnkte Untersttzung durch Auftraggeber und Management spielen ebenfalls eine wichtige Rolle. Statt komplizierter Hierarchien gibt es beispielsweise im Scrum-Modell lediglich drei klar denierte Rollen: Product Owner (in der Regel der Kunde) Team Scrum Master Trgt die Gesamtverantwortung, deniert die Zielsetzungen und aktuell wichtigsten Features Ist fr die Umsetzung der Ziele verantwortlich berwacht die Aufteilung der Rollen und sorgt fr optimale Arbeitsbedingungen

Reihenfolge und Ablauf der Arbeit werden vollstndig vom Team bestimmt. Dazu dient das tgliche Meeting, in dem die Prioritten gesetzt, Hindernisse aufgezeigt und Mittel und Wege zur Zielerfllung ausgewhlt werden. All das erfolgt unter Einbeziehung mglichst vieler Teammitglieder. Der Scrum Master sorgt fr optimale Arbeitsbedingungen. Diese Organisation erfordert ein gewisses Umdenken im Vergleich zur gewohnten Arbeitsweise. Wichtig ist, dass die Methoden nicht aufgezwungen werden, sondern Agilitt als Kultur verstanden wird. Dann wird sich die neue Arbeitsweise schnell vorteilhaft auf die Stimmung und die Produktivitt auswirken.

10

Vertrauen statt Kontrolle, Motivation statt Gngelei, Risikoorientierung statt Sicherheitsfanatismus bewirken eine Steigerung des Selbstbewusstseins und erhhen die Motivation der Mitarbeiter. Die Erfahrung zeigt, dass trotz anfangs oft geuerter Skepsis der Mut zur Vernderung durch termingerecht fertiggestellte und funktionierende Software belohnt wird.

11

5. Agile Methoden bei Infopark

Besondere Eignung fr Web-Projekte
IT-Projekte im Web-Bereich weisen einige Besonderheiten auf. Dazu gehren: Am Projektbeginn existieren gewhnlich seitens des Kunden sehr unscharfe Vorstellungen von den Mglichkeiten des Mediums Internet. Daraus folgt ein hohes nderungspotenzial. Die Projektlaufzeiten sind kurz. Im Web gibt es besonders kurze Innovationszyklen. Die Projektteams sind klein, aber in der Zusammensetzung sehr heterogen (Programmierer, Graker, Redakteure, Usability-Tester, Marketing-Experten). Die Ergebnisse mssen sehr oft auf ihre Brauchbarkeit getestet werden. Die Ergebnisbewertung ist hug subjektiv.

Unter diesen Rahmenbedingungen kommen die Strken agiler Entwicklungsprozesse besonders zum Tragen. Das unkomplizierte Reagieren auf genderte Anforderungen, die kurzen Release-Zyklen und die stndige Kommunikation zwischen Kunden und Entwicklerteam fhren nach den Erfahrungen von Infopark in Web-Projekten zu sehr guten Resultaten. Als Beispiele seien Portal-Projekte der AIR LIQUIDE Deutschland GmbH und der Max-Planck-Gesellschaft erwhnt.

Workshops und Consulting

Das in diesem White Paper beschriebene Vorgehensmodell stellt nur eine kleine Auswahl aus vielen Techniken agiler Softwareentwicklung dar. In der Praxis wird es immer erforderlich sein, in enger Kooperation mit dem Kunden die passenden Methoden auszuwhlen und zu verfeinern. Wir vermitteln unsere Erfahrungen im Rahmen von Intensiv-Workshops und beraten Sie auch gern individuell bei der Einfhrung und Anwendung agilen Projektmanagements. Das betrifft beispielsweise folgende Methoden und Techniken: Ziele formulieren Nutzen berechnen Prioritten setzen Projekte steuern.

Bitte verwenden Sie bei Interesse unser Online-Formular: www.infopark.de/anfrage

12

6. Weiterfhrende Informationen
Checkliste Agiles Management fr erfolgreiche IT-Projekte
Die folgende Liste gibt Ihnen einen berblick darber, welche Kriterien im Zusammenhang mit dem Thema Agiles Management fr erfolgreiche IT-Projekte interessant sein knnen. Wenn die Mehrzahl der Aussagen zutrifft, stellt die Einfhrung und Anwendung agiler Methoden eine vielversprechende Alternative dar.

Entscheidungskriterien
Nutzer und Entwickler sprechen nicht immer eine Sprache und haben unterschiedliche Vorstellungen vom Projektziel. Wir arbeiten bei IT-Projekten regelmig mit externen Beratern zusammen. Die Erarbeitung und Aktualisierung der Projektspezikationen ist sehr aufwendig und bindet viele Ressourcen. Whrend eines Projektes entstehende neue Anforderungen werden selten oder nicht ausreichend bercksichtigt. Neue Technologien knnen wegen starrer Rahmenbedingungen nicht im Laufe der Entwicklung genutzt werden. Eine starke Arbeitsteilung erschwert den Wissenstransfer innerhalb des Entwicklerteams. Projekte werden mitunter nicht zum geplanten Endtermin fertig gestellt und/oder berschreiten das vorgesehene Budget. Das Produkt wird erst zur Projektabnahme dem Kunden vorgestellt. Bei der Projektabnahme gibt es oft unterschiedliche Meinungen ber den Erfllungsstand der Anforderungen.

Raum fr eigene Kriterien

13

Literatur
Natrlich knnen wir an dieser Stelle das Thema Agiles Management fr erfolgreiche IT-Projekte nur ansatzweise beleuchten. Diese Links und Bcher bieten Ihnen weitere Informationen zum Thema:

Links

Manifest der agilen Softwareentwicklung: www.agilemanifesto.org Agile Alliance: www.agilealliance.org Scrum: www.controlchaos.com Extreme Programming: www.extremeprogramming.org Agile Software Development with Scrum Ken Schwaber, Mike Beedle, PEARSON STUDIUM 2008 Extreme Programming - Das Manifest Kent Beck, Addison-Wesley 2004 User Stories Applied. For Agile Software Development. Mike Cohn, Addison-Wesley Professional 2004 Der Pragmatische Programmierer Andrew Hunt & David Thomas, Hanser Fachbuch 2003

Bcher

14

Kontakt
Sollten Sie weitere Fragen oder Anregungen haben, dann freuen wir uns ber Ihre Nachricht. Bitte wenden Sie sich an unser Communication Center: Infopark AG Communication Center Kitzingstrae 15, 12277 Berlin, Deutschland Tel. +49 30 747993-0, Fax +49 30 747993-93 www.infopark.de cc@infopark.de

Rechtliche Hinweise
Die Infopark AG ist bemht, die dargestellten Informationen zu Produkteigenschaften immer korrekt und fehlerfrei zu halten. Die Komplexitt einiger Produkteigenschaften und der technische Fortschritt in der Produktentwicklung machen jedoch laufende nderungen notwendig, die nicht immer in allen Verffentlichungen von Infopark gleichzeitig gepegt sind. Der rechtlich verbindliche Lieferumfang eines Produkts in einer bestimmten Version von Infopark wird ausschlielich durch die Angaben in den ofziellen Handbchern zu dem Produkt wiedergegeben. Infopark behlt sich das Recht vor, in spteren Versionen des Produkts Funktionen zu ndern, zu ergnzen oder nicht mehr zu liefern. Alle Warennamen oder Herstellernamen werden ohne Gewhrleistung der freien Verwendbarkeit benutzt und sind mglicherweise eingetragene Warenzeichen. Wir richten uns im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschlielich aller seiner Teile ist urheberrechtlich geschtzt. Alle Rechte vorbehalten, einschlielich der Vervielfltigung, bersetzung, Mikroverlmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Infopark AG, Berlin 2007-2009, Agiles Management fr erfolgreiche IT-Projekte

15