Seminar Einführung agiler Projektmanagementmethoden für Softwareentwicklung in der IuK-Industrie Fallstudie und Handlungsempfehlungen

Transkript

1 Wirtschaftsinformatik Universität Augsburg Systems Engineering Seminar Einführung agiler Projektmanagementmethoden für Softwareentwicklung in der IuK-Industrie Fallstudie und Handlungsempfehlungen Stefan Wind, Holger Schrödl Lehrstuhl für Betriebswirtschaftslehre, Wirtschaftsinformatik und Systems Engineering Universität Augsburg Universitätsstraße 16, Augsburg Tel.: +49 (821) , Fax URL:

2 Agenda I. Vorstellung Lehrstuhl II. Motivation III. Agile Vorgehensweisen IV. Beschreibung der Fallstudie V. Handlungsempfehlungen VI. Zusammenfassung und Ausblick 2

4 I. Lehrstuhl Wirtschaftsinformatik und Systems Engineering Überblick Im Rahmen der High-Tech-Offensive des Landes Bayern im Jahr 2001 gegründet. Positioniert als ein interdisziplinärer Lehrstuhl an der Schnittstelle von Wirtschaftswissenschaften und Informatik. Besonders wichtig ist die Verbindung von theoretischen Forschungsergebnissen mit Erfahrungen aus Praxis- Kooperationen. Ein starker Ansprechpartner für Unternehmen, beispielsweise im Bereich Business-to-Business Electronic Commerce. 4

5 I. Lehrstuhlinhaber Prof. Dr. Klaus Turowski Vita Klaus Turowski studierte Wirtschaftsingenieurwesen an der Universität Karlsruhe und promovierte am Institut für Wirtschaftsinformatik der Universität Münster. Habilitation an der Universität Magdeburg im Fach Wirtschaftsinformatik. Leitet den Lehrstuhl für Wirtschaftsinformatik und Systems Engineering an der Universität Augsburg. Klaus Turowski Darüber hinaus ist er Gastdozent an verschiedenen ausländischen Universitäten. Praktische Erfahrungen sammelte er im Rahmen zahlreicher Projekte in der Wirtschaft. 5

7 II. Motivation Motivation Klassische Vorgehensmodelle stoßen im Hinblick auf die veränderten Rahmenbedingungen häufig an ihre Grenzen. Besonderheiten im Softwaremanagement müssen im Projektmanagement berücksichtigt werden. Agile Vorgehensmodelle versprechen hier eine Verbesserung, sind jedoch nur selten out of the box anwendbar. 7

8 II. Motivation Projekterfolgsquoten aus den Chaos-Reports Ø 70% der Probleme basieren auf Unzulänglichkeiten im Projektmanagement. Quelle: Pohl (2008), S. 9 8

9 II. Motivation Offene Fragen Wie wird eine agile Methode am besten in einem realen Unternehmen und in einem konkreten Projekt eingeführt? Wie sieht die Anwendung einer agile Methode in der Praxis überhaupt aus und welche Erfahrungen können gesammelt werden? Welche praktische Handlungsempfehlungen können für die Einführung einer agilen Methode daraus abgeleitet werden? 9

11 III. Agile Vorgehensweisen Im Jahr 2001 veröffentlichten 17 namhafte Vordenker agiler Vorgehensweisen als Gegenbewegung zu den klassischen Vorgehensweisen eine Grundsatzerklärung über die Werte eines agilen Vorgehens, welche unter dem Begriff des agilen Manifests bekannt wurde. 11

12 III. Agile Vorgehensweisen Ziele bei der Einführung eines agilen Vorgehens Vgl. Schwaber C. (2007), S. 4 12

13 III. Agile Vorgehensweisen Im Laufe der Zeit haben sich viele verschiedene agile Methoden / Vorgehensweisen entwickelt. Diese verfolgen zwar im Grundsatz alle die agilen Werte und Prinzipien, unterscheiden sich aber wesentlich in Umfang und Detaillierungstiefe. Bekannte Vertreter sind: Xtreme Programming (XP) Crystal-Methodenfamilie von Alistair Cockburn Feature Driven Development (FDD) von Jeff DeLuca Scrum von Ken Schwaber, Jeff Sutherland und Mike Beedle 13

