22 l projekt MA N A G E M E N T aktuell 1/ 2013 34 WISSEN Funktionalitäten entsteht. Ein Sprint dauert zwischen zwei und vier Wochen. Während eines Sprints finden täglich Scrum-Meetings statt. Am Ende jedes Sprints wird eine Sprint-Demo durchgeführt, in der das Ergebnis der Iteration präsentiert wird, und eine Sprint-Retrospektive, in der Verbesserungsmaßnahmen durch das Team ausgearbeitet werden [3, S. 111]. In Abbildung 1 sind die einzelnen Bestandteile von Scrum sowie deren Zusammenhänge grafisch dargestellt. Durch das Sammeln von Anforderungen im Product Backlog stellt Scrum sicher, dass auch im Projektverlauf Anforderungen geändert werden können. Lediglich die Tasks, die gerade im Sprint bearbeitet werden, dürften nicht verändert werden. Somit tragen schon die Gestaltung des Scrum-Prozesses und die dort verwendeten Artefakte dem Zielkonflikt „Flexibilität“ versus „Effizienz“ Rechnung. Dieses Bestreben, Effizienz und Flexibilität bereits durch die Prozessgestaltung sicherzustellen, wird durch die Rollenaufteilung zielgerichtet weitergeführt. 1.2 Der Faktor Mensch im Mittelpunkt - Das Rollenkonzept in Scrum Wesentlicher Erfolgsfaktor von Scrum ist das veränderte Mitarbeiterbild, das diesem Vorgehensmodell zugrunde liegt. Scrum-Projekte kommen ohne klassischen Projektleiter und ohne hierarchische Projektstruktur aus. Im Mittelpunkt steht das Entwicklungsteam, dem die Projektsteuerung weitgehend überlassen wird. Es legt die Aufgaben aus dem Product Backlog, die im nächsten Sprint bearbeitet werden, fest. Während der eigentlichen Aufgabenbearbeitung steht das Team vor allem durch das tägliche Scrum-Meeting in ständigem Austausch miteinander. Die Teams müssen dabei klein genug gehalten Das aktuelle Stichwort Potenziale und Grenzen agiler Vorgehensmodelle Eine Best Practice-Analyse Durch hohe Produktanforderungen bei gleichzeitig kürzer werdenden Produktlebenszyklen steigen auch die Anforderungen, die an Prozesse des Projektmanagements gestellt werden. Diese müssen einen effizienten Projektablauf sicherstellen und dabei ausreichend flexibel gestaltet sein, um auch auf Anforderungsänderungen reagieren zu können. Nicht zuletzt spielt der Faktor „Mensch“ eine große Rolle. Im Bereich der Softwareentwicklung haben sich verschiedene Vorgehensmodelle entwickelt, die aktuelle Herausforderungen in unterschiedlicher Weise aufgreifen. Während klassische Modelle mehr und mehr in den Hintergrund treten, erfreuen sich agile Vorgehensmodelle steigender Beliebtheit. Vor allem Scrum wird zunehmend eingesetzt, zum Teil ergänzt um Werte und Prinzipien anderer Vorgehensmodelle. Franziska Krodel 1 Effizienz, Transparenz und Flexibilität durch agile Softwareentwicklung 1.1 Scrum in a Nutshell Scrum ist ein flexibles Managementframework der Softwareentwicklung, welches die Regeln des agilen Manifests umsetzt. Scrum selbst gibt keine Techniken zur Erstellung von Software vor, sondern schafft lediglich einen Rahmen, innerhalb dessen verschiedene Techniken eingesetzt werden [1, S. 3]. Die Kernstücke des Scrum-Prozesses stellen das Product Backlog, das daraus resultierende Sprint Backlog, die Sprints, die Scrum-Meetings und der Abschluss der Sprints dar [2, S. 120]. Das Product Backlog enthält alle Anforderungen an das Produkt. Die Anforderungen werden zu Beginn jeder Iteration vom Team in kleinere Teile, die sogenannten Tasks, aufgeteilt und in das Sprint Backlog übertragen [2, S. 124]. Anschließend wird ein Sprint durchgeführt, woraus ein fertiges Produkt mit neuen Mit Blick auf Effizienz, Transparenz und Flexibilität werden agilen Methoden der Softwareentwicklung große Potenziale zugeschrieben - gerade im Praxiseinsatz stoßen sie jedoch auch an Grenzen. Um einen umfassenden Einblick in den Praxiseinsatz agiler Methoden zu erhalten, wurden verschiedene Experten aus international agierenden mittelständischen und Großunternehmen der Softwarebranche ausführlich befragt. Nach eingehender Analyse wurden deren Kernaussagen zu Best Practices und einem Risikoprofil verdichtet. Ausgehend von diesen Analysen wird ein Kombinationsmodell entwickelt, das Elemente verschiedener agiler Methoden miteinander kombiniert und so eine größtmögliche Ausschöpfung der Potenziale sicherstellen kann. +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 34 werden, um intensiv miteinander kommunizieren zu können, und interdisziplinär zusammengestellt werden, um einerseits den Projektanforderungen Rechnung tragen zu können, andererseits ein Verständnis für „das große Ganze“ zu fördern [3, S. 13-17]. Um ein reibungsfreies, effizientes Arbeiten im Team sicherzustellen, wird dieses durch zwei weitere Rollen ergänzt: den Product Owner und den Scrum Master. Der Product Owner repräsentiert die Bedürfnisse des Endkunden [3, S. 9]. Er hat die Aufgabe, die vom Kunden an die Software gestellten Anforderungen im Product Backlog zu erfassen, zu priorisieren und im Projektverlauf weiter anzupassen [4, S. 13]. Demnach ist der Product Owner für die gesamte Kommunikation mit dem Kunden verantwortlich. Aufgabe des Scrum Masters ist es, dafür zu sorgen, dass Scrum als Prozess richtig umgesetzt wird. Dies umfasst insbesonders die Aufgabe, das Entwicklungsteam vor äußeren Störungen zu schützen und somit effizientes Arbeiten zu ermöglichen. Dieses Streben nach Effizienz bedingt dabei vor allem, während eines Sprints keine Änderungen an den im Sprint Backlog ausgewählten Aufgaben mehr zuzulassen und die Entwickler vor projektfremden Aufgaben zu schützen. Dieses innovative Rollenkonzept schafft transparente Kommunikationswege - wie Abbildung 2 zeigt. Der Kunde hat einen festen Ansprechpartner, der die Schnittstelle Projekt - Auftraggeber bildet. Durch die regelmäßige Auslieferung von lauffähigen Produktversionen nach jedem Sprint, hat der Kunde einen besseren Einblick in den Gegenstand der Entwicklung. Dies wiederum schafft Vertrauen und eine klare Diskussionsgrundlage, um mit dem Product Owner Veränderungen in den Anforderungen zu besprechen. 1.3 XP und Kanban - Eine Bereicherung für Scrum? Wie oben beschrieben, bildet Scrum somit hinsichtlich der Prozessgestaltung, durch die darin enthaltenen Artefakte und durch das Rollenkonzept, eine tragfähige Basis für effizientes Arbeiten. Dies wird vor allem gefördert durch transparente Kommunikationswege, weitgehende Selbstbestimmung im Team und Prozessbestandteile, welche schon ihrer Grundkonstruktion nach auf Flexibilität ausgelegt sind. Dennoch ist Scrum „nur“ ein Framework, welches den Rahmen für Projektablauf und Rollenverteilung bildet. Die konkrete Ausgestaltung variiert in der Praxis sehr. Scrum bietet aber auch Raum, Elemente anderer Vorgehensmodelle und Managementgrundsätze zu integrieren. Hierbei bieten sich vor allem Werte und Prinzipien an, die ebenfalls auf das agile Manifest gründen. Gerade Extreme Programming (XP), aber auch das weniger etablierte IT-Kanban, beinhalten Ergänzungsmöglichkeiten. 1.3.1 Scrum und XP XP wird derzeit als eigenständiges Vorgehensmodell von Scrum weitgehend verdrängt. Zwar bietet es ein eigenständiges Prozess- und Rollenmodell, jedoch wird hier der Fokus eher auf konkrete Werte, Prinzipien und Techniken gelegt. Das Rollenkonzept in XP ist in der Grundstruktur dem von Scrum ähnlich. Einen wesentlichen Unterschied stellt die Rolle des Kunden dar, an den bei XP erhöhte Anforderungen gestellt werden. Es wird davon ausgegangen, dass der Kunde selbst die Anforderungen erhebt, welche „verständlich, umsetzbar und testbar sein müssen“ [5, S. 122]. Zudem sollte der Kunde immer vor Ort sein, um jederzeit für Fragen und Feedback zur Verfügung zu stehen. Diese hohen Anforderungen können im praktischen Projektbetrieb schnell zu einer Überforderung des Kunden führen. Daher muss das Rollenkonzept von Scrum hier als praktikabler gesehen werden. Im Gegensatz zum Rollenkonzept kann eine Anreicherung von Scrum um XP-Werte, Prinzipien und Techniken durchaus sinnvoll sein. Dabei geht XP vom Allgemeinen zum Speziellen. Während die Werte „Kommunikation“, „Einfachheit“, „Feedback“ und „Mut“ grundsätzliche Paradigmen darstellen, werden diese durch die XP-Prinzipien weiter präzisiert [5, S. 4 f.]. Wesentlich ist dabei, dass in XP eine ausgeprägte Feedback-Kultur etabliert wird, die Offenheit für Veränderungen und das Streben nach hoher Qualität fördert. Auch wird in XP- Projekten „Einfachheit“ angestrebt, worin hohes zeitliches Einsparpotenzial gesehen wird. Die Werte und Prinzipien werden durch zwölf XP- Techniken umgesetzt. Die bekanntesten XP-Techniken projekt MA N A G E M E N T aktuell 1/ 2013 l 35 Abb. 1: Scrum im Überblick Sprint Backlog Funktionalität für den Sprint Product Backlog Gewünschte Funktionalitäten priorisiert vom Product Owner Backlog Items Vom Team aufgeteilt Sprint 2-4 Wochen Scrum- Meeting täglich Neue Funktionalität Wird am Sprint Review Meeting präsentiert cklog Items m Team aufgeteilt Sprint 2-4 Wochen Scrum- Meeting täglich Abb. 2: Kommunikationsmodell in Scrum Manager Stakeholder Kunde Scrum Master Entwicklungsteam Product Owner = Kommunikation nach extern = Kommunikation innerhalb der Beteiligten im Scrum-Prozess Manager Stakeholder Kunde Scrum Master Product Owner kation n kation er im zess PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 35 sind kurze Release-Zyklen, Test Driven Development (TDD), Refactoring, Pair Programming, Collective Ownership, fortlaufende Integration, eine 40-Stunden- Woche und der Kunde vor Ort. Einige dieser Techniken, wie das Streben nach kurzen Release-Zyklen, regelmäßiges Testen und Kundeneinbindung sind in ähnlicher Form in Scrum bereits durch das Prozess- und Rollenmodell umgesetzt. Andere hingegen sind geeignet, Scrum inhaltlich weiter zu präzisieren. Beispielsweise empfiehlt sich für Scrum-Projekte die Einhaltung einer 40-Stunden- Woche, um Demotivation und Erschöpfung zu vermeiden. Auch die teamorientierten Aspekte der XP-Techniken, wie das Pair Programming und ein gemeinsames Verantwortungsgefühl für das Projekt, können in Scrum integriert werden. Somit steuert XP eher mit „weichen Faktoren“ Ergänzungspotenzial für den agilen Prozess Scrum bei. Hinsichtlich des Prozess- und Rollenmodells beinhaltet Scrum bereits wesentliche Elemente von XP. Hierin liegt begründet, dass Scrum XP zunehmend verdrängt und nur die Techniken von XP erhalten bleiben, auf die sich die meisten Veröffentlichungen beschränken. 1.3.2 Scrum und Kanban Neben den bekannten Vertretern XP und Scrum etabliert sich aktuell Kanban als weiteres agiles Vorgehensmodell. Dieses ist von dem „Kanban“-Konzept aus der Produktion abgeleitet, welches vor allem im Zusammenhang mit dem Toyota Production System (TPS) bekannt geworden ist [6]. Im Jahr 2007 übernahm David J. Anderson die grundlegenden Prinzipien von Kanban und passte diese für die Softwareentwicklung an [7, S. 1]. Es resultierte daraus ein evolutionäres Vorgehensmodell, welches bei der Einführung nur wenige Veränderungen an der gewohnten Arbeitsweise benötigt [6]. Dies suggeriert bereits die Möglichkeit, das Kanban-Modell als Ergänzung zu anderen Vorgehensmodellen - wie Scrum - einzusetzen. Der Einsatz von Kanban ist in zwei unterschiedlichen Arbeitsumgebungen möglich: im Tagesgeschäft (z. B. bei der Systemadministration) [8, S. 40] und in Softwareentwicklungsprojekten [6]. In Hinblick auf Effizienzsteigerung von Scrum durch ergänzende Kanban-Elemente ist vor allem die zweite Einsatzmöglichkeit interessant. Wie XP zeichnet sich auch Kanban durch die zugrunde liegenden Prinzipien aus. Dabei steht vor allem die Effizienz der Aufgabenerfüllung bei gleichzeitiger Vermeidung von Überforderung, Doppelarbeiten und Fehlern im Vordergrund. Kernstück von Kanban ist das Pull- Prinzip, das heißt die einzelnen Aufgaben dürfen den nachgelagerten Prozessschritten niemals übergeben werden, sondern diese „ziehen“ sich die Arbeiten, wenn entsprechende Kapazitäten frei werden [9, S. 13]. Um dieses „Ziehen von Aufgaben“ systematisch aufzubereiten, beinhaltet Kanban zudem eine Visualisierungstechnik über das sogenannte Kanban-Board. Dieses ist meist ein großes Whiteboard, an dem Karten kleben, auf welchen Aufgaben vermerkt sind [9, S. 13]. Im Laufe des Entwicklungsprozesses durchlaufen die Karten die Prozessschritte von links nach rechts, was den kompletten Prozess visualisiert. Aufbauend auf dem Kanban-Board wird eine Begrenzung paralleler Arbeitsschritte festgelegt - es darf sich nur eine bestimmte Anzahl von Karten in einer Spalte befinden. Je weniger Arbeiten parallel durchgeführt werden, desto kürzer wird auch die Durchlaufzeit je Aufgabe [9, S. 13 f.]. In Kanban ist auch das Streben nach kontinuierlicher Verbesserung (Kaizen) etabliert [9, S. 14]. Durch eine ständige Verbesserung des Prozesses soll eine schrittweise Annäherung an einen Zustand der Perfektion erreicht werden [10, S. 16]. Dies wird durch das Team erreicht und fußt somit auf regelmäßigen Meetings, bei denen im teaminternen Dialog Fehlerursachen identifiziert werden. Da Kanban den Fokus weniger auf Rollen- und Phasenmodelle legt, sondern sich über die oben dargestellten Prinzipien identifiziert, bietet es Potenziale in Hinblick auf Transparenz- und Effizienzsteigerungen für bestehende Prozessmodelle. 2 Agile Entwicklung im Praxiseinsatz - Potenziale und Grenzen Mit Blick auf Effizienz, Transparenz und Flexibilität werden agilen Methoden, insbesondere Scrum, zu Recht große Potenziale zugeschrieben. Jedoch ist zu prüfen, ob und wo agile Methoden gerade im Praxiseinsatz auch an Grenzen stoßen. Dies ist hauptsächlich insofern interessant, da mögliche Probleme beim alltäglichen Einsatz von Scrum durch die genauere Ausgestaltung mittels Techniken, Prinzipien und Werten anderer Methoden vermieden oder zumindest gemildert werden könnten. Somit gilt es zu analysieren, welche Erfahrungen Unternehmen im Praxiseinsatz mit agilen Methoden gemacht haben - sowohl hinsichtlich positiver als auch negativer Aspekte. Die Basis dieser Analyse stellt die Auswertung einer Befragung verschiedener Experten aus international agierenden mittelständischen und Großunternehmen der Softwarebranche dar. Um fundierte Aussagen zu erhalten, wurden nur Experten befragt, die sich durch umfangreiche Projekterfahrung mit agilen Methoden auszeichnen. Der Fokus in der praktischen Projektarbeit lag überwiegend auf Scrum, wobei auch Elemente aus XP und Kanban eingesetzt wurden. Für die Durchführung der Interviews im Februar 2012 wurde ein Fragebogen entwickelt. Dieser wurde hin- 22 l projekt MA N A G E M E N T aktuell 1/ 2013 36 WISSEN Abb. 3: Potenzial-Risiko-Matrix Potenzial Risiko Mitarbeiterzufriedenheit Mitarbeiterzufriedenheit Transparenz Transparenz Arbeitseffizienz Arbeitseffizienz Kundenzufriedenheit Kundenzufriedenheit Produktqualität Produktqualität Schulungsbedarf Schulungsbedarf Einsatz in Großprojekten Einsatz in Großprojekten Fehlende Designphase Fehlende Designphase Festpreisverträge Festpreisverträge Verteile Teams, Teilzeit Verteile Teams, Teilzeit PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 36 sichtlich halboffener Interviews konzipiert, um die Interviewpartner möglichst wenig in ihren Antworten einzuschränken und damit hochgradig aussagekräftige Ergebnisse zu erhalten. Im Zuge der Experteninterviews stellten sich einige Aspekte der Softwareentwicklung mit agilen Methoden als besonders positiv heraus. Andere wurden mehrmals als „nicht in der Praxis durchführbar“ bezeichnet. Einige Faktoren bergen zwar große Potenziale, jedoch auch Risiken. Einen Überblick über die identifizierten Potenziale und die damit verbundenen Risiken gibt die Matrixdarstellung in Abbildung 3. Die einzelnen Punkte werden im Folgenden erläutert. 2.1 Potenziale im Praxiseinsatz realisieren Nach einer auswertenden Analyse der Befragungsergebnisse konnten folgende Potenziale bei der Anwendung agiler Methoden identifiziert werden: Als größtes Potenzial der agilen Softwareentwicklung ist die dadurch entstehende Transparenz zu werten. Hinsichtlich des Prozesses wird die Entwicklung auslieferungsfähiger Produkte in jeder Iteration sehr positiv gewertet, da dadurch bereits im Projektverlauf konkret messbare Ergebnisse vorliegen. Eine reine Fortschreibung des Projektes ohne greifbare Grundlage entfällt somit, was die Projektplanung und Steuerung erleichtert. Hinsichtlich der Kommunikation werden vor allem die Feedback-Runden positiv gewertet. Zwar finden sich Berichte, dass in der Praxis Retrospektiven nicht immer stattfinden [11, S. 67], jedoch wurden mit der Sprint- Retrospektive in der Praxis positive Erfahrungen gemacht. Dieses systematische „Zurückblicken“ auf das Vorgehen führte dazu, dass sowohl eine kontinuierliche Verbesserung als auch eine hohe intrinsische Motivation erreicht wurden. In der Literatur herrscht weitgehender Konsens darüber, dass durch die Anwendung agiler Methoden eine höhere Arbeitseffizienz erreicht wird. Dies ist darauf zurückzuführen, dass weniger Zeit in reine Planungsaktivitäten investiert wird und der Fokus auf die Durchführung von Anforderungen gelegt wird. Bei Scrum lautet eine Hilfsregel, dass Sprint-Planung, Demo und Retrospektive maximal 10 Prozent der gesamten Zeit in Anspruch nehmen sollen [3, S. 86]. Auch bei Kanban wird gefordert, dass so wenig Zeit wie möglich auf das Planen verwendet werden soll, da dies keine wertschöpfende Tätigkeit ist [12, S. 222-224]. Die befragten Experten stimmten weitgehend darin überein, dass die Arbeitseffizienz durch den Einsatz agiler Methoden in den Projekten gestiegen ist. Dadurch wird bestätigt, dass Detailplanung zu Beginn eines Projektes die Effizienz hemmt. Jedoch ist darauf zu achten, dass Projektteams in agilen Methoden strenge Timeboxes (Zeitbeschränkungen) für die Planungen einhalten. Im Praxiseinsatz ist die gestiegene Effizienz nicht allein auf weniger Planungsaktivität zurückzuführen, sondern auch auf eine Reduktion der Komplexität. Diese wird durch die erhöhte Transparenz der umzusetzenden Anforderungen und der Kommunikationswege erzielt. Als kritisch hinsichtlich der Arbeitseffizienz muss das Pull- Prinzip gesehen werden. Zwar ist dieses Prinzip theoretisch äußerst wertvoll, um einen effizienten Projektablauf sicherzustellen. Jedoch setzt dieses Prinzip auch voraus, dass alle Entwickler alle Anforderungen verstehen - was naturgemäß mit einem höheren Zeitbedarf einhergeht. Hinsichtlich der Zufriedenheit der Projektbeteiligten wurde sowohl die Kundenzufriedenheit als auch die Mitarbeiterzufriedenheit untersucht: Generell steigt die Kundenzufriedenheit bei Anwendung agiler Vorgehensmodelle. Dies gründet auf der Tatsache, dass der Kunde auch während der Entwicklung Änderungswünsche einbringen und somit veränderten Unternehmens- oder Marktanforderungen Rechnung tragen kann [13, S. 23]. Auch wird vermutet, dass die Kundenzufriedenheit durch die größere Transparenz des Projektfortschritts steigt [13, S. 23].Vor allem der zweite Punkt konnte in den Interviews als großes Potenzial bestätigt werden. Durch die frühe Auslieferung von fertigen Teilprodukten wird dem Kunden ermöglicht, bereits frühe Versionen der Software nutzbringend einzusetzen. In der Literatur wird eine gestiegene Mitarbeiterzufriedenheit als großer Vorteil der agilen Softwareentwicklung gesehen. Im Allgemeinen ist das Team motivierter, wenn es mehr Verantwortung übernehmen kann. Durch das Pull-Prinzip wird das Management zudem entlastet, da das Team viele organisatorische Aufgaben selbst übernimmt [14, S. 55]. Dieses Potenzial hat sich auch in der Praxisbefragung weitgehend bestätigt. Die meisten Entwickler freuen sich, wenn sie agile Methoden und Techniken anwenden können. Durch die gestiegene Verantwortung bringen sich die Mitarbeiter vermehrt ein und werden somit produktiver. Auch positive Auswirkungen auf die Code-Qualität lassen sich darauf zurückführen. Die ebenfalls in der Literatur beschriebene Verbesserung der Produktqualität wurde im Praxiseinsatz als zum Teil risikobehaftet gesehen. Vor allem die kontinuierliche Auslieferung fertiger Software - welche auch gründliche Tests voraussetzt - hat einen positiven Einfluss auf die Produktqualität. Auch können Missverständnisse durch das regelmäßige Kunden-Feedback frühzeitig erkannt werden. Zudem wurde eine Erhöhung der intrinsi- Projektmanagement-Fachmann GPM® Qualifizierungslehrgang IPMA Level D Die State-of-the-Art-Qualifikation von PM-Profis für PM-Profis aus allen Branchen. Classic Seminar 11 Tage Frankfurt/ Main und Mainz, Start 07.09.2013 Karlsruhe und Ludwigshafen, Start 14.09.2013 Boot Camp D - Kompakt Seminar Mannheim, Start 08.05.2013 Berater, Coaches und Trainer für Projektmanagement Senior Projektmanager GPM® Aufbaulehrgang IPMA Level C/ B Prüfungsvorbereitendes Seminar für praktizierende Projektmanager. Aufbaulehrgang 5 Tage Mannheim, Start 06.05.2013 Projektmanagement mit Microsoft Project Professional - Silver Level Mehr als solide Grundlagen für künftige Profis. Seminar 2 Tage Mannheim 25./ 26.02.2013 15./ 16.04.2013 13./ 14.05.2013 Praxisorientiert für fortgeschrittene Anwender. Seminar 2 Tage Mannheim 28.02./ 01.03.2013 18./ 19.04.2013 16./ 17.05.2013 projektpartner management gmbh fon: 0621 - 17 89 06 - 0 fax: 0621 - 17 89 06 - 18 mail: office@projektpartner.de web: www.projektpartner.de Auch als Kombi-Lehrgang IPMA D+C/ B buchbar! Mannheim, Start 09.09.2013 Projektmanagement mit Microsoft Project Professional - Gold Level l Anzeige PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 37 schen Motivation im Projektteam beobachtet, was zu dem Wunsch führt, eine qualitativ hochwertige Software auszuliefern. Auch der vermehrte Einsatz automatisierter Tests und die verbesserte Wissensbasis im Team wurden als Gründe für gesteigerte Produktqualität angegeben. Jedoch lassen sich diese Punkte nur realisieren, wenn auch bestehende Risiken im Auge behalten werden. Hierbei wurde vor allem die eher kurzfristige Orientierung des Projektteams angesprochen. Es besteht die Gefahr, dass der Fokus zu sehr auf den einzelnen Sprints und deren Zielen liegt und damit das Gesamtprojekt aus den Augen verloren wird. Dadurch wird sowohl die Weiterentwicklung als auch die Wartung des implementierten Codes schwieriger. 2.2 Risiken im Auge behalten Wie agile Methoden durch ihre Prozess- und Rollengestaltung oben erläuterte Potenziale eröffnen, bergen sie auch Risiken und Probleme bei der praktischen Durchsetzung. Diese sind sowohl im Bereich Teambuilding und Kundenmanagement als auch im Prozess selbst verankert. Hinsichtlich der Teamorganisation stellen laut Expertenaussagen sowohl örtlich verteilte Teams als auch Teilzeitmitarbeiter ein großes Problem dar. Der Hauptgrund hierfür liegt in der erschwerten Kommunikation. Gerade diese ist aber ganz essenzieller Bestandteil agiler Modelle. Verbreitete XP-Techniken, wie bspw. das Pair Programming, erfordern den direkten Kontakt im Projektteam. Dieser ist durch Telefon, E-Mail und Videokonferenzen nicht zu ersetzen. Neben verteilten Teams ist auch der Einsatz von Teilzeitmitarbeitern problematisch. In agilen Projekten wird die Software gemeinsam entwickelt. Daher ist eine kontinuierliche Kommunikation und Koordination zwischen den Mitarbeitern notwendig, um immer auf dem aktuellen Stand zu bleiben. Wenn Mitarbeiter lediglich in Teilzeit am Projekt beteiligt sind, kann dies zu großen Reibungsverlusten führen. Aktuellen Tendenzen hinsichtlich einer Flexibilisierung der Arbeitszeitgestaltung stehen sie jedoch eher entgegen. Während der Einsatz agiler Methoden für die interne Entwicklung weitgehend unproblematisch gesehen wird, birgt er für externe Kundenprojekte Gefahren. Es steht und fällt der Einsatz agiler Methoden mit der Bereitschaft des Kunden, sich darauf einzulassen. Die Anforderung von XP, dass der Kunde ständig im Projekt vor Ort sein soll, wurde von unseren Interviewpartnern als „Illusion“ bezeichnet. Standardmäßig geht der Kunde davon aus, dass er lediglich bei Fragen kontaktiert wird. Besser funktioniert in der Praxis das in Scrum etablierte Konzept mit einem Product Owner als Kommunikationsschnittstelle. Die dadurch vereinfachte und erhöhte Kommunikation wurde als gut umsetzbares und großes Potenzial gesehen. Überraschendes Ergebnis der Befragung war, dass bei agilen Projekten überwiegend Festpreisverträge eingesetzt werden. Dies ist insofern problematisch, da dadurch eine ausgiebige Anforderungserfassung mit Budgetplanung zu Beginn des Projektes stattfinden muss. Diese Schätzungen werden im Projektverlauf oftmals revidiert, wobei es häufig zu großen Abweichungen kommt. Diese offenbar in der Praxis weit verbreitete Vorgehensweise läuft aber dem Grundkonzept agiler Methoden hinsichtlich größtmöglicher Flexibilität entgegen. Hier ist eine weitere Sensibilisierung der Kunden für das agile Konzept notwendig. Sowohl der Entwicklungsprozess als solcher wie auch dessen Einführung werfen zum Teil Probleme auf: So ist zu Beginn jeder neuen Entwicklungsmethode ein erhöhter Schulungsbedarf der Mitarbeiter gegeben. Dabei wurde berichtet, dass ein Anstieg der Produktqualität nur durch ausreichende Schulung erreicht werden kann. Werden agile Praktiken ohne vorherige Ausbildungsphase eingesetzt, besteht die Gefahr von Qualitätsverlusten. Auch muss zusätzlich zu den durchgeführten Schulungen vor Projektbeginn in der Anfangsphase immer wieder auf die Einhaltung agiler Werte, Prinzipien und Techniken hingewiesen werden, bis diese sich im Projektalltag manifestiert haben. Derartige Schulungsmaßnahmen verursachen zum Teil erhebliche Kosten und sind somit langfristige Investitionsentscheidungen. Die in der Literatur häufig skeptische Meinung zum Einsatz von agilen Methoden in größeren Projekten konnte in unseren Interviews jedoch nicht bestätigt werden. Überwiegend wird Scrum auch in großen Projekten mit Erfolg eingesetzt. Um weiterhin die Vorteile der Selbstorganisation der Teams zu realisieren, werden große Projekte in kleine Teams von fünf bis neun Entwicklern unterteilt. Zur Synchronisation werden zusätzliche Meetings durchgeführt. Ein prozessimmanentes Problem stellt die fehlende Designphase dar. Dadurch könnte eine unstrukturierte Architektur entstehen. Da dies der praktischen Erfahrung nach Nachteile mit sich bringt, wird im Praxiseinsatz meist ein grober Architekturplan erstellt. Unter den befragten Experten konnte der Konsens herausgearbeitet werden, dass zwar keine detaillierte Designphase stattfinden muss, ein grobes Architekturgerüst jedoch unbedingt notwendig ist. Ohne dieses müsste bereits nach nur wenigen Iterationen das Refaktorisieren kontinuierlich durchgeführt werden, was den Projektfortschritt hemmt. Weitere Elemente des Prozesses, wie beispielsweise die Abgeschiedenheit während der Iterationen, das Daily Scrum und das strenge Timeboxing, wurden überwiegend als sehr positiv bewertet. Gerade die Abgeschiedenheit der Sprints wird als großes Potenzial gesehen, da es die Überforderung mit anderen Aufgaben verhindert und ein klarer Fokus geschaffen wird. Dies führt zu einer gestiegenen Produktivität des Einzelnen. Die Forderung, dass ein Mitarbeiter in nur einem Projekt eingesetzt wird, ist jedoch in der Praxis schwer umsetzbar. Auch das strikte Verbot, Anforderungsänderungen während eines Sprints zuzulassen, ist schwierig. Hier ist eine weitere Sensibilisierung des Kunden für den Prozess notwendig. Auch das Daily Meeting wird durchwegs als sehr positiv gewertet. Eine Synchronisation im Team wird dadurch sehr effektiv erreicht. Da ungeschulte Teams jedoch häufig sehr lange für das Durchführen der täglichen Meetings brauchen, kann dies zu Ineffizienzen führen. Daher ist auf die strenge Einhaltung der Zeitlimits - das Timeboxing - zu achten. Pünktlichkeit und Zuverlässigkeit sind dabei unbedingte Voraussetzung. Grundsätzlich ist die Einführung und Durchführung agiler Vorgehensweisen in der Praxis gerade durch fehlende Managementunterstützung häufig gefährdet. Weder wird in agilen Projekten eine detaillierte Planung zu Beginn des Projektes durchgeführt, noch werden täg- 22 l projekt MA N A G E M E N T aktuell 1/ 2013 38 WISSEN PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 38 liche Reports für das Management erstellt. Auch zielt die Forderung nach weitgehender Selbstorganisation der Teams auf einen Verlust von Einfluss durch das Management. Die befragten Experten sehen den Hauptgrund für mangelnde Akzeptanz agiler Modelle durch das Management darin, dass nicht genau verstanden wird, was sich hinter dem Begriff „Agilität“ verbirgt. Allerdings bessert sich dieser Faktor seit den letzten Jahren, nachdem Scrum, XP und Kanban formalisiert dargestellt wurden und einen größeren Bekanntheitsgrad erreichten. 3 Potenziale besser nutzen: Ein Kombinationsmodell Während in der Praxis der Schwerpunkt bei der Anwendung agiler Methoden derzeit eindeutig auf Scrum liegt, kann eine Kombination der Verfahren dazu beitragen, Potenziale noch besser zu nutzen. Dies liegt darin begründet, dass die drei betrachteten Vorgehensmodelle ihren Schwerpunkt auf verschiedene Bereiche legen. Scrum ist ein Framework, bei dem das Projektmanagement und der Prozessverlauf im Vordergrund stehen. Hingegen liegt bei XP der Fokus auf speziellen Techniken für die Softwareentwicklung. Kanban zielt darauf ab, durch die Einführung bestimmter Prinzipien und Visualisierungstechniken bestehende Prozesse zu verbessern. Beispiele hierfür sind die Limitierung der aktuell bearbeiteten Arbeitspakete und das Kanban Board. Eine zielführende Integration von Kanban-Prinzipien und XP-Techniken in den klassischen Scrum-Prozess ist in Abbildung 4 dargestellt und wird im Folgenden weiter erläutert. Das Pull-Prinzip aus Kanban ist auch in Scrum integriert. Auch das Streben nach kontinuierlicher Verbesserung - das Kaizen in Kanban - ist in ähnlicher Form in Scrum beinhaltet. Darüber hinaus wurden Kanban- Techniken von den von uns befragten Experten nur verprojekt MA N A G E M E N T aktuell 1/ 2013 l 39 Abb. 4: Das Kombinationsmodell Scrum eXtreme Programming Kanban Product Backlog Sprint Backlog Daily Meeting (timeboxed) Iteration (Prozess wird am Kanban-Board visualisiert ) Ende einer Iteration • Neue Funktionalität • Review • Kaizen (= Retrospektive) • Integration • Pull-Prinzip • WIP-Limits • Pair Programming • Testen (TDD) • 40-Stunde-Woche • Collective Ownership • kontinuierliche Integration • Abgeschiedenheit der - Iteration = 1. Spalte im Kanban-Board Anzeige www.rillsoft.de Download 30-Tage-Vollversion Rillsoft GmbH • Mollenbachstrasse 14 • 71229 Leonberg Tel.: 07152-395745 • Fax: 07152-395744 • E-Mail: info@rillsoft.de Projektmanagement Software - Terminplanung - Ressourcenmanagement - Kapazitätsplanung - Personaleinsatzplanung - Projektportfolio - Integrierter Report-Generator - Terminplanung - Ressourcenmanagement - Kapazitätsplanung - Personaleinsatzplanung - Projektportfolio - Integrierter Report-Generator PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 39 einzelt explizit angewendet. Hier ist somit hinsichtlich der Effizienzsteigerung durch Visualisierungstechniken noch Potenzial zu sehen. Wesentlich verbreiteter ist die Anwendung bestimmter XP-Techniken zur näheren Ausgestaltung von Scrum- Projekten. Dabei wurden vor allem für den Einsatz von Pair Programming, Collective Ownership und TDD Potenziale und Grenzen diskutiert. Generell wurde festgestellt, dass das komplette Team davon profitiert, dass Richtlinien für die Programmierung eingeführt werden. Pair Programming wird dabei besonders erfolgreich für den Wissenstransfer und das „voneinander Lernen“ verwendet. Nach einer gewissen Einarbeitungszeit wurde oftmals sowohl eine Steigerung der Produktqualität als auch der Entwicklungsgeschwindigkeit beobachtet. Auch ein Anstieg der Mitarbeiterzufriedenheit war zu erkennen, da das „zu zweit Programmieren“ den meisten Mitarbeitern mehr Freude bereitet. Zusammenfassend lässt sich sagen, dass diese Technik besonders bei komplexen, fehleranfälligen Aufgabenstellungen Vorteile bringt; bei einfachen Routineaufgaben hingegen stellt sich das Pair Programming eher als problematisch dar. Die XP-Technik „Collective Ownership“ bedeutet, dass es keine Codeteile mehr gibt, die einzelnen Programmierern gehören. Der komplette Code wird vom gesamten Team bearbeitet. Dies zielt darauf ab, dass die Abhängigkeit von einzelnen Mitarbeitern reduziert und Engpässe vermieden werden. Beispielsweise könnten in einem Krankheitsfall andere Teammitglieder am Code weiterarbeiten [11, S. 85 f.]. Dieses in der Literatur beschriebene Potenzial konnte in der Befragung nicht bestätigt werden. Es herrschte weitgehende Übereinstimmung, dass Collective Ownership in der Praxis nicht oder nur schwer durchführbar sei, da die Aufgaben viel zu komplex und spezifisch seien. Es handelt sich hierbei somit um ein theoretisches Potenzial. „Test Driven Development“ (TDD) heißt, dass ein automatisierter Test geschrieben wird, bevor der Code dazu implementiert wird. Dieser durchläuft anschließend den zuvor entworfenen Test. In der Praxis liegt dabei der Fokus dieses Begriffes ganz klar auf dem vermehrten Einsatz automatisierter Tests. Dies wird sehr erfolgreich eingesetzt. Der Befragung zufolge konnte dadurch die Produktqualität erheblich gesteigert werden. 4 Fazit In einer Gesamtbetrachtung lässt sich erkennen, dass der Einsatz agiler Vorgehensmodelle große Potenziale birgt. Diese erstrecken sich vor allem auf Transparenz, Effizienz, Produktqualität und Zufriedenheit sowohl bei Kunden als auch bei Mitarbeitern. Um diese realisieren zu können, ist jedoch ein Reifeprozess mit zielgerichteten Schulungen zu durchlaufen und eine kontinuierliche Sensibilisierung für agile Prinzipien unumgänglich. Nicht nur der Prozess als solches, sondern vor allem auch die Durchsetzung agiler Praktiken - beispielsweise die Abgeschiedenheit der Iterationen und regelmäßige Retrospektiven - bilden die Grundlage für die Realisierung der Potenziale. Um diese voll ausschöpfen zu können, ist zudem eine Kombination der Methoden zu empfehlen. Da derzeit eindeutig Scrum eine Vorreiterrolle einnimmt, sollten vielversprechende Techniken aus XP und Kanban in Scrum integriert werden. ■ Literatur [1] Schwaber, K./ Sutherland, J.: Scrum Guide - Der gültige Leitfaden für Scrum: Die Spielregeln. Veröffentlicht durch scrum.org2011 [2] Schwaber, K.: Scrum im Unternehmen. Microsoft Press Deutschland, Unterschleißheim 2008 [3] Pichler, R.: Scrum - agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008 [4] Roock, A./ Wolf, H.: Was ist Scrum. In: agile review 2010, 1, S. 13-17 [5] Lippert, M./ Rook, S./ Wolf, H.: Software entwickeln mit eXtreme Programming - Erfahrungen aus der Praxis. Bonn 2002 [6] Leopold, K.: Software-Kanban im Einsatz - Das etwas andere Kochrezept. In: Heise Developer, 2011, www. heise.de/ developer/ artikel/ Software-Kanban-im-Einsatz- 1235465.html [7] Epping, T.: Kanban für die Softwareentwicklung. Informatik im Fokus, Heidelberg 2011 [8] Roock, A.: Scrum funktioniert nicht überall, Interview mit David Anderson. In: OBJEKT-Spektrum 2010, 2, S. 38-41 [9] Roock, A./ Wolf, H.: Kanban in der Softwareentwicklung, Verbesserungsprozesse bringen echten Wettbewerbsvorteil. In: Business Technology - Architektur & Management Magazin 2010, 1, S. 12-16 [10] Sprengholz, Ph.: Lean Software Development - Kundenzentrierte Softwareentwicklung durch Anwendung schlanker Prinzipien. München 2011 [11] Kniberg, H.: Scrum and XP from the Trenches - How we do Scrum. Toronto/ Canada 2007 [12] Anderson, D. J.: Kanban - Evolutionäres Change Management für IT-Organisationen. Heidelberg 2011 [13] Elssamadisy, A.: Patterns of Agile Practice Adoption - The Technical Cluster. Toronto/ Canada 2007 [14] Neubauer, A.: Scrum-Einführung bei Immobilien- Scout24. In: Henning, W. (Hrsg.): Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen - Erfahrungsberichte aus der Praxis. Heidelberg 2012, S. 47-72 Stichwörter agil, Kanban, Projektmanagement, Scrum, Softwareentwicklung, XP Kompetenzelemente der NCB 3.0 4.1.3 Projektanforderungen und Projektziele, 4.1.7 Teamarbeit, 4.1.11 Projektphasen, Ablauf und Termine, 4.15 Änderungen, 4.1.17 Information und Dokumentation, 4.1.18 Kommunikation, 4.2.3 Selbststeuerung, 4.2.9 Effizienz Autorin Franziska Krodel M.Sc. ist derzeit in einem der größten agilen Projekte bei der BMW AG tätig. Zuvor verfasste sie ihre Masterarbeit zum Thema „Potenziale und Grenzen agiler Softwareentwicklung“, welche mit der Bestnote ausgezeichnet wurde. Während des Studiums arbeitete sie als Wissenschaftliche Hilfskraft an der Universität Passau. Anschrift Pündterplatz 7 D-80803 München E-Mail: Franziska.Krodel@web.de 22 l projekt MA N A G E M E N T aktuell 1/ 2013 40 WISSEN Jens Kö PM_1-2013_1-64: Inhalt 30.01.2013 13: 37 Uhr Seite 40