WHITE PAPER

Agiles Managementfür erfolgreiche IT-Projekte

1

Agiles Management für erfolgreiche IT-Projekte

KurzfassungNur eins von drei IT-Projekten verläuft im Durchschnitt erfolgreich. Verspätungen, Kostenexplosionen und ständige Anforderungsänderungen sind scheinbar normale Rahmenbedingungen der Softwareentwicklung. Weder die Kunden noch die Lieferanten sind damit zufrieden – aber lassen sich diese Mängel beseitigen?

Agiles Projektmanagement bietet neue Wege zur erfolgreichen Umsetzung von IT-Projekten. Traditionelle Techniken des Projektmanagements wie detaillierte Planun–gen und strenge Hierarchien werden durch Flexibilität, Kreativität und Kommuni–kation abgelöst. Ziel ist es, den Kunden durch die Auslieferung werthaltiger Software innerhalb möglichst 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 populär 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 für Web-Projekte: Erfolgsquote und Produktqualität werden deutlich gesteigert, Termine und Kosten bleiben unter Kontrolle. Es lohnt, sich damit genauer zu beschäftigen.

2

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. Anschließend wird die erarbeitete Spezifikation 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 fünfte Vorhaben scheiterte sogar komplett. Dass dieses Verhältnis seit längerem besteht, unterstreichen die Auswertungs-ergebnisse der Standish Group für die Jahre 1994-2004:

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

Auch Umfragen im nationalen Rahmen bestätigen diese Tendenzen (siehe z.B. www.gulp.de/kb/it/projekt/planungsmaengel_f.html). Immer wieder werden folgende Symptome als typisch für IT-Projekte benannt:

• Projekt dauert länger als erwartet

• Kosten sind höher als erwartet

• Anforderungen ändern sich

• Inhaltliche Umsetzung erfolgt mangelhaft

• Technologieentwicklung überholt das laufende Projekt.

Welche Begründung gibt es dafür?

3

Grenzen konventionellen Projektmanagements

Die Ursachen für diese unbefriedigenden Resultate liegen in der „Sucht“, alle Arbeitsschritte und Ergebnisse so exakt wie nur möglich 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 dafür geeignet ist. Eine Erhebung des OFFIS e. V. (Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme, www.offis.de) aus dem Jahr 2005 bestätigt sogar die Aussage, dass Projekte ohne spezielle Vorgaben eine höhere Erfolgsquote aufweisen als Projekte mit konkreten Vorgehensmodellen.

Der Grund ist einfach: Wir können nicht in die Zukunft sehen. Es ist schlicht unmöglich, vor Beginn einer Softwareentwicklung alle Anforderungen vorherzusehen und den Aufwand für die Arbeitsschritte genau zu prognostizieren. Jeder Versuch, das zu tun, gerät entweder zu allgemein oder zu detailliert und ist unausweichlich mit Fehlern behaftet. Während des Projekts gewonnene Erkenntnisse werden viel zu selten genutzt – denn dafür müsste die Spezifikation geändert werden.

„Kein Plan überlebt die erste Feindberührung.“

Helmuth Graf von Moltke

Durch die starke Arbeitsteilung im Team konzentriert sich jeder Mitarbeiter nur auf die vorgegebenen Aufgaben und ist nicht bereit, darüber hinaus Verantwortung zu übernehmen. Die Kommunikation im Team wird negativ beeinflusst, der Blick „über den Tellerrand“ für die ganzheitlichen Anforderungen geht verloren. Ein weiterer Nachteil ist der große Dokumentationsaufwand, der enorme Ressourcen bindet.

Offensichtlich wird ein anderer, mehr der menschlichen Natur entsprechender Ansatz benötigt, um IT-Projekte zur allseitigen Zufriedenheit abzuwickeln. Infopark nutzt dazu mit Erfolg unterschiedliche Techniken agiler Softwareentwicklung, die in den nächsten Kapiteln näher erläutert werden.

4

2. Das Konzept agiler Softwareentwicklung

Freiräume fürkreatives Handeln

Die grundlegenden Ideen agiler Softwareentwicklung entstanden in den 1990er Jahren. Die Entwicklung von Software sollte durch Verschlankung und Entbüro-kratisierung verbessert und beschleunigt werden. Ziel ist es, das konventionelle Anforderungskorsett aufzubrechen und die kreativen Potenziale aller Beteiligten zu erschließen.