15 Agenda IV. Beschreibung der Fallstudie IV.1 Ausgangssituation Unternehmen und Umfeld Szenario Projekt Bisher üblicher Projektablauf IV.2 Durchführung Auswahl der agilen Methode Vorbereitung Durchführung des agilen Projektmanagements IV.3 Bewertung und Erfahrung für das konkrete Projekt Bewertung der agilen Vorgehensweise für das konkrete Projekt Erfahrungen im Projektverlauf 15

16 IV.1 Ausgangssituation Unternehmen und Umfeld Unternehmen aus dem Bereich der IuK-Industrie Weltweites Angebot von Produkten und Servicedienstleistungen Mitarbeiter an mehreren Standorten weltweit Dynamisches Umfeld, Konfrontation mit sich ändernden Zielen, Anforderungen und Märkten Verbesserungswürdige bisherige Projektbilanz Ø Die Anwendung des agilen Projektmanagements ist aus diesen Gründen besonders interessant. 16

17 IV.1 Ausgangssituation Szenario Projekt Gezielt (geschäftsrelevant und typisch, nicht aber überlebenswichtig ist) für die Anwendung ausgewählt. Projekt: Design und Implementierung eines Management Cockpits für den Bereich Finance und Controlling mit SAP. Umfang von ca. 300 Personentagen; acht Mitarbeiter, alle am selben Standort tätig. Beteiligte Mitarbeiter verfügten noch nicht über praktische Erfahrungen in der Anwendung agiler Vorgehensmodelle. Bisher bestand ein organisationsspezifisches Projekthandbuch (wasserfallartig), das das Vorgehen im Projektmanagement regelte. 17

18 IV.1 Ausgangssituation- Management Cockpit Ziel: Effiziente und optimale grafische Aufbereitung von Informationen im Zusammenhang für die Führungsebene eines Unternehmens. Umwandlung von Zahlenfriedhöfen in entscheidungsrelevante Informationen, um Wettbewerbsvorteile für das Unternehmen zu generieren. 18

19 IV.1 Ausgangssituation Bisher üblicher Projektablauf Bisher bestand ein organisationsspezifisches Projekthandbuch, das das Vorgehen im Projektmanagement regelte. Das Vorgehensmodell war wasserfallartig aufgebaut. Es waren weder weitergehende Rückkopplungen noch Iterationen zwischen den einzelnen Phasen vorgesehen. 19

20 IV.2 Durchführung Auswahl der agilen Methode Es gibt keine agile Standardmethode! Das würde auch der agilen Philosophie widersprechen. Für jedes Projekt soll individuell die angemessene Methode bzw. Vorgehensweise ausgewählt werden und jene soll dann kontinuierlich auf Praktikabilität hin überprüft werden. Ausführliche Analyse der Projektziele, -eigenschaften und risiken. Im Rahmen des Auswahlprozesses wurden die Eignung der agile Methoden SCRUM, XP und FDD genau für dieses Projekt untersucht. 20

21 IV.2 Durchführung Projekteigenschaften Kriterium Eindeutigkeit der Projektziele Komplexität der Aufgabe Ausprägung Wenig Mittel Stark Extrem X Ein Ziel für alle wesentliche Punkte X Hoch Umfang der Aufgabe X Bis zu 300 PT X Bekanntheitsgrad Anzahl beteiligter Stakeholder Neuer Kunde aber bekannte Branche und Aufgabentyp X Bis zu 20 Stakeholder Verfügbarkeit von Anforderungen zu Beginn X Die Anforderungen müssen erst erarbeitet werden. Wahrscheinliche Änderungen von Anforderungen während der Projektlaufzeit X Hoch aufgrund neuer Erkenntnisse 21

