projektManagementaktuell | AUSGABE 2.2016 36 WISSEN Mit der zunehmenden Verbreitung von agilen Vorgehensweisen und deren Ausweitung auf Anwendungsfelder außerhalb der Softwareentwicklung ist auch ein wachsender Markt für Software-Werkzeuge für agiles Projektmanagement entstanden [1]. Die Nachfrage nach solchen Produkten steht zwar in gewissem Widerspruch zu den Idealvorstellungen des Agilen Manifests („Individuals and interactions over processes and tools.“ [2]), erklärt sich aber durch die Größe und geografische Verteilung vieler Projektteams in realen Projekten (vgl. [3, 4]). Neben der Vielzahl von angebotenen Produkten wird die Auswahl dadurch erschwert, dass sich bis heute kein einheitliches Verständnis von agilem Projektmanagement herausgebildet hat bzw. in der Unternehmenspraxis häufig Anpassungen der theoretischen Konzepte vorgenommen werden, um die neuartigen Ansätze mit der historisch gewachsenen Projektkultur vereinbaren zu können. Zudem sind hergebrachte Modelle, Verfahren und Kriterienkataloge für die Evaluation von Projektmanagement-Software nur teilweise hilfreich, da sie Anforderungen zur Unterstützung eines agilen Projektmanagements in der Regel nicht berücksichtigen (bspw. [5, 6, 7]). Der vorliegende Artikel will zum Schließen dieser Lücke beitragen, indem er spezifische Evaluationskriterien für die Auswahl von Software-Werkzeugen für agiles Projektmanagement entwickelt und deren Anwendung exemplarisch an den Produkten JIRA Agile, Projektron BCS und OpenProject demonstriert. Dazu wird zunächst kritisch beleuchtet, welche Evaluationsansätze und Auswahlhilfen für Projektmanagement-Software aktuell zur Verfügung stehen. Anschließend werden auf Basis einer Literaturrecherche wesentliche Merkmale von agilem Projektmanagement identifiziert, mit deren Hilfe ein Bezugsrahmen zur Ableitung spezifischer Evaluationskriterien konstruiert wird. Den Hauptteil bilden die Darstellung der Evaluationsmethodik, der abgeleiteten Evaluationskriterien und deren exemplarische Anwendung auf die genannten Softwareprodukte. Der Beitrag endet mit einem Fazit und Ausblick. 1 Softwareevaluierung für die Domäne Projektmanagement Softwaresysteme für Projektmanagement sind bereits vergleichsweise früh entstanden und wurden infolge des Siegeszugs des Personal Computers immer besser verfügbar. Kerzner [8] beschreibt eine einfache Klassifikation von PM- Software, die auf einen Artikel im US-amerikanischen PC Magazine von 1984 zurückgeht [9]. Die bessere Verfügbarkeit steht dabei in enger Beziehung mit einer zunehmenden Anzahl an Standardsoftware-Produkten sowie einer auch von anderer Standardsoftware (bspw. Produkte der Microsoft Office-Familie) bekannten fortwährenden Erweiterung des Funktionsumfangs mit jeder neuen Version. Durch diese Entwicklung stehen heute umfassende Softwarelösungen zur Verfügung, die den Anspruch haben, das Management des gesamten Projektlebenszyklus und darüber hinaus auch Programm- und Portfoliomanagement zu unterstützen [5]. Durch die anhaltende Vergrößerung des Angebots ergibt sich jedoch für den interessierten Anwender neben der verbesserten Wahlmöglichkeit auch ein immer schwierigeres Auswahlproblem bei dem Versuch, die zu den eigenen Anforderungen am besten passende Software zu finden. Diesem Problem begegnen wiederum diverse Auswahlinstrumente, die von einfachen Produktlisten bis zu wissenschaftlich fundierten Evaluationsstudien reichen. Tabelle 1 vermittelt einen Eindruck von Umfang und Informationsgehalt einiger Auswahlinstrumente, indem die Anzahl der jeweils untersuchten Softwareprodukte und der herangezogenen Vergleichskriterien aufgelistet werden. PM-Software Evaluation von Software-Werkzeugen für agiles Projektmanagement Autoren: Erzsébet Tolnai, Gunnar Auth >> Für eilige Leser Die zunehmende Verbreitung von agilen Vorgehensweisen und deren Ausweitung auf Anwendungsfelder außerhalb der Softwareentwicklung hat auch zu einer wachsenden Nachfrage nach Software-Werkzeugen für agiles Projektmanagement geführt. Zur Unterstützung der Auswahl aus dem immer größer werdenden Produktangebot beschreibt der Beitrag spezifische Evaluationskriterien, die aus einem eigens konstruierten Bezugsrahmen abgeleitet werden. Die Anwendung der Evaluationskriterien wird exemplarisch an drei Softwareprodukten demonstriert. PM-aktuell_2-2016_Inhalt_01-72.indd 36 04.04.2016 5: 17: 37 Uhr WISSEN 37 projektManagementaktuell | AUSGABE 2.2016 wicklung begonnen. So beteiligten sich mit Cockburn und Highsmith zwei Verfasser des Agilen Manifests 2005 auch an der Ausarbeitung der sogenannten Declaration of Interdependence (DOI) [16], die ursprünglich auf eine Weiterentwicklung des Agilen Manifest für Nicht-Software- Projekte zielte, im Ergebnis aber so allgemein formuliert ist, dass ein spezifischer Bezug auf Projekte kaum noch vorhanden bzw. die DOI auch für allgemeine Managementaufgaben nutzbar ist. Im selben Zeitraum konnte sich der Begriff des agilen Projektmanagements basierend auf einer Reihe von Monografien und anderen Publikationen mit entsprechenden Titeln (bspw. [17, 18, 19]) weiter etablieren, wobei jeder Autor sein eigenes Verständnis von agilem Projektmanagement entwickelte. Trotz der Unterschiede im Detail lassen sich gemeinsame Wesensmerkmale feststellen, die sich sowohl in den verfolgten Zielen als auch in den aus dem Agilen Manifest entlehnten Prinzipen kristallisieren. Zusammengefasst lassen sich die folgenden Ziele formulieren: 1) Kundenzufriedenheit durch Projektergebnisse, die einen Wert aus Sicht des Kunden darstellen; 2) höhere Produktivität durch geringeren bürokratischen Aufwand und weniger, dafür einfache Regeln; 3) Minimierung von Projektrisiken durch iteratives Vorgehen, das einen kontinuierlichen Verbesserungsprozess unter Beteiligung des Kunden integriert und mit ständigem Lernen einhergeht. samer Mangel feststellbar: die fehlende Berücksichtigung von spezifischen Anforderungen an eine Projektmanagement-Software für die Unterstützung einer agilen Projektdurchführung. 2 Spezifische Anforderungen an Software-Werkzeuge für agiles Projektmanagement Die Entstehung des agilen Projektmanagements ist eng verknüpft mit den Konzepten der agilen Softwareentwicklung, deren grundlegende Werte und Prinzipien 2001 im sogenannten Agilen Manifest veröffentlicht wurden [2]. In das Agile Manifest gingen wiederum eine Reihe von Entwicklungen und Einflüssen ein, die bereits seit Längerem bekannt waren (vgl. [14]). Neben den evolutionären Vorgehensmodellen zur Softwareentwicklung (bspw. Barry Böhms Spiralmodell) waren dies unter anderem das neuartige Vorgehen zur Produktentwicklung, das Takeuchi und Nonaka [15] bereits Mitte der 1980er-Jahre beschrieben hatten (und dafür den Vergleich zur Scrum-Technik im Rugby nutzten), sowie Elemente der japanischen Kaizen- und Total Quality- Philosophie, aus denen sich später der Lean Management-Ansatz (in der deutschen Industrie vor allem als sogenannter kontinuierlicher Verbesserungsprozess, KVP, verbreitet) entwickelte. Während sich das Agile Manifest noch ausdrücklich auf die Domäne Softwareentwicklung bezogen hatte bzw. heute noch bezieht, wurde sehr bald auch mit einer Übertragung und Erweiterung des agilen Vorgehens auf das allgemeine Projektmanagement mit Fokus auf Produktent- Auf die Berücksichtigung älterer Studien (bspw. [10]) wurde verzichtet, da diese durch neue Produktversionen, aber auch technologische Entwicklungen (bspw. Software as a Service) durchweg veraltet sind. Die Problematik der schnell verfallenden Aktualität hat Schelle bereits 2003 in seiner Kritik an den seinerzeit vorhandenen Studien benannt [11]. Auch die weiteren von ihm benannten Kritikpunkte wie fehlende oder schwer nachvollziehbare Kategorisierung, unvollständige Abdeckung des Projektlebenszyklus, zu umfangreiche Kriterienkataloge, die eine Entscheidung eher erschweren als erleichtern, zu wenig Praxisbezug und zu wenig Differenzierung nach verschiedenen Zielgruppen sind heute weitgehend noch gültig. Einzig die 2003 erstmalig von Ahlemann und 2014 zusammen mit Mey Mark Meyer in 8. Auflage [6] veröffentlichte Studie auf Basis des von Ahlemann entwickelten M-Modells bescheinigt Schelle eine Berücksichtigung seiner Kritikpunkte, die zu einem deutlich höheren Nutzwert führen [11]. Einen anderen Ansatz verfolgen die amerikanischen IT-Marktforschungsunternehmen Gartner und Forrester Research, die in unregelmäßigen Abständen unter der Bezeichnung Magic Quadrant (Gartner) und Forrester Wave Studienergebnisse zu den aus ihrer Sicht führenden Anbietern und Softwareprodukten im Segment Projektportfoliomanagement veröffentlichen [12, 13]. Als Unterstützung für eine kriterienbasierte Evaluation sind diese Darstellungen jedoch nur von begrenztem Nutzen. Neben dieser grundlegenden Kritik ist bei allen betrachteten Auswahlinstrumenten ein gemein- Auswahlinstrument Anbieter Anzahl Produkte Anzahl Vergleichskriterien Zuletzt aktualisiert Verzeichnis Online-Fachportal ProjektMagazin 73 -* k. A. Vergleichstabelle Fachzeitschrift IT&Production 82 34 k. A. Vergleichstabelle Online-Portal projektmanagement-loesungen.de 74 64 k. A. Webbasierte Kriterienabfrage pm-toolfinder.de (Le Bihan Consulting) 58 > 300 Themenfragen k. A. Vergleichstabelle Wikipedia 165 16 22.5.2015 Marktstudie von Meyer/ Ahlemann [6] Business Application Research Center 27 > 250 2014 (8. Aufl.) Tab. 1: Auswahlhilfen für Projektmanagement-Software * nur Auflistung ohne Vergleich PM-aktuell_2-2016_Inhalt_01-72.indd 37 04.04.2016 5: 17: 37 Uhr projektManagementaktuell | AUSGABE 2.2016 38 WISSEN 7) Durchführen der Messungen, 8) Auswerten der Messdaten. 3.1 Evaluationsmethodik Für den vorliegenden Beitrag sind die Evaluationsobjekte Software-Werkzeuge für agiles Projektmanagement. Das Evaluationsziel ist die Auswahl desjenigen Werkzeugs, das aus Sicht der Projektbeteiligten (insbes. Managementrollen wie Projektleiter oder Product Owner, aber auch übrige Mitglieder des Projektteams) den höchsten Nutzen für das Management agiler Projekte erbringt. Die Kriterien sind Eigenschaften des Evaluationsobjektes, auf deren Erfüllung das Erreichen des Evaluationsziels zurückgeführt werden kann. Eine Gewichtung von Kriterien ist erforderlich, damit der Messwert mit unterschiedlichem Gewicht in Betracht gezogen werden kann. Dadurch lassen sich unterschiedliche Präferenzen berücksichtigen, wie sie beispielsweise durch das individuelle Verständnis von agilem Projektmanagement in einem konkreten Unternehmen vorliegen. In diesem Beitrag wird keine Gewichtung durchgeführt. Diese ließe sich jedoch bei der praktischen Anwendung der Kriterien in einem bestimmten Kontext problemlos vornehmen. Mittels Messmethoden werden Daten über die Evaluationsobjekte direkt oder indirekt erfasst. kommen, weshalb sie auch als leichtgewichtig bezeichnet werden. Zu den bekanntesten Vertretern (vgl. [14]) zählen Scrum, Kanban, die Crystal-Familie und Dynamic Systems Development Method (DSDM), die ihren Ursprung wiederum durchweg in der Softwareentwicklung haben. Die einzelnen Elemente des Bezugsrahmens orientieren sich aufgrund des hohen Verbreitungsgrades an Scrum, stellen aber eine Verallgemeinerung dar. Der Begriff Informationsträger geht auf Cockburn [20] zurück und wird als Überbegriff von Darstellungsformen für Projektinformationen verwendet, die inhaltlich aktuell und für alle Projektmitarbeiter gut sichtbar sind und somit für Transparenz im Projekt sorgen. 3 Evaluationsmethodik und -kriterien Das Vorgehen bei der Evaluation beruht auf [21]. Demnach soll eine Evaluation methodisch, nach bestimmten Regeln aufgebaut und nachvollziehbar sein. Ein allgemeiner Arbeitsplan besteht je nach Problemsituation aus bis zu acht Schritten: 1) Festlegen der Evaluationsobjekte, 2) Formulieren des Evaluationsziels, 3) Ableiten der Evaluationskriterien, 4) Gewichten der Evaluationskriterien, 5) Abbilden der Evaluationskriterien in Metriken, 6) Auswählen von Messmethoden, Eher im Hintergrund stehen Ziele bezüglich Termin- und Budgeteinhaltung, die zusammen mit dem Projektumfang (Scope) bzw. den Qualitätszielen das sogenannte magische Dreieck des klassischen Projektmanagements bilden. Diese Ziele werden durch die Anwendung von sogenannten agilen Prinzipien verfolgt, auf denen die Durchführung von agilen Projekten beruht. Das Agile Manifest wurde von seinen Autoren um zwölf Prinzipien ergänzt, deren Fokus wiederum auf der Softwareentwicklung liegt. Diese lassen sich wie folgt zusammenfassen und unter Nutzung der ausgewerteten Literatur verallgemeinern: • Geringe Planungsintensität, das heißt Verzicht auf Pläne bzw. Reduzierung von Plänen, die mit hohem Detailgrad die Aufgaben für den gesamten Projektzeitraum definieren, sowie Anforderungsspezifikationen, die vor Beginn der Entwicklung die geforderten Eigenschaften des Produkts vollständig, korrekt und eindeutig beschreiben. • Hohe Anpassungsfähigkeit an Veränderungen während des Projekts durch kurze Iterationszyklen auf Basis des Deming-Zyklus (plan, do, inspect and adapt). • Selbstorganisierende, möglichst hierarchiefreie Teams, die als Ganzes Verantwortung für das Erreichen der Projektziele übernehmen und die kurzen Iterationszyklen nutzen, um aus Fehlern zu lernen, und kontinuierlich auf die Verbesserung der eigenen Arbeitsweise hinarbeiten. • Intensive und möglichst direkte Kommunikation mit und im Team, um den Informationsaustausch möglichst effektiv und effizient zu gestalten und so Probleme möglichst frühzeitig erkennen zu können. Aus den bisherigen Erkenntnissen über Wesen und Merkmale von agilem Projektmanagement lässt sich ein Bezugsrahmen konstruieren, der das vorhandene Wissen bzw. Begriffsverständnis expliziert und im Folgenden als Grundlage für die Ableitung von Evaluationskriterien für geeignete Software-Werkzeuge dient. Neben den bereits angesprochenen Kategorien Ziele, Prinzipien, Prozess und Projekt umfasst der in Abbildung 1 dargestellte Bezugsrahmen noch die weiteren Kategorien Regelwerke und Informationsträger. Regelwerke beschreiben Details für Vorgehen in und Management von agilen Projekten, denen als gemeinsames Merkmal ein iterativer Prozess zugrunde liegt. Diese Regelwerke wollen mit wenigen und einfach verständlichen Regeln aus- Abb. 1: Bezugsrahmen für agiles Projektmanagement PM-aktuell_2-2016_Inhalt_01-72.indd 38 04.04.2016 5: 17: 38 Uhr WISSEN 39 projektManagementaktuell | AUSGABE 2.2016 kann aber zu jeder Iteration nach gemeinsamer Abstimmung im Team neu erzeugt werden (automatisch oder manuell). Der Plan baut auf den übrigen Artefakten auf und es sollte die Möglichkeit geben, diese zusammenfassend darzustellen. Feature List: Auch Epics oder Themes genannt. Der Einsatz von Feature Lists ist bei größeren Projekten sinnvoll, um komplexe User Stories besser strukturieren zu können (vgl. [19]). Dazu werden Anforderungen aufgrund der Menge und Komplexität zu Produktfeatures gruppiert und so zum Iterationsplan hinzugefügt, um die Übersicht für Kunden und das Management zu vereinfachen. Die Fertigstellung eines Features kann mehrere Iterationen dauern. Bei kleineren Projekten kann von diesem Kriterium abgesehen werden. Agile Risk Planning: Agile Risikoplanung wird nicht auf Basis klassischer Netzpläne und Checklisten betrieben, sondern eher in den Meetings (wie bspw. Daily Stand-ups) durch Einschätzung der Teammitglieder auf aktuelle Ereignisse bezogen. Dabei kommen Techniken wie Risk Adjusted Backlog oder Risk Burndown Graph zur Verwendung (vgl. [24]) und müssten im besten Falle von einem Software-Werkzeug unterstützt werden. Product Backlog: Das Product Backlog umfasst die Gesamtheit der priorisierten User Stories bzw. Anforderungen für ein Projekt und kann auch als Arbeitsvorrat für die Iterationen verstanden werden. Im Rahmen der Iterationsplanung werden User Stories zur Implementierung ausgewählt. Dabei hat die Priorisierung durch den Kunden Vorrang. Das Backlog ist nicht abgeschlossen, es kann jederzeit aktualisiert werden. Es ist grobgranular und bietet einen Überblick über das Gesamtprojekt. Die Backlog-Einträge dürfen nicht begrenzt sein, es müssen immer zusätzliche User Stories ergänzt werden können. Iteration Backlog: Auch Sprint Backlog genannt. Entsteht durch Auswahl von User Stories aus dem Product Backlog und bildet damit eine Teilmenge von diesem. Im Iteration Backlog werden die priorisierten User Stories aus technischer Sicht detaillierter beschrieben, um als Grundlage für die Umsetzung zu dienen. Das Resultat der Iteration ist ein dem Kunden vorzeigbares, funktionierendes Inkrement. Iterationen finden so lange statt, wie das Product Backlog noch nicht implementierte User Stories bzw. Anforderungen enthält. Die User Stories müssen nach Priorisierungsreihenfolge und Abhängigkeiten untereinander Iterationen zugeordnet werden können. Darüber hinaus sollten eine Verknüpfung mit Eine geeignete Methode für die Softwareevaluation ist das Testen der zu evaluierenden Produkte auf Basis eines realen oder realitätsnahen Anwendungsszenarios (vgl. [22]). Das Testen kann durch Recherchieren von Produktinformationen des Herstellers bzw. von Dritten (bspw. Usergroups, Testberichte) ergänzt werden. Das Durchführen der Messungen liefert die Daten zur Bewertung anhand der Evaluationskriterien. Die Auswertung geschieht hinsichtlich des zu erreichenden Ziels und repräsentiert das Evaluationsendergebnis. 3.2 Evaluationskriterien Die Kriterien beschränken sich in diesem Beitrag auf die Aspekte des agilen Projektmanagements, wie sie im Bezugsrahmen dargestellt wurden. Weitere allgemeine Kriterien für die Softwareauswahl finden sich beispielsweise in [22]. Zudem sei verwiesen auf die vorhandenen Darstellungen von Kriterien für klassische Projektmanagement-Software, bspw. [5, 11, 10]. Die Bezeichnungen der Kriterien sind auf Englisch gehalten, was dem Sprachgebrauch in der Praxis entspricht. Nachfolgend sind die Kriterien aufgelistet und jeweils kurz beschrieben: User Stories: User Stories spielen eine zentrale Rolle bei der Anforderungsanalyse und -definition im agilen Projektmanagement. User Stories werden zu Projektbeginn mit dem Kunden bzw. den Anwendern erstellt. Sie werden in einzelne Tasks runtergebrochen und ggf. zu Features (Feature List) zusammengefasst. Sie sollten Personen, Features, Backlogs und Iterationen zuordenbar sein. Die Priorisierung erfolgt mithilfe von Schätzverfahren (Techniques of Estimation). Die User Stories können in jeder Iteration aktualisiert werden und müssen aus diesem Grund versionierbar sein sowie mit Kommentaren versehen werden können. Für einen Überblick über alle User Stories sollte eine Visualisierung in einer Story Map möglich sein. Whole Project Plan: Das Kriterium wird auch Release Plan genannt. Der Plan enthält die wichtigsten Projekteigenschaften, um gegenüber dem Management berichtsfähig sein zu können. Der Gesamtprojektplan stellt einen Überblick über Kosten (Cost Planning), Zeitrahmen (Scheduling), Umsetzungsreihenfolge der Anforderungen (Product Backlog), Meetings und Werkzeuge sowie Anzahl der Iterationen dar (vgl. [23]). Der Plan ist ein Big Picture über Abhängigkeiten im Projektumfeld. Der Plan wird zu Projektbeginn erstellt, Anzeige PM-aktuell_2-2016_Inhalt_01-72.indd 39 04.04.2016 5: 17: 39 Uhr projektManagementaktuell | AUSGABE 2.2016 40 WISSEN öffentlich für das Team. So kann nach agilen Regeln schneller und gemeinsam gehandelt werden. Das Reporting kann auch für die Kundenkommunikation genutzt werden. Die Zusammensetzung des Reports kann von Projekt zu Projekt verschieden sein. Der Bericht kann beispielsweise folgende Elemente enthalten: Aktueller Projektfortschritt, verbleibende Aufwände, nächste Termine, Abwesenheitsliste, Stimmungslage im Team sowie Burndown Chart. Die Software muss es ermöglichen, den Report oder das Big Picture frei konfigurieren zu können. 4 Anwendung mit ausgewählten Softwareprodukten Der Markt für agile Projektmanagement-Software ist in den letzten Jahren erheblich gewachsen. Viele klassische Anbieter entwickeln für ihre Produkte zusätzliche Funktionen bzw. Erweiterungen für agiles Projektmanagement. Es gibt aber auch zunehmend Anbieter, die sich ausschließlich mit agilen Konzepten beschäftigen [25]. Ein Überblick über die wichtigsten Scrum-Produkte findet sich in der Literatur bei [25]. Deutlich umfangreicher und vor allem aktueller sind jedoch Online-Verzeichnisse im Internet wie bspw. auf agilescout.com (http: / / agilescout.com/ best-agilescrum-tools, Stand: 23.5.2015), softwaretestingclass.com (www.softwaretestingclass.com/ 70comprehensive-agile-project-management-toolslist, Stand: 23.5.2015) oder die auf Open Source Software spezialisierte Webseite agile-tools.net (www.agiletools.net, Stand: 23.5.2015). Der Kriterienkatalog wird auf drei ausgewählte Software-Werkzeuge exemplarisch angewendet: JIRA Agile, Projektron BCS und OpenProject. Die Werkzeuge werden im Folgenden kurz vorgestellt und anschließend die Evaluationsergebnisse dargestellt. Die Evaluation beinhaltet nur die zuvor erarbeiteten agilen Kriterien. Allgemeine Kriterien zur Evaluation von Projektmanagement-Software werden nicht berücksichtigt. 4.1 Ausgewählte Softwareprodukte JIRA Agile: JIRA wurde ab 2002 ursprünglich als Werkzeug für die Fehler- und Themenverfolgung bei Softwareentwicklung und -management entwickelt und später um Projektmanagementfunktionalitäten erweitert. Laut Angaben des Herstellers Atlassian wird es von mehr als 22.000 Kunden eingesetzt (www.atlassian.com/ dms/ wac/ images/ press/ Resources/ presskits/ Summit_Pro Stand-up Meeting: Dieses Treffen ist eine (meist) tägliche, kurze persönliche oder virtuelle Besprechung zur Teamsteuerung mit Verbindung zu aktuellen Tasks. Während des Meetings werden Fortschritte, Probleme, künftige Aufgaben besprochen. Die Planung und die Durchführung des Meetings werden vom Team selbst umgesetzt. Zur Förderung von Effizienz und Effektivität findet das Meeting in einem festen Zeitrahmen (timeboxed) statt. Ein Software-Werkzeug sollte das Meeting mit einer Planungs- und Dokumentationsfunktion unterstützen, User Stories oder Tasks in die Agenda aufnehmen sowie Burndown Charts einblenden können. Iteration Review: Das Review ist eine Besprechung zur Kontrolle und Verbesserung der Ergebnisse aus der gerade abgeschlossenen Iteration. Das fertiggestellte Inkrement wird dem Kunden präsentiert und von diesem beurteilt. Das Review findet nach jeder Iteration statt, um den Fortschritt bewerten und Verbesserungen einleiten zu können. Dabei wird eine Überprüfung der aktuellen Situation und der Teamleistung, eine Kontrolle des Fortschritts gegenüber dem Whole Project Plan durchgeführt und schließlich über die Inkrementfreigabe entschieden. Das Ergebnis ist ein überarbeitetes Product Backlog. Ein Software-Werkzeug sollte das Review unterstützen, indem automatisch oder manuell ein Bericht mit den nötigen Daten wie dem Burndown Chart und die zu Iteration zugeteilten User Stories und Tasks erstellt werden. Iteration Retrospective: Ziel einer Retrospektive soll es sein, aus der zurückliegenden Iteration zu lernen und nicht wie im Review die Fortschritte zu messen und zu planen. Während eines Workshops werden die Zusammenarbeit bewertet, mögliche Schwachstellen aus der vergangenen Iteration identifiziert und Verbesserungsmaßnahmen entwickelt. Ziel ist es, zu lernen, wie zukünftig die Projektsituation verändert bzw. verbessert werden kann. Ein Software- Werkzeug sollte dem Team in der Organisation des Workshops behilflich sein können und die Untersuchung der Iteration durch speziell aufbereitete Reports ermöglichen. Zudem kann mit vorgefertigten Fragebögen oder Abfragen der Workshop unterstützt werden. Agile Status Reporting: Hierunter wird eine klar aufgeteilte, kompakte Berichtsliste über den Projektfortschritt verstanden, die jederzeit von jedem Teammitglied einsehbar ist (vgl. [24]). Im Gegensatz zum klassischen Status Reporting ist das agile Reporting stets aktuell und Tasks und eine Visualisierung auf einer Live- Timeline (Fortschrittsanzeige) möglich sein. Eine Verknüpfung zu „Techniques of Estimation“ sollte ebenfalls vorhanden sein. Definition of Done (DoD): Die DoD ist eine verbindliche Vereinbarung zur Qualität des zu erreichenden Zieles. Damit ein Inkrement oder Produkt kollektiv als „done“ bezeichnet werden kann, wird ein gemeinsames Verständnis über Kriterien entwickelt, wann ein Ergebnis vorliegt bzw. erreicht ist. Die Kriterien müssen dabei messbar und objektiv sein. Die DoD wird in der Vorbereitungsphase als Dokument erstellt, eine Änderung erfolgt nur über den Product Owner und nur nach gemeinsamer Entscheidung. Tasks: Tasks sind Aufgaben zur Umsetzung einer User Story. Tasks haben eine Dauer, die für die Arbeitsaufteilung und für das Timeboxing wichtig ist. Die Dauer muss auf einem Taskboard visualisierbar sein, um einen Überblick über den Fortschritt und Projektstatus bekommen zu können. Sie müssen außerdem versionisierbar sein und mit Kommentaren versehen werden können. Die Zuordenbarkeit zu User Stories muss gegeben sein. Tasks müssen auf einem Taskboard mit den Zuständen von mindestens „To-do“, „Work in Progress“ und „Done“ dargestellt werden können. Tasks müssen zudem jederzeit geändert und neue hinzugefügt werden können. Techniques of Estimation: Schätzverfahren dienen zur Ermittlung des Aufwands von User Stories, Tasks bzw. des Gesamtprojekts. Das Team entscheidet gemeinsam, wie viel Zeit im Projekt für einzelne Tätigkeiten gebraucht wird. Hierfür gibt es mehrere Verfahren, die die Qualität der Entscheidung auch in virtuellen Teams mithilfe von Software-Werkzeugen unterstützen wie beispielsweise Schätzpoker oder Magic Estimation (vgl. [25]). Zu einzelnen Inkrementen, User Stories, Tasks sowie zur Projektfortschrittkontrolle muss eine Verbindung hergestellt werden. Es sollte darüber hinaus darstellbar sein, welche Ergebnisse zu welchen Artefakten gehören, um später die Entscheidungen nachvollziehen zu können. Burndown Chart: Dient der Projektfortschrittskontrolle in Form eines Diagramms. Das Chart dient der Transparenz im Team, kann aber auch gut für die Kundenkommunikation genutzt werden. In der Regel wird die restliche Zeit mit dem verbleibenden Arbeitsaufwand in Echtzeit verglichen. Darüber hinaus kann beispielsweise die Auslastung des Teams oder der Gesamtaufwand visualisiert werden. PM-aktuell_2-2016_Inhalt_01-72.indd 40 04.04.2016 5: 17: 39 Uhr WISSEN 41 projektManagementaktuell | AUSGABE 2.2016 nagement-Software sowie allgemeine Kriterien für die Softwareauswahl (bspw. Ergonomie oder Wirtschaftlichkeit) zu ergänzen und die Kriterien nach individuellen Präferenzen zu gewichten. Ansatzpunkte zur Weiterentwicklung bietet schließlich auch der dargestellte Bezugsrahmen, der durch die Orientierung an Scrum unter Umständen ein zu eingeengtes Verständnis von agilem Projektmanagement expliziert. Zudem ließe sich untersuchen, welche Veränderungen sich durch die Betrachtung von Kombinationsmöglichkeiten agiler und klassischer Projektmanagementansätze ergäben, wie sie seit einiger Zeit unter dem Stichwort hybrides Projektmanagement diskutiert werden (vgl. [26]).  Literatur [1] Goth, G.: Agile Tool Market Growing with the Philosophy. In: IEEE Software, März / April 2009, S. 88-91 [2] Beck, K., et al.: Manifesto for Agile Software Development. O. O., 2001, http: / / agile manifesto.org, Stand: 19.5.2015 [3] Kelter, U./ Monecke, M./ Schild, M.: Do We Need ‘Agile’ Software Development Tools? In: Aks¸ it, M./ Mezini, M./ Unland, R. (Hrsg.): Objects, components, architectures, services, and applications for a networked world. International Die Bewertung der drei Produkte bezüglich der Evaluationskriterien zeigt Tabelle 2. 5 Fazit und Ausblick Die Evaluationsergebnisse zeigen zwar durchaus Unterschiede in der Bewertung der untersuchten Produkte hinsichtlich ihrer Eignung für agiles Projektmanagement. Das Treffen einer Auswahlentscheidung auf der alleinigen Grundlage dieser Ergebnisse erscheint jedoch noch durchaus problematisch, da die Kriterien in der vorliegenden Form spezifische Produktunterschiede noch nicht hinreichend erfassen. Zudem muss bei der Durchführung einer Evaluierung bei einem bestimmten Unternehmen auch das unternehmensspezifische Verständnis von agilem Projektmanagement mit den Kriterien abgebildet werden. Dazu sollte zu Beginn eine Auswahl bzw. Ergänzung sowie Anpassung der Kriterien vorgenommen werden. Zudem empfiehlt sich gegebenenfalls eine Verfeinerung, bei der die vorgestellten Kriterien als Hauptkriterien dienen, deren Aussagefähigkeit sich durch schrittweise Zerlegung in Unterkriterien erhöhen lässt. Im Beitrag festgestellt wurden zudem die Erfordernisse, für eine praktische Anwendung die spezifischen Kriterien für agiles Projektmanagement um allgemeine Kriterien für Projektmaduct_Fast_Facts.pdf, Stand: 23.5.2015). In Produktstudien und Tool-Vergleichen wird es als eines der führenden Software-Werkzeuge für agiles Projektmanagement eingestuft (bspw. [25]). JIRA Agile ist ein Add-on für das Basissystem, das auf Scrum und Kanban basiert. Laut Herstellerangaben wird es von mehr als 60 Prozent der JIRA-Kunden eingesetzt. Projektron BCS: Hierbei handelt es sich um das Produkt eines kleineren Herstellers aus Berlin mit nach eigenen Angaben über 550 Kunden (www.projektron.de/ ueber-uns/ unternehmens profil, Stand: 29.5.2015), das in den oben genannten Auflistungen und Studien aus dem englischsprachigen Raum nicht berücksichtigt wird. Projektron BCS ist eine webbasierte Projektmanagement-Software, die auch Funktionalitäten für Multiprojektmanagement, Dokumentenmanagement und Kundenbeziehungsmanagement umfasst. Als Besonderheit verfügt das Produkt neben einer Scrum-Unterstützung auch über eine bidirektionale JIRA-Schnittstelle. OpenProject: OpenProject entstand ab 2012 als webbasierte Projektmanagement-Software mit Schwerpunkt auf Kollaboration. Da es sich um eine Open Source-Software handelt, konnte der Hersteller keine näheren Userzahlen angeben. In der Community befinden sich 34.000 Mitglieder, es werden 5.000 bis 6.000 Demoinstanzen pro Monat angelegt und seit November 2014 wurden etwa 5.000 Installations-Packages heruntergeladen (Angaben aus einer E-Mail des OpenProject-Teams vom 7.1.2015 als Antwort auf eine Anfrage der Autoren). OpenProject Agile basiert auf Scrum, ist ebenfalls ein Add-on für das Basissystem und kann gemeinsam mit klassischen Projektfunktionalitäten genutzt werden. 4.2 Evaluationsergebnisse Für die Bewertung wurden vier Erfüllungsgrade definiert, mit denen jedes Kriterium bewertet wurde: • Voll erfüllt: Die Funktionalität kann in vollem Umfang gemäß Anforderung und ohne Konfiguration genutzt werden. • Überwiegend erfüllt: Die Funktionalität kann nach Konfiguration in vollem Umfang genutzt werden, und/ oder es gibt geringe Abweichungen von der Anforderung. • Teilweise erfüllt: Die Funktionalität kann nicht uneingeschränkt genutzt werden. • Nicht erfüllt: Die Funktionalität ist nicht vorhanden. Kategorie Kriterium JIRA Agile Projektron BCS OpenProject Projekt Project Plan + ++ + Agile Risk Planning - - - Agile Status Reporting + + + Produkt User Stories ++ ++ ++ Feature List ++ ++ ++ Product Backlog ++ ++ ++ Prozess Techniques of Estimation o - - Iteration Backlog + ++ + Definition of Done + + + Tasks ++ ++ ++ Burndown Chart ++ ++ ++ Stand-up Meeting + + o Iteration Review ++ ++ ++ Iteration Retrospective + ++ + ++ = voll erf., + = überwiegend erf., o = teilweise erf., - = nicht erf. Tab. 2: Evaluationsergebnisse PM-aktuell_2-2016_Inhalt_01-72.indd 41 04.04.2016 5: 17: 39 Uhr projektManagementaktuell | AUSGABE 2.2016 42 WISSEN Schlagwörter agiles Projektmanagement, Projektmanagement-Software, Projektmanagement-Tools, Softwareevaluation, Tool-Evaluation Kompetenzelemente der ICB 4.0 1.02 Governance, Strukturen und Prozesse, 3.04 Ablauf und Termine, 3.10 Planung und Steuerung Autoren Erzsébet Tolnai, geboren 1986, absolvierte ihr duales Masterstudium der Wirtschaftsinformatik an der Hochschule für Telekommunikation in Leipzig mit dem Schwerpunkt Business Analytics. Nach erfolgreichem Abschluss des Studiums ist sie seit Anfang 2015 bei der KfW Bankengruppe im IT-Bereich tätig. Hier profitiert sie heute bei Aktivitäten im Projektmanagement von den in ihrer Masterarbeit gewonnen Erkenntnissen. Auf Basis dieser Masterarbeit entstand auch der vorliegende Artikel. Anschrift: KfW Bankengruppe, Informationstechnologie, Palmengartenstraße 5-9, 60325 Frankfurt am Main, E-Mail: Erzsebet.Tolnai@ kfw.de Prof. Dr. oec. (HSG) Gunnar Auth ist seit 2012 Professor für Wirtschaftsinformatik an der privaten Hochschule für Telekommunikation Leipzig und vertritt dort das Fachgebiet Informations- und Projektmanagement. Zuvor arbeitete Auth beim Automobilhersteller Daimler AG in verschiedenen Fach- und Führungsfunktionen. Anschließend war er als Direktor des Rechenzentrums der Universität Leipzig für die zentrale Bereitstellung von IT-Services verantwortlich. Als Gründer und Direktor des privaten Instituts für Bildungs- und Wissenschaftsmanagement ist Prof. Auth weiterhin mit der Praxis verbunden. Anschrift: Hochschule für Telekommunikation Leipzig, Department für Wirtschaft, Gustav- Freytag-Straße 43-45, 04277 Leipzig, E-Mail: Gunnar.Auth@hft-leipzig.de In: Hanser, E./ Mikusz, M./ Fazal-Baqaie, M.: Vorgehensmodelle 2013: Vorgehensmodelle - Anspruch und Wirklichkeit. LNI Band P-224, Bonn 2013, S. 109-132 [15] Takeuchi, H./ Nonaka, I.: The New New Product Development Game. In: Harvard Business Review, Jan.-Feb. 1986, Reprint 86116 [16] Cockburn, A.: The declaration of interdependence for modern management or DOI. O. O., 2008, http: / / alistair.cockburn.us/ The+ declaration+of+interdependence+for+modern +management+or+DOI, Stand: 19. 5.2015 [17] Chin, G.: Agile Project Management: How to Succeed in the Face of Changing Project Requirements. AMACOM, New York 2004 [18] Schwaber, K.: Agile Project Management with Scrum. Microsoft Press, Redmond 2004 [19] Oesterreich, B./ Weiss, C.: APM - Agiles Projektmanagement: Erfolgreiches Timeboxing für IT-Projekte. dpunkt.verlag, Heidelberg 2008 [20] Cockburn, A.: Agile Software-Entwicklung. mitp-Verlag, Bonn 2003 [21] Heinrich, L. J.: Bedeutung von Evaluationsforschung in der Wirtschaftsinformatik. In: Heinrich, L. J./ Häntschel, I. (Hrsg.): Evaluation und Evaluationsforschung in der Wirtschaftsinformatik: Handbuch für Praxis, Lehre und Forschung. Oldenbourg, München, Wien 2000, S. 8-22 [22] Vering, O.: Systematische Auswahl von Unternehmenssoftware. In: Becker, J., et al. (Hrsg.): Softwareauswahl und -einführung in Industrie und Handel: Vorgehen bei und Erfahrungen mit ERP- und Warenwirtschaftssystemen. Springer, Berlin et al. 2007, S. 61-108 [23] Eckkrammer, T./ Eckkrammer, F./ Gollner, H.: Agiles IT-Projektmanagement im Überblick. In: Bauer, N./ Tiemeyer, E. (Hrsg.): Handbuch IT-Projektmanagement: Vorgehensmodelle, Managementinstrumente, Good Practices. 2., überarb. u. erw. Aufl., Hanser, München 2014, S. 75-118 [24] Pröpper, N.: Agile Techniken für klassisches Projektmanagement: Qualifizierung zum PMI-ACP. mitp-Verlag, Heidelberg et al. 2012 [25] Gloger, B.: Wie schätzt man in agilen Projekten - oder wieso Scrum-Projekte erfolgreicher sind. Hanser, München 2014 [26] Habermann, F.: Hybrides Projektmanagement - agile und klassische Vorgehensmodelle im Zusammenspiel. In: HMD - Praxis der Wirtschaftsinformatik 50, 2013, 293, S. 93-102 Conference NetObjectDays, NODe 2002, Erfurt, revised papers, Springer, Berlin, New York 2003, S. 412-430 [4] Azizyan, G./ Magarian, M. K./ Kajko-Matsson, M.: Survey of Agile Tool Usage and Needs. In: Proceedings of 2011 Agile Conference, Salt Lake City, Utah, 8.-12. August 2011, IEEE Computer Society, Los Alamitos, Calif., 2011, S. 29-38 [5] Ahlemann, F.: Towards a conceptual reference model for project management information systems. In: International Journal of Project Management 27, 2009, S. 19-30 [6] Meyer, M. M./ Ahlemann, F.: Project management software systems. Requirements, selection process and products. 8. Aufl., BARC, Würzburg 2014 [7] Eichten, M.: Wie Sie PM-Tools effizient auswählen und die Akzeptanz der Anwender sicherstellen. In: projektmagazin, Nr. 5/ 2015, www. projektmagazin.de/ artikel/ wie-sie-pm-toolseffizient-auswaehlen-und-die-akzeptanz-deranwender-sicherstellen_1098045, Stand: 2.6.2015 [8] Kerzner, H.: Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 11. Aufl., Wiley, Hoboken, New Jersey, 2013 [9] o. V.: Project Management with the PC. In: PC Magazine, Jg. 3, Nr. 24, 11. Dezember 1984 [10] Dworatschek, S./ Hayek, A.: Marktspiegel Projektmanagement-Software: Kriterienkatalog und Leistungsprofile. 3., völlig überarb. Aufl., Verlag TÜV Rheinland, Köln, 1992 [11] Schelle, H.: Benchmarking von PM-Software - Vergleichende Analyse der Universität Osnabrück. In: projektManagement aktuell, Nr. 4/ 2003, S. 35-39 [12] Stang, D. B./ Handler, R. A.: Magic Quadrant for Cloud-Based IT Project and Portfolio Management Services. Gartner Inc. (Hrsg.), o. O., 2014, www.gartner.com/ doc/ 2743517/ magic-quadrant-cloudbased-it-project, Stand: 12.5.2015 [13] Visitacion, M./ Murphy, P./ McNabb, K./ Brown, R.: The Forrester Wave™: Project/ Program Portfolio Management. Q4, 2012, Forrester Research Inc. (Hrsg.), o. O., 2012, www. forrester.com/ The+Forrester+Wave+Project Program+Portfolio+Management+Q4+2012/ fulltext/ -/ E-res61657, Stand: 12.5.2015 [14] Korn, H.-P.: Das „agile“ Vorgehen: Neuer Wein in alte Schläuche - oder ein „Déjà-vu“? PM-aktuell_2-2016_Inhalt_01-72.indd 42 04.04.2016 5: 17: 42 Uhr