Dafür werden neue Denkansätze und Werte benötigt. 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.Lauffähige Software ist wichtiger als umfangreiche Dokumentation.Reagieren auf Veränderung ist wichtiger als Planerfüllung.

„Manifest der Agilen Softwareentwicklung“ (www.agilemanifesto.org)

Die rechts stehenden Kriterien werden dabei nicht vernachlässigt, aber im Zweifelsfall bekommen die links genannten Werte den Vorzug. Dabei ist Agilität nicht zu verwechseln mit Anarchie. Im Gegenteil, aufgrund der gesteigerten Verantwortung jedes Einzelnen sind Disziplin und Initiative besonders gefragt.

Priorität hat generell die Erfüllung der Kundenbedürfnisse. 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 PrinzipienEin Projekt wird nicht einfach dadurch „agil“, indem man es so bezeichnet. Alle Beteiligten müssen bestimmte Prinzipien akzeptieren und auch bereit sein, danach zu arbeiten. Solche Prinzipien sind beispielsweise

• Kundennähe

• Transparenz

• Flexibilität und

• Teamfähigkeit.

Auf den genannten Werten und Prinzipien basieren alle agilen Softwareentwick-lungsprozesse. 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 populären Modellen ein. Diese werden durch eigene Erfahrungen und State-of-the-Art-Methoden erweitert. Was das konkret bedeutet, erläutert der nächste Abschnitt.

5

3. Mittel und Methoden agilen Projektmanagements

KontinuierlicherProzess

Klassische Softwareentwicklung unterscheidet verschiedene Phasen (Anforderungs-analyse, Entwurf, Test, Programmierung), die gewöhnlich 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, möglichst früh zu einer ausführbaren Version der Software zu gelangen. Diese wird dann in regelmäßiger Abstimmung mit dem Kunden erweitert und verfeinert, bis ein allseits befriedigender Stand erreicht ist.

Natürlich entsteht so ein Prototyp nicht von selbst. Auch agile Softwareentwicklung benötigt ein bestimmtes Maß an Organisation.

Angestrebten Nutzen klar definieren

Am Beginn des Projektes werden in einer Anforderungsanalyse die grundlegenden Projektziele und der damit verbundene Nutzen bestimmt. Dabei wird berücksichtigt, dass der Funktionsumfang einer Software von der überwiegenden Zahl der An-wender nur zu etwa einem Drittel ausgeschöpft wird. Zwei Drittel der verfügbaren Möglichkeiten werden dagegen selten oder gar nicht benötigt. Der unverhältnis-mäßig große Aufwand für 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 möglichst geringem Erstellungsaufwand den höchsten Nutzen erbringen.

6

Unterteilungin Stories

Um den Planungsaufwand niedrig zu halten, wird bei agiler Softwareentwicklung keine detaillierte Spezifikation erstellt. Für 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 situationsabhängig änderbar.

Für die Protokollierung gibt es keine Vorgaben, es genügen formlose, aber präzise Beschreibungen auf einfachen Karten („Story Cards“). Diese Story Cards werden für alle Beteiligten gut sichtbar an einer zentralen Stelle platziert. Sie dienen im gesamten Projektablauf als wichtiges Kommunikationsmedium zwischen Kunde und Entwickler.

Beispiele für Story Cards bei Infopark

7

Abstrakte Aufwands- und Risikobewertung

Die Abschätzung des zeitlichen und personellen Aufwands für die Realisierung einer Story ist auch für erfahrene Mitarbeiter problematisch. In der agilen Software-entwicklung werden dafür keine konkreten Größen (Zeit, Geld) genutzt. Die Aufwandsbewertung erfolgt statt dessen in abstrakten Einheiten, beispielsweise unter Verwendung einer nicht-linearen Punkteskala. Die verwendeten Abstufungen sollten einfache Vergleichsabschätzungen zwischen den Stories zulassen, beispielsweise (nach Mark Cohn):

• eine Skala mit den Werten 1, 2, 3, 5, 8: für Story C (Aufwand = 3) benötigen wir genau so lange wie für Story A (Aufwand = 1) und Story B (Aufwand = 2) zusammen oder

• eine Skala mit den Werten 1, 2, 4, 8: für Story C (Aufwand = 4) benötigen wir doppelt so lange wie für Story B (Aufwand = 2).

Ergibt die Abschätzung in diesen Fällen einen Wert größer als 8, muss die Story weiter untergliedert werden. Im Projektverlauf werden die Aufwandsabschätzungen mit den tatsächlichen Ergebnissen verglichen und bei Bedarf korrigiert. Dadurch sind zunehmend genauere Schätzungen über die verbleibenden Aufwände möglich.