22 IV.2 Durchführung Projektrisiko Der Entwurf und die Implementierung eines Management Cockpits stellte ein komplexes Vorhaben bei einer bekannten Problemstellung dar. Der Abstimmungsaufwand zur Auswahl der geeigneten Kennzahlen inklusive ihrer visuellen Darstellungsform wurde als hoch eingeschätzt. Hinsichtlich der vorgesehenen, bereits bewährten Technologie (SAP SEM) bestanden keine Bedenken. Verlust der getätigten monetären und zeitlichen Investition im Falle eines Scheiterns sowie Gefahr von falschen Schlussfolgerungen im Falle von fehlerhafter Software. Ø Mittleres bis hohes Gesamtrisiko. 22

23 IV.2 Durchführung Auswahl der agilen Methode FDD wurde nicht gewählt, da es schwer gewesen wäre, im ersten Schritt ein stabiles Gesamtmodell zu erstellen. XP erschien für das erste agile Projekt nicht optimal geeignet, da es radikal neue Vorgehensweisen fordert, die zunächst oft auf Unverständnis bei den Beteiligten stoßen und eine Abwehrhaltung hervorrufen. Der Fokus von XP liegt stark auf programmiertechnischen Ansätzen, im aktuellen Fall kam jedoch auch der Konzeption der Ermittlung der Finanzkennzahlen eine hohe Bedeutung zu. 23

24 IV.2 Durchführung Auswahl der agilen Methode SCRUM wurde als agile Projektmanagementmethode ausgewählt, da es für die aktuelle Situation des Pilotprojekts gegenüber den anderen Methoden zwei entscheidende Vorteile hatte: SCRUM eignet sich gut, wenn sich Anforderungen im Voraus nicht genau festlegen lassen und eher chaotische Bedingungen antizipiert werden müssen Das Verfahren lässt sich leicht erlernen und für die Beteiligten auf wenigen Seiten beschreiben, was bei der der Erstdurchführung eines agilen Projekts nicht zu unterschätzen ist. 24

25 IV.2 Durchführung Rahmenbedingungen Um SCRUM erstmalig im Projekt einsetzen zu können, war eine Vorbereitung der Organisation und der betroffenen Mitarbeiter notwendig. Im Projektrahmen waren die verfügbaren Möglichkeiten jedoch begrenzt. So konnte weder eine Organisationsänderung noch eine groß angelegte Einführung als eigenständiges SCRUM- Projekt durchgeführt werden. Im Rahmen der zur Verfügung stehenden Möglichkeiten wurde eine Vorbereitung durchgeführt, die sicherlich auch für Projektleiter in ähnlichen Konstellationen interessant sein kann. 25

26 IV.2 Durchführung Vorbereitung der eigentlichen Durchführung Änderungsbedarf anhand einer Fallstudie aufzeigen. Agiles Projektmanagement anhand eines praktischen Beispiels vorstellen. Sicherung der Management-Unterstützung durch Aufzeigen von Potenzialen. Ausgewähltes Pilotprojekt anhand des Projektauftrags vorstellen. Beteiligte Mitarbeiter intensiv schulen. 26

27 IV.2 Durchführung Rollen besetzen Im nächsten Schritt wurden die Rollen Product Owner, SCRUM Master und Team besetzt.. Für die Rolle des SCRUM-Masters wurde ein zertifizierter und erfahrener, externer Mitarbeiter eingesetzt. Für die Rolle des Product Owners konnte ein langjähriger Mitarbeiter aus dem Fachbereich Finance und Controlling gewonnen werden (fachliche Erfahrung & Entscheidungsbefugnis). Das Team beinhaltet alle notwendigen Experten (drei SAP SEM Experten, ein Reporting-Experte, zwei fachliche Kennzahlen-Experten und zwei Tester). 27

28 IV.2 Durchführung Projektdurchführung anhand von SCRUM Nach Durchführung dieser vorbereitenden Schritte wurde das Projekt mit dem gewählten Modell realisiert. Quelle: Mountaingoatsoftware (o. J.) 28

29 IV.2 Durchführung Beispiel Ergebnis nach ersten Sprints 29

30 IV.3 Bewertung und Erfahrung Übergreifende Feststellungen Grundsätzlich ist als wichtigste Erkenntnis für das durchgeführte Pilotprojekt festzustellen, dass SCRUM als agile Projektmanagementmethode funktioniert hat. Das Projekt wurde erfolgreich abgeschlossen und hat die Erwartungen der Beteiligten erfüllt. Naturgemäß zeigt die erste Anwendung von SCRUM jedoch auch noch einiges an Verbesserungspotenzial auf. 30

31 IV.3 Bewertung und Erfahrung Bewertung der agilen Vorgehensweise für das konkrete Projekt Der unklaren Ausgangslage des Projekts konnte mit SCRUM gut begegnet werden. Die Aufteilung des Projektablaufs in mehrere Sprints erlaubte es, Anforderungen schrittweise umzusetzen und frühzeitig Feedback von den zukünftigen Anwendern zu erhalten. Im Gegenzug konnten diese die korrekte Umsetzung ihrer Anforderungen zeitnah überprüfen und bei Bedarf bis dato nicht berücksichtigte, zusätzliche Anforderungen in das Projekt einfließen lassen. Beide Seiten profitierten durch die frühzeitige und iterative Vorstellung des entstehenden Cockpits und die Möglichkeit der produktiven Nutzung bereits fertiggestellter Teile. 31

32 IV.3 Bewertung und Erfahrung Herausforderungen Vertragsgestaltung für den Einkauf der externen Entwickler und des Reporting-Experten. Überwindung von Widerständen gegen ein agiles Projektvorgehen und falsche Vorstellungen darüber in der Organisation. Auswahl der geeigneten agilen Methode für das Projekt. In der Praxis gestaltete sich das Leben der SCRUM-Rollen nicht ganz unproblematisch. Trotz des zu Beginn einfach erscheinenden Projektablaufs war viel Selbstdisziplin, Entscheidungsfähigkeit und Selbstorganisation von jedem Einzelnen verlangt. 32

33 IV.3 Bewertung und Erfahrung Erfahrungen bei der Projektdurchführung Quelle: Mountaingoatsoftware (o. J.) 33

34 IV.3 Bewertung und Erfahrung Product und Sprint Backlog Ein erfahrener SCRUM-Master erwies sich im Projektverlauf als sehr wertvoll. Die im Product Backlog enthaltenen Anforderungen eindeutig zu beschreiben, erwies sich als schwierig. Für die Festlegung der für das Team optimalen Darstellung des Sprint Backlogs wurde mit verschiedenen Formaten experimentiert. 34

35 IV.3 Bewertung und Erfahrung Sprint-Planungsmeeting Das Sprint Planungsmeeting ist wichtig und nicht zu unterschätzen. Die Teilnahme des Product Owners erwies sich hier als schwierig, dennoch wurde konsequent auf seiner Teilnahme bestanden. Dies war wichtig, da Antworten zu Fragen zum Teil anders als vermutet waren und damit zu völlig anderen Aufwandsschätzungen durch das Team führten. Der Product Owner war seinerseits über den geschätzten Aufwand erstaunt und musste daraufhin den Umfang reduzieren oder die Anforderungen neu priorisieren. 35

36 IV.3 Bewertung und Erfahrung Sprintdurchführung inkl. Daily Scrum In der Sprintdurchführung war es zum Teil schwierig, Störungen vom Team fernzuhalten. In ausgewählten Phasen, wie bei der Erstellung von kritischen Abfragen, wurde beispielsweise das Paarprogrammieren von XP erfolgreich eingesetzt. Tägliche und pünktliche Durchführung des Sprint Meeting erwies sich schwieriger als gedacht. Hinzu kam das einige Teammitglieder im Meeting zunächst angaben nicht zu wissen, was am aktuellen Tag sinnvoll zu erledigen wäre. 36