Für die Risikobewertung bezüglich Zeitplan, Kosten und Funktionalität genügen zwei (gering – hoch), maximal drei Stufen.

Sprints und Planning GameEin grundlegendes Prinzip agilen Projektmanagements ist das Vorgehen in kurzen überschaubaren Etappen konstanter Länge (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 Prioritäten zugeordnet. Das erfolgt durch den Kunden und die Entwickler gemeinsam. Die Prioritäten werden dabei nach folgenden Kriterien vergeben:

Risiko Nutzen Priorität

Hoch Hoch 1

Gering Hoch 2

Gering Gering 3

Hoch Gering Diese Kombination ist möglichst zu vermeiden

8

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 schätzen deren Aufwand ab. In täglichen 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 SprintsErweist sich der geschätzte Aufwand für eine Story als zu gering, wird die Story entweder aufgeteilt oder komplett auf den nächsten Sprint verschoben. Auch die Repriorisierung von Stories während eines Sprints ist möglich.

Am Ende jedes Sprints steht eine neue ausführbare Version der Software. Diese ist Gegenstand eines Akzeptanztests (des „Sprint-Reviews“). Gemeinsam mit dem Kunden wird im Review bestimmt, wie weit die Anforderungen erfüllt wurden und welche Leistungsmerkmale im nächsten Sprint realisiert werden sollen.

Änderungen gegenüber bisherigen Planungen sind dabei willkommene Chancen zur Verbesserung der Produkteigenschaften („Feedback-Loops“). Nicht selten erweist sich im Verlaufe des Projektfortschritts, dass die Realisierung ursprünglich vorgesehener Ziele einen zu geringen Nutzen erbringen würde. Es wird dann gemeinschaftlich entschieden, ob diese Funktionen trotzdem zur Verfügung gestellt werden oder ob auf sie verzichtet werden kann, ohne dass Einschränkungen in der Benutzbarkeit der Software entstehen.

Veränderungen sind willkommen – Projektfortschritt mit Sprints

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

9

4. Vorteile und Anforderungen

Nutzen für beide SeitenDas im vorigen Abschnitt beschriebene iterative Vorgehen in enger Kommunikation mit dem Kunden – ein grundlegendes Element agiler Softwareentwicklung – erweist sich in der Praxis aus vielen Gründen vorteilhaft:

• Die Orientierung auf den maximalen Nutzen führt zu schnellen Erfolgen.

• Es gibt schnelles Feedback speziell zur Umsetzung der wichtigsten Funktionen.

• Fehler in der Konzeption bzw. Umsetzung werden schnell erkannt und können sofort beseitigt werden.

• Das Risiko von Fehlentwicklungen wird minimiert.

• Eine gleichmäßige Auslastung des Projektteams wird gesichert.

• Zeitplan und Kosten bleiben unter Kontrolle – der typische fehlerbehaftete Finalstress wird vermieden.

• Neu gewonnene Erkenntnisse fließen ständig in die Entwicklung ein.

• Durch die intensive Kommunikation kann der Umfang der Dokumentation auf ein vernünftiges Maß reduziert werden.

Das Team entscheidetAuch die agile Softwareentwicklung kann keine hundertprozentige Erfolgsgarantie bieten. Die Bereitschaft zur Flexibilität, 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 uneingeschränkte Unter-stützung durch Auftraggeber und Management spielen ebenfalls eine wichtige Rolle. Statt komplizierter Hierarchien gibt es beispielsweise im Scrum-Modell lediglich drei klar definierte Rollen:

Product Owner(in der Regel der Kunde)

Trägt die Gesamtverantwortung, definiert die Zielsetzungen und aktuell wichtigsten Features

Team Ist für die Umsetzung der Ziele verantwortlich

Scrum Master Überwacht die Aufteilung der Rollen und sorgt für optimale Arbeitsbedingungen

Reihenfolge und Ablauf der Arbeit werden vollständig vom Team bestimmt. Dazu dient das tägliche Meeting, in dem die Prioritäten gesetzt, Hindernisse aufgezeigt und Mittel und Wege zur Zielerfüllung ausgewählt werden. All das erfolgt unter Einbeziehung möglichst vieler Teammitglieder. Der Scrum Master sorgt für optimale Arbeitsbedingungen.

Diese Organisation erfordert ein gewisses Umdenken im Vergleich zur gewohnten Arbeitsweise. Wichtig ist, dass die Methoden nicht aufgezwungen werden, sondern Agilität als Kultur verstanden wird. Dann wird sich die neue Arbeitsweise schnell vorteilhaft auf die Stimmung und die Produktivität auswirken.

10

Vertrauen statt Kontrolle, Motivation statt Gängelei, Risikoorientierung statt Sicherheitsfanatismus bewirken eine Steigerung des Selbstbewusstseins und erhöhen die Motivation der Mitarbeiter. Die Erfahrung zeigt, dass trotz anfangs oft geäußerter Skepsis der Mut zur Veränderung durch termingerecht fertiggestellte und funktionierende Software belohnt wird.

11

5. Agile Methoden bei Infopark

Besondere Eignung für Web-Projekte

IT-Projekte im Web-Bereich weisen einige Besonderheiten auf. Dazu gehören:

• Am Projektbeginn existieren gewöhnlich seitens des Kunden sehr unscharfe Vorstellungen von den Möglichkeiten 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, Grafiker, Redakteure, Usability-Tester, Marketing-Experten).

• Die Ergebnisse müssen sehr oft auf ihre Brauchbarkeit getestet werden.

• Die Ergebnisbewertung ist häufig subjektiv.

Unter diesen Rahmenbedingungen kommen die Stärken agiler Entwicklungsprozesse besonders zum Tragen. Das unkomplizierte Reagieren auf geänderte Anforderungen, die kurzen Release-Zyklen und die ständige Kommunikation zwischen Kunden und Entwicklerteam führen 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 erwähnt.

Workshops und ConsultingDas 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 auszuwählen und zu verfeinern.

Wir vermitteln unsere Erfahrungen im Rahmen von Intensiv-Workshops und beraten Sie auch gern individuell bei der Einführung und Anwendung agilen Projekt-managements. Das betrifft beispielsweise folgende Methoden und Techniken:

• Ziele formulieren

• Nutzen berechnen

• Prioritäten setzen

• Projekte steuern.

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

12

6. Weiterführende Informationen

Checkliste „AgilesManagement für

erfolgreiche IT-Projekte“Die folgende Liste gibt Ihnen einen Überblick darüber, welche Kriterien im Zusammenhang mit dem Thema „Agiles Management für erfolgreiche IT-Projekte“ interessant sein können. Wenn die Mehrzahl der Aussagen zutrifft, stellt die Einführung 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 regelmäßig mit externen Beratern zusammen.

Die Erarbeitung und Aktualisierung der Projektspezifikationen ist sehr aufwendig und bindet viele Ressourcen.

Während eines Projektes entstehende neue Anforderungen werden selten oder nicht ausreichend berücksichtigt.

Neue Technologien können 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 Erfüllungsstand der Anforderungen.

Raum für eigene Kriterien

13

LiteraturNatürlich können wir an dieser Stelle das Thema „Agiles Management fürerfolgreiche IT-Projekte“ nur ansatzweise beleuchten.

Diese Links und Bücher 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

Bücher • „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

14

KontaktSollten Sie weitere Fragen oder Anregungen haben, dann freuen wir uns über Ihre Nachricht. Bitte wenden Sie sich an unser Communication Center:

Infopark AGCommunication CenterKitzingstraße 15, 12277 Berlin, DeutschlandTel. +49 30 747993-0, Fax +49 30 747993-93

www.infopark.decc@infopark.de

Rechtliche HinweiseDie Infopark AG ist bemüht, die dargestellten Informationen zu Produkteigenschaften immer korrekt und fehlerfrei zu halten. Die Komplexität einiger Produkteigenschaften und der technische Fortschritt in der Produktentwicklung machen jedoch laufende Änderungen notwendig, die nicht immer in allen Veröffentlichungen von Infopark gleichzeitig gepflegt sind.

Der rechtlich verbindliche Lieferumfang eines Produkts in einer bestimmten Version von Infopark wird ausschließlich durch die Angaben in den offiziellen Handbüchern zu dem Produkt wiedergegeben. Infopark behält sich das Recht vor, in späteren Versionen des Produkts Funktionen zu ändern, zu ergänzen oder nicht mehr zu liefern.

Alle Warennamen oder Herstellernamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Wir richten uns im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten, einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

© Infopark AG, Berlin 2007-2009, Agiles Management für erfolgreiche IT-Projekte

15