37 IV.3 Bewertung und Erfahrung Sprint Review & Retrospektive Die Vorführung der Ergebnisse am Ende des Sprints entwickelte sich im Projektverlauf zu einem wichtigen und wertvollen Ereignis. Zu Beginn des Projekts neigte das Team dazu, die Sprint Retrospektive ausfallen zu lassen. Dem wirkte der SCRUM-Master jedoch strikt entgegen, was sich am Ende als absolut zielführend herausstellte. So war es möglich, aufbauend auf den gewonnenen Erkenntnissen neue Ideen im Team zu generieren und in die nächsten Phasen einzubringen. 37

38 IV.3 Bewertung und Erfahrung Beispielhafte Ergebnisse der SPRINT Retrospektive 38

39 IV.3 Bewertung und Erfahrung Zusammenfassung Abschließend kann festgestellt werden, dass im Rahmen dieses Pilotprojekts viele wertvolle Erkenntnisse für die zukünftige Anwendung von SCRUM im Unternehmen gewonnen werden konnten. Fazit: Zum einen erfordert auch die Anwendung einer agilen Methode die notwendige Disziplin und Konsequenz, wenn sie zum Erfolg führen soll. Zum anderen ist die Einführung von SCRUM nicht in wenigen Wochen möglich, sondern beinhaltet einen kontinuierlichen Lernprozess, der professionell begleitet werden muss. 39

41 V. Handlungsempfehlungen Allgemein Aufbauend auf den gesammelten Erfahrungen und bestehenden theoretischen Empfehlungen (siehe Ec04], [Hi04], [Co05], [Sc07], [Pi08]) sollen nachfolgend Hinweise gegeben werden, die bei der Anwendung agiler Vorgehensweisen in anderen Bereichen und Unternehmen helfen können. 41

42 V. Handlungsempfehlungen Grundlegende Empfehlungen Beteiligte Personen und Unternehmensbereiche sind auf die zu erwartenden Neuerungen vorzubereiten. Bei der Auswahl des Pilotprojekts ist darauf zu achten, dass es geschäftsrelevant und typisch für das Umfeld, jedoch nicht überlebenswichtig ist. Im Vorfeld sind die Projekteigenschaften und Risiken mit einer Bewertungsmatrix zu ermitteln und kontinuierlich zu überprüfen. Es sind je nach Projekt angemessene Methoden auszuwählen und jene kontinuierlich auf ihre Praktikabilität hin zu überprüfen. 42

43 V. Handlungsempfehlungen SCRUM-spezifische Empfehlungen Die wenigen klar definierten Regeln in SCRUM sind absolut konsequent einzuhalten, um den Erfolg der Methode sicherzustellen. Der Product Owner soll neben seiner fachlichen Kompetenz auch über entsprechende Entscheidungsbefugnis verfügen. Alle benötigen Rollen, die zur Umsetzung der Projekt- und Sprintziele benötigt werden, müssen auch im Team vertreten sein. Für die erstmalige Einführung empfiehlt es sich, einen zertifizierten und erfahrenen externen SCRUM-Master einzusetzen. 43

44 V. Handlungsempfehlungen SCRUM-spezifische Empfehlungen Anlage einer Sprint-Infoseite, damit alle Stakeholder aus erster Hand über den Stand des Projekts informiert sind und das Aufkommen von Gerüchten und das Treffen von Annahmen möglichst unterbunden werden. Verwendung eines Releaseplans, um den Fertigstellungstermin, Funktionalität und Kosten leichter miteinander in Einklang zu bringen. 44

46 VI. Zusammenfassung und Ausblick Allgemein Die Arbeit lieferte anhand der Erfahrungen aus einer Fallstudie in der Praxis Empfehlungen bei der Einführung eines agilen Vorgehensmodells in der IuK-Industrie. Es konnten vier allgemein gültige sowie sechs methodenspezifische Empfehlungen für die Einführung herausgearbeitet werden. Weiterer Forschungsbedarf besteht in der Erprobung in weiteren Branchen, in der Kombination sowie in der Einführung in einem interkulturellen Umfeld. 46

47 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? 47

48 Kontakt: Master of Science (Univ.) Stefan Wind Wissenschaftlicher Mitarbeiter Lehrstuhl Wirtschaftsinformatik & Systems Engineering Universität Augsburg Tel.: +49 (1 76)