KONZEPT EINES LEITSTANDES FÜR AGILES MULTIPROJEKT-MANAGEMENT

Transkript

1 Fachhochschul-Masterstudiengang INFORMATION ENGINEERING & -MANAGEMENT 4232 Hagenberg, Austria KONZEPT EINES LEITSTANDES FÜR AGILES MULTIPROJEKT-MANAGEMENT Diplomarbeit zur Erlangung des akademischen Grades Master of Arts in Business Eingereicht von DI (FH) Robert Schmelzer Begutachter: FH-Prof. DI Dr. Herwig Mayr Juni 2011

2 Eidesstattliche Erklärung Ich versichere, dass ich die Diplomarbeit selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, mich auch sonst keiner unerlaubten Hilfen bedient habe und diese Diplomarbeit bisher weder im In- noch Ausland in irgendeiner Form als Prüfungsarbeit vorgelegt habe. Linz, 01. Juni 2011 DI (FH) Robert Schmelzer

3 Inhalt Kurzfassung... 1 Abstract Einleitung Begriffsdefinitionen Agile Methoden im Überblick Motivation Gemeinsamkeiten agiler Methoden extreme Programming (XP) Scrum Test-Driven Development (TDD) Dynamic Systems Development Method Crystal Methods Feature-Driven Development (FDD) Adaptive Software Development (ASD) (Rational) Unified Process Informations- und Steuerungsbedürfnisse Informations- und Steuerungsbedürfnis im Management Informations- und Steuerungsbedürfnis des Kunden Informations- und Steuerungsbedürfnis im Projektteam Informationsmodell für Fortschritt und Zielerreichung Grundlegende Überlegungen Modellvisualisierung Vertrauen durch Validierbarkeit IT-Strategie und Qualitätsanforderungen Backlog Ziel- und Fortschritt Kosten/Budget Konzept eines Leitstandes Metapher des Software-Leitstandes Grundlegende Überlegungen Datenmodell für einen Leitstand Gesamtkonzept des Leitstandes... 38

4 6.5. Elemente des Software-Leitstandes IT-Strategie Qualitätsanforderungen Backlog Burndown-Diagramm Ergebnisse / Systeme Build- und Testergebnisse Offene Defekte Vogelperspektive Produktivität Projektvorschau Planning-Burndown Anwendung des Modells auf vorhandene Daten Abgleich mit gängigen Standards und Modellen ISO 9001: CMMI ITIL Zusammenfassung und Bewertung Literaturverzeichnis Abbildungsverzeichnis... 66

5 Kurzfassung In der Softwareentwicklung haben sich agile Vorgehensweisen mittlerweile etabliert und werden in zahlreichen Projekten erfolgreich umgesetzt. In der Literatur über agile Vorgehensweisen in der Softwareentwicklung wird insbesondere auf die Durchführung von einzelnen Projekten in einem Team eingegangen. In jüngerer Vergangenheit beschäftigen sich insbesondere die Vordenker agiler Methoden mit der Frage, wie große Projekte über mehrere Entwicklungsteams hinweg mit agilen Vorgehensmethoden umgesetzt werden können. In zahlreichen IT-Organisationen ergibt sich aber die Fragestellung, wie mehrere Projekte, Anwendungen und/oder Produkte in mehreren Entwicklungsteams parallel mit agilen Vorgehensmethoden realisiert werden können. Dabei kollidiert scheinbar das Bedürfnis nach guter Planbarkeit seitens des IT-Managements und der Kunden mit den Ideen agiler Vorgehensweisen. Eingeleitet wird diese Arbeit durch einen Vergleich der wichtigsten agilen Methoden und die Beschreibung der Grundideen von agilem Vorgehen. Anschließend werden die Informations- und Steuerungsbedürfnisse der wichtigsten Projektbeteiligten erhoben und im Rahmen eines Informationsmodells dargestellt. Als wichtiger Leitgedanke dient dabei die Erkenntnis, dass Führung durch Vertrauen eine gute Möglichkeit darstellt, das Potenzial von selbstverantwortlich und kreativ agierenden Mitarbeitern voll auszuschöpfen. Dabei wurde festgestellt, dass agiles Management besonders auf das gegenseitige Vertrauen gründet und daher ausgeprägte Kontrollmöglichkeiten braucht. In der Arbeit wird beschrieben, welche Kontrollmöglichkeiten sich im agilen Projektmanagement anbieten. Aufbauend auf das Informationsmodell wird das Konzept eines Software-Leitstandes beschrieben, der die Daten des agilen Prozesses darstellt und die Informationsbedürfnisse der Projektbeteiligten befriedigt. Der Software-Leitstand dient dabei als Informationswerkzeug und Kommunikationsplattform. Bei der Konzeption wurde insbesondere auf die Vermeidung von dysfunktionalen Effekten geachtet und auf ein nachvollziehbares und transparentes Reporting Wert gelegt. Das Konzept des Leitstandes wird mit echten Daten aus einer agilen Multiprojekt Umgebung getestet und dargestellt. Seite 1

6 Abstract Agile software development methods are widely accepted for software development nowadays. The literature is concentrating on project management for single projects from small to large size. But environments where multiple teams are working on multiple projects which is quite typical for larger IT organizations are only seldom focused. IT management needs to schedule projects at least one year ahead which seems to undermine the agile idea. This thesis presents a concept how IT management can apply agile techniques on multiproject and multi-team environments. After describing the common aspects of agile project management, the work describes a model how management and other stakeholders can be kept informed about the progress of projects. The main idea is, to manage IT projects by having confidence in the development teams. Management by confidence is only possible if the results can be monitored and it enables people to work with all their energy and motivation on the project. Based on the informational model a concept to realize a software development dashboard is presented. It will present information necessary to the projects stakeholders and it will be tool for all stakeholders to force their interaction. Special attention is spent to avoid dysfunctional effects when applying reporting functions. Finally the concept will be filled with original project data to show its usefulness. Seite 2

7 1. Einleitung Nachdem agile Vorgehensweisen in der Softwareentwicklung bereits große Verbreitung erreicht haben, stellt sich immer öfter auch die Frage, wie die Vorteile agiler Softwareentwicklung auch projektübergreifend im Management von Softwareentwicklungsabteilungen eingesetzt werden können. In größeren Softwareentwicklungsabteilungen werden üblicherweise mehrere Projekte gleichzeitig von mehreren Teams entwickelt. Darüber hinaus ist es für eine Entwicklungsabteilung auch notwendig zumindest im mittelfristigen Bereich von 1-2 Jahren die Auslastung zu planen und Projekte vorzubereiten. Ein solcher Planungshorizont ist bei agilen Vorgehensmethoden nicht vorgesehen. Daher war die Ausgangsfrage, wie die Anforderung des Managements nach planbaren und vorhersehbaren Projektverläufen mit den Ideen agiler Softwareentwicklung zusammenspielen kann. Schnell war klar, dass dafür insbesondere genaue Informationen über die Produktivität und den aktuellen Status der Projekte notwendig ist. Damit hat sich auch die Frage der Erfassung von Fortschritt und Zielerreichung in agilen Projekten gestellt. Das Ziel dieser Arbeit ist die Sammlung und Zusammenstellung von Ideen und Erfahrungen aus der konkreten Arbeit in einem agilen Umfeld mit mehreren Projekten gleichzeitig. Um das Problem zu strukturieren, wurde ein Informationsmodell entwickelt, das die Informationsbedürfnisse der Projektbeteiligten und deren Einfluss auf das Projekt darstellt. Ein Informationsmodell alleine ist aber noch kein einsetzbares Werkzeug. Daher wurde in weiterer Folge auch das Konzept eines Leitstandes entworfen, das die Informationen aufbereitet und zielgruppengerecht darstellt. Um weitere Aspekte des Managements von Entwicklungsabteilungen einzubringen, wird auch eine enge Brücke zur IT-Strategie beschrieben. Die Arbeit beginnt mit der Einführung einiger grundlegender Begriffe. Im Kapitel 3. Agile Methoden im Überblick werden die wichtigsten agilen Vorgehensmodelle kurz beschrieben. Im Kapitel 4. Informations- und Steuerungsbedürfnisse werden die Bedürfnisse der Projektbeteiligten analysiert um im Anschluss daran im Kapitel 5. Informationsmodell für Fortschritt und Zielerreichung ein theoretisches Modell entwickelt. Darauf aufbauend wird im Kapitel 6. Konzept eines Leitstandes die Idee des Software-Leitstandes beschrieben und mögliche Elemente und Kennzahlen werden vorgestellt. Um die Vorschläge auf ihre Praxistauglichkeit zu prüfen, werden die Ideen im Kapitel 7. Anwendung des Modells auf vorhandene Daten auf Daten aus einem echten Projektumfeld angewendet. Das Kapitel 8. Abgleich mit gängigen Standards beschäftigt sich mit der Vereinbarkeit des Modells mit gängigen Standards und Normen der Softwareentwicklung. Schließlich finden sich in Kapitel 9. Zusammenfassung und Bewertung die wichtigsten Schlüsse und Ideen für weitere Überlegungen. Seite 3

8 2. Begriffsdefinitionen Bei den Begriffen in der IT-Branche, die zu einem großen Teil aus Veröffentlichungen aus dem englischen Raum stammen, ist es oft nur schwer möglich, eine sinnvolle deutsche Übersetzung zu verwenden. Sind für einen Begriff deutsche Übersetzungen geläufig, werden diese in der Arbeit verwendet. Begriffe, für die keine selbsterklärenden Übersetzungen verfügbar sind oder der englische Begriff weitgehend verbreitet ist, werden auch in dieser Arbeit im Englischen verwendet. Aufgrund der besseren Lesbarkeit werden in dieser Arbeit geschlechtsspezifische Begriffe in ihrer männlichen Form verwendet. Das soll nicht darüber hinwegtäuschen, dass eine gleichmäßige Geschlechtsverteilung in der IT wünschenswert wäre und die gesamte Branche von den geschlechtsspezifischen Stärken und Talenten profitieren würde. Einige Begriffe werden in dieser Arbeit wiederholt verwendet, haben allerdings keine eindeutige und verbreitete Bedeutung. Daher werden die Begriffe nachfolgend eingeführt. Projektmanagement Unter dem Begriff Projektmanagement werden alle Aufgaben zusammengefasst, die für die operative Planung, Durchführung und Abwicklung von Projekten notwendig sind. Es wird davon ausgegangen, dass die IT-Organisation Projekte bereits mit agilen Vorgehensweisen durchführt und die Vorzüge von agilem Projektmanagement bekannt und im Unternehmen verankert sind. Projektsteuerung Die Projektsteuerung umfasst alle Tätigkeiten, die notwendig sind, um ein Projekt erfolgreich zu lenken und auf unerwartete Ereignisse zu reagieren. Damit bezeichnet Projektsteuerung eigentlich den Regelkreis eines Projektes, bei dem durch aktuelle Ergebnisse und Ereignisse Einfluss auf das Projekt genommen wird. Der Begriff Projektregelung ist aber so wenig verbreitet, dass Projektsteuerung als Synonym verwendet wird. IT-Management Als IT-Management wird in dieser Arbeit der Aufgabenbereich beschrieben, der für die mittel- und langfristige Ausrichtung (1-5 Jahre) und die strategische Entwicklung einer IT- Organisation zuständig ist. In größeren Unternehmen sind dies eigene Managementebenen, die im Gegensatz um Projektmanagement nicht mehr mit der operativen Durchführung von Projekten beschäftigt sind. Release / Rollout Nachdem die Erfahrungen, die der Arbeit zugrunde liegen, in einer IT-Abteilung für interne Fachbereiche eines Unternehmens gemacht wurden, konnte Software auf einfache Art und Weise in Produktion genommen werden. Wenn von Release oder Rollout gesprochen wird, ist in dieser Arbeit die Inbetriebnahme der Software für die internen Kunden gemeint. In einem Unternehmen im klassischen Produktverkauf kann dieser Schritt oftmals nicht so einfach umgesetzt werden, da Standardprodukte nicht in beliebig kurzen Versionszyklen auf den Markt gebracht werden können. Seite 4

9 Anwendung / System In großen Unternehmen existieren oftmals zahlreiche Anwendungen oder Systeme zur Unterstützung der internen Prozesse. Dabei unterstützt eine Anwendung spezifische Geschäftsprozessteile oder Gruppen von Teilprozessen. Zumeist sind die Anwendungen auf die Benutzergruppe zugeschnitten. Damit werden Geschäftsprozesse oder Geschäftsteile meist erst durch das Zusammenspiel mehrere Anwendungen oder Systeme realisiert. Anwendungen haben einen definierten Lebenszyklus und sind über einzelne Projekte hinaus in Verwendung und Entwicklung. Damit werden Anwendungen und Systeme im Laufe der Zeit über viele Projekte hinweg entwickelt. Projekt Ein Projekt ist ein zeitlich und budgetär eingegrenztes Vorhaben, um Anwendungen oder Produkte zu entwickeln, neue oder veränderte Geschäftsprozesse und/oder Geschäftsfelder umzusetzen und zu erschließen. Damit sind Projekte aus einer wirtschaftlichen Überlegung heraus motiviert. Einzelne Projekte können in Anwendungs- und Systemlandschaften zahlreiche Veränderungen und Anpassungen notwendig machen. Es ist also möglich, dass einzelne Projekte mehrere Systeme und Anwendungen betreffen und damit auch die Zusammenarbeit mehrerer Teams erfordern. Multiprojekt In großen Organisationen laufen mehrere Projekte parallel bzw. sind auch mehrere in Planung und Vorbereitung. Ein solches Umfeld wird in dieser Arbeit als Multiprojekt- Umgebung bezeichnet. Das ist schon alleine aufgrund der notwendigen Risikosteuerung und zur Auslastung der Personalressourcen notwendig. Das unterscheidet die Perspektive dieser Arbeit auch wesentlich von anderer Literatur über agile Vorgehensweisen, die Projekte meist nur singulär betrachtet. In dieser Arbeit wird allerdings nicht betrachtet, wie sehr große Projekte auf viele Teams aufgeteilt werden können. Damit beschäftigt sich zum Beispiel [Eckstein 2009]. Multiteam Nachdem in einer Multiprojekt-Umgebung viele Projekte parallel umgesetzt werden, die auch verschiedene Anwendungen und Systeme betreffen, müssen dafür auch mehrere Teams zur Verfügung stehen. Daher wird der Begriff Multiteam-Umgebung verwendet. Diese Teams sind nicht beliebig austauschbar, da sie jeweils spezifisches Wissen über die Systeme und deren fachlichen Kontext haben. Die universelle Austauschbarkeit von Entwicklern ist zwar oftmals ein Wunsch des IT-Managements, lässt sich aber in der Praxis nicht realisieren. Der willkürliche Austausch von Entwicklern in Teams führt zu sozialen Spannungen in den Teams und zum Wissensverlust der beteiligten Personen. Dadurch wird auch die Produktivität der Teams sinken, was durch eine transparente Darstellung im agilen Projekt auch deutlich sichtbar wird. Diese Arbeit beschäftigt sich intensiv mit Multiprojekt-Multiteam-Umgebungen. Es handelt sich dabei also um IT-Organisationen die mit mehreren Teams unterschiedliche Projekte gleichzeitig umsetzen. Seite 5

10 3. Agile Methoden im Überblick Dieses Kapitel beschäftigt sich mit den Grundlagen agiler Softwareentwicklung und der Motivation, die diesen zugrunde liegt. Nachdem die Motivation und die Gemeinsamkeiten agiler Methoden beschrieben werden, folgt eine kurze Erläuterung der am weitesten verbreiteten Ansätze. Die Informationen zu den einzelnen agilen Methoden stammen, soweit nicht anders angeführt, aus [Highsmith 2002] Motivation Betrachtet man die Geschichte der Ablauforganisation von Softwareprojekten, zeigt sich eine klare Tendenz. Die ersten Ansätze haben Projekte als eine Abfolge von Projektphasen beschrieben. Durch das sequenzielle Vorgehen konnten aber Änderungen der Anforderungen nicht in den Projektablauf integriert werden. Die gewonnenen Erkenntnisse im Zuge der Umsetzung können erst in folgenden Projekten eingesetzt werden. Daher hat sich die Ablauforganisation von Projekten schrittweise zu iterativen Vorgehensweisen entwickelt, bei denen die Iterationsdauer immer kürzer wurde. Durch Einführung des Wasserfallmodells wurden erstmals Zyklen in Projektphasen integriert. Später hat das Spiralmodell Iterationen über alle Phasen des Projektes gespannt. Damit ist die iterative Vorgehensweise von agilen Entwicklungsmethoden absolut keine neue Erfindung, sondern lediglich eine logische Weiterentwicklung in der Softwareentwicklung. Durch die beschleunigten Abläufe in Unternehmen und sich ständig ändernden wirtschaftlichen Umstände wurde insbesondere seit Mitte der 80er Jahre die Anpassbarkeit von Projekten während ihrer Laufzeit immer mehr zum Thema. Es wurde zunehmend deutlich, dass eine vollständige Anforderungserhebung am Beginn eines Projektes oft nicht mehr sinnvoll oder auch gar nicht möglich war. Es wurde also notwendig, sich ändernde Anforderungen als Bestandteil des Entwicklungsprozesses zu etablieren. Diesen Anspruch konnten die klassischen Phasenmodelle nicht mehr hinreichend erfüllen. Neben den oben genannten, vornehmlich sachlich orientierten Motivationsgründen war für die Entwicklung von agiler Softwareentwicklung noch ein sozialer Gedanke wesentlich. Durch die starke Reglementierung und Kontrolle in klassischen Projektvorgehensweisen haben sich immer mehr Teams sozial ungünstig entwickelt. Es scheint besonders bei Programmierern so zu sein, dass diese auf zu starke Regeln und Kontrollen negativ reagieren und dann nicht ihr volles Potenzial nutzen können. Agile Softwareentwicklungsmethoden streben durch Schaffung eines günstigen Arbeitsumfeldes eine hohe Teamproduktivität an, wobei in diesem Kontext Produktivität auch Kreativität, Kommunikationsstärke, Einsatzbereitschaft, Qualität und Produktfortschritt im engeren Sinn umfasst. Seite 6

11 3.2. Gemeinsamkeiten agiler Methoden Die wichtigsten Grundlagen agiler Softwareentwicklung wurden im Agilen Manifest [Agile Manifest 2008] zusammengetragen: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Aufbauend auf diesen vier Richtlinien lassen sich beinahe alle wichtigen Regeln und Aspekte von agilen Vorgehensmethoden erklären. Alle agilen Vorgehensweisen fokussieren auf eine intensive Zusammenarbeit aller Beteiligten in Form von zwischenmenschlicher Kommunikation. Umfangreiche Dokumente werden nur dann produziert, wenn diese auch als Teil des Projektergebnisses notwendig sind, nicht aber aus der Vorgehensmethode selbst motiviert. Viele agilen Vorgehensmethoden versuchen möglichst früh im Prozess bereits ausführbare und benutzbare Software zu schaffen, sodass bereits frühzeitig gewonnene Erkenntnisse in den Entwicklungsprozess einfließen können. Um die beschriebenen Richtlinien und Grundideen erfolgreich umzusetzen, haben sich einige sehr gängige Techniken zur Softwareentwicklung etabliert, die sich so oder in abgewandelter Form in allen Methoden wiederfinden. Zentrales Element in allen Vorgehensweisen ist ein iteratives Vorgehen und Zyklen von 1-4 Wochen, in denen jeweils benutzbare und für den Kunden wertvolle Funktionalität vollständig umgesetzt wird. Eine weitere besonders wichtige Grundidee der agilen Softwareentwicklung ist die Einplanung von Änderungen. Agile Softwareentwicklung versucht im Gegensatz zu traditionellen Ansätzen nicht mehr, Funktionalität eines Projektes im Vorhinein in Stein zu meißeln, sondern geht ganz bewusst davon aus, dass sich Anforderungen und Wünsche im Verlauf des Projektes ändern werden. Dazu wird am Anfang jeder Iteration festgelegt, was in dieser Iteration umgesetzt werden soll. Alle anderen Anforderungen, die nicht gerade umgesetzt werden, können vom Kunden noch verändert und anders gereiht werden. Welche Konsequenzen dieses Vorgehen für die Vertragsgestaltung hat, wird hier nicht näher behandelt. Derzeit werden agile Vorgehensweisen oft noch als unverbindlich, unstrukturiert oder chaotisch abgestempelt oder sie werden als Freibrief für nicht dokumentiertes oder adhoc gesteuertes Vorgehen verwendet. Diese Problematik ist wohl großteils auf die wichtigsten Vertreter von agilen Methoden zurückzuführen, die in den Anfangsjahren oft noch eine revolutionäre Umstellung und das Wegwerfen aller Dokumente gepredigt haben. Damit wurden agilen Methoden oftmals missverstanden bzw. die Maßnahmen und Techniken wurden nicht richtig eingeordnet. Betrachtet man agile Methoden abseits provokan- Seite 7

12 ter Formulierungen, wird deutlich, dass diese meist sehr klar strukturiert sind und klare eindeutige Regeln haben. Die Maßnahmen von agilen Entwicklungsmethoden sind zumeist aus langjähriger Projekterfahrung in klassischen Vorgehensweisen hervorgegangen. Es wird darauf geachtet, diese Arbeit auf die Gemeinsamkeiten agiler Softwareentwicklungsmethoden aufbaut. Die gewählte Terminologie und Details zur Vorgehensweise stammen aus der Methode Scrum [Schwaber 2004]. In den meisten agilen Vorgehensweisen finden sich folgende Elemente wieder: Klare Regeln Agile Vorgehensweisen zeichnen sich durch klare und meist auch strenge Regeln aus. Die Regelwerke von agilen Vorgehensweisen sind üblicherweise einfach darstellbar und meist als Gesetz formuliert. Im Gegensatz zu klassischen Modellen sind diese Regeln meist strenger formuliert, dafür aber auch einfacher kontrollierbar. Beispielsweise fordern viele agile Vorgehensweisen eine tägliche Morgenbesprechung im Team, die auch klaren Vorgaben folgt. In den Regeln sind üblicherweise auch die abzuhaltende Besprechungen und zu führenden Dokumente beschrieben. Backlog Der Backlog ist eine Sammlung aller Anforderungen in Form von Anwendungsfällen, User Stories, Features oder Akzeptanztests. Die Liste ist nach ihrer Bedeutung für die Projektbeteiligten des Projektes priorisiert und bestimmt damit auch die Umsetzungsreihenfolge für das Projektteam. Enger Kundenkontakt Die Zusammenarbeit mit dem Kunden bzw. Projektbeteiligten des Projektes geht weit über den einfachen Dokumentenaustausch hinaus. Kommunikation steht als zentrales Werkzeug der Softwareentwicklung im Mittelpunkt und alle Dokumentation unterliegt nur der Unterstützung dieser. Regelmäßiges Feedback (Review und Retrospektive) Aufbauend auf den engen Kundenkontakt spielt die stetige Rückmeldung (Feedback) vom Kunden aber auch im Team selbst eine wichtige Rolle. Sie dient zur stetigen Verbesserung sowohl des Produktes als auch des Prozesses selbst. Gemeinsames Schätzen Die Anforderungen aus dem Backlog werden vom agilen Team selbst geschätzt. Meist werden dazu abstrakte Schätzgrößen vorgeschlagen, die nur einen relativen Bezug von Anforderungen zueinander herstellt. Durch die gesammelten Erfahrungen über einige Iterationen hinweg, ergibt sich ein Erfahrungswert, wie viel Arbeit das Team in der vorgegeben Zeit erledigen kann. Damit entscheidet das Team auch selbst, wie viel es in einer vorgegebenen Zeitspanne (Iteration) fertigstellen kann. Iterationen / Inkremente (Sprint) Iterationen sind Zyklen in Zeitumfang von etwa 1-8 Wochen in denen das Team weitgehend ungestört seiner Arbeit nachgehen kann und am Ende der Iteration zuvor vereinbarte Ergebnisse den Projektbeteiligten präsentieren müssen. Dazu übernimmt das Team Seite 8

13 Elemente aus dem Backlog in die Iteration. Das Team muss gemeinsam eine Regelung finden, wann die Elemente des Backlogs als abgeschlossen bezeichnet werden dürfen ( Definition of Done oder DoD ). Damit werden Elemente des Backlogs üblicherweise mit nur drei Status eingeordnet: nicht bearbeitet, in Arbeit und fertiggestellt. Viele agile Vorgehensweisen sehen vor, dass jede Iteration ein nutzbares Produktinkrement sein muss, dass potentiell auch an den Kunden ausgeliefert werden kann extreme Programming (XP) Extreme Programming (XP) wurde maßgeblich von Kent Beck im Rahmen des C3-Projektes bei Chrysler entwickelt und in [Beck 2000] beschrieben. Die Inhalte dieser Zusammenfassung stammen aus [Lippert/Roock/Wolf 2002], die XP in konkreten Projektsituationen beschreiben. XP baut auf vier Grundwerte, zwölf Prinzipien und zwölf Techniken auf. Die vier Grundwerte sind einfache Lösungen, Feedback, Kommunikation und Mut. Die Prinzipien sind Umsetzungen der Grundwerte und geben Anleitungen für die Projektkultur. So lautet ein Prinzip Verantwortung übernehmen und ist damit dem Grundwert Mut zuzuordnen und fordert vom Team die Bereitschaft, Verantwortung für ihr Tun und ihre Entscheidungen zu übernehmen. Die zwölf Techniken sind eine Sammlung von zum Teil bereits bekannten Vorgehensweisen zur Entwicklung hochqualitativer Software. Sie umfassen zum Beispiel Pair Programming, Fortlaufende Integration oder vollständiges Unit Testen. Neu an XP ist die konsequente Verbindung der Techniken zu einem integrierten, aufeinander aufbauendem System. XP ist wohl auch die umstrittenste Methode. XP wurde im Zuge des C3-Projektes bei Chrysler entwickelt. Von den Vertretern von XP als ultimativer Erfolg gefeiert, gibt es Kritiker, die das Projekt als Fehlschlag bezeichnen [C3 Project Wiki 2009]. Das liegt wohl einerseits an der beinahe fundamentalistischen Art und Weise der XP-Evangelisten, andererseits liegt das auch am sehr fragilen Zusammenspiel der einzelnen Systemteile. Das Gesamtsystem XP neigt zur Instabilität, wenn einzelne Techniken nicht befolgt werden [Stephens/Rosenberg 2003]. Darüber hinaus fokussiert XP zu stark auf das Projektinnenleben und lässt damit Herausforderungen der umgebenen Projektsituation außer acht. Ein Beispiel dafür ist die Technik Vor-Ort-Kunde (On-Site-Customer). In XP wird gefordert, dass ein Kundenvertreter ständig im Projektteam mitarbeitet und so alle fachlichen Fragen entscheidet und beantwortet. Die Vorstellung, dass ein einziger Kundenvertreter alle fachlichen Fragen beantworten kann, ist selbst bei Kleinprojekten eine zu starke Simplifizierung der Realität. Aus Sicht eines Entwicklungsteams wäre das natürlich wünschenswert, ist aber nur in seltenen Umständen umsetzbar. Auf diese Weise hat XP einerseits einen wichtigen Grundstein in der Diskussion um agile Vorgehensweisen gelegt. Auf der anderen Seite hat XP aber durch die zu provokanten und zu stark vereinfachenden Darstellungen die agilen Ansätze im Allgemeinen ins falsche Seite 9

14 Licht gerückt. Seit dem Hype um XP kämpfen alle agilen Methoden mit dem Vorurteil, zu simpel oder zu chaotisch zu sein Scrum Scrum ist schon Anfang der 90er Jahre entstanden und stammt ursprünglich aus der Produktentwicklung [Takeuchi/Nonaka 1986] und wurde sowohl von Ken Schwaber als auch Jeff Sutherland ungefähr Mitte der 90er Jahre auf die Softwareentwicklung angewandt [Schwaber/Sutherland 1997]. Nach dem Hype um XP wurde Scrum zu der am weitesten verbreiteten agilen Vorgehensweise. Dafür ausschlaggebend ist vermutlich auch die professionelle Organisation in der Scrum Alliance [ScrumAlliance 2011] und das weit verbreitete Schulungs- und Zertifizierungsprogramm. Abbildung 1 zeigt die Verbreitung verschiedener agiler Methoden. Obwohl in [VersionOne 2009] nicht angeführt, kann man annehmen, dass diese Daten vorrangig aus dem amerikanischen und europäischen Raum stammen, da im asiatischen Raum Lean Development und Feature Driven Development stärker verbreitet sind. Abbildung 1 - Häufigkeit agiler Vorgehensmodelle (Quelle: [VersionOne 2009]) Die folgende Zusammenfassung von Scrum stammt aus [Schwaber 2004]. Scrum bietet ein einfaches Prozessmodell mit wenigen klar beschriebenen Artefakten und mit klar definierten Rollen im Team. Abbildung 2 stellt die wichtigsten Elemente von Scrum dar. Damit kann Scrum einfach und mit verschiedenen Werkzeugen und Vorgehensweisen eingeführt werden. Aufgrund des robusten Aufbaus des Prozesses ist eine Anpassung an die Bedürfnisse im Unternehmen auch mit weniger Erfahrung möglich. Wichtig ist dabei, dass die Grundlagen und die Motivation von Scrum verstanden wurden, um die zentral wichtigen Elemente konsequent beizubehalten. In Scrum werden die Anforderungen als Anwendungsfälle (Stories) im Backlog beschrieben. Der Backlog wird vom Product Owner gepflegt und priorisiert. Innerhalb eines Sprints entscheidet das Team, wie viele Elemente des Backlogs in den Sprint aufgenommen werden und gibt ein Versprechen ab, alles daran zu setzten diese Elemente im Sprint auch umzusetzen. Das Team selbst iteriert im Tageszyklus und stimmt sich im Daily Scrum Meeting untereinander ab. Damit entscheidet in Scrum das Team selbst über die Menge der Seite 10

15 Arbeitspakete, die es umsetzen kann. Das ist auch der größte kulturelle Unterschied und bringt die meiste Verunsicherung mit sich. Durch die einfache Idee, dass von außen entschieden wird WAS umgesetzt wird und das Team selbst WIEVIEL in gewisser Zeit machbar ist, trägt im Projekt jeder die Verantwortung für jene Bereiche, die er auch tatsächlich selbst beeinflussen kann. Damit ist auch eine wichtige Grundlage für vertrauensvolles Zusammenarbeiten geschaffen (vgl. [Sprenger 2002]). Abbildung 2 - Scrum Übersicht (Quelle: [Softhouse 2011]) In Scrum ist das Team selbstorganisiert. Das Team muss also für eine geeignete Arbeitsumgebung und alle notwendigen Vorbedingungen selbst Sorge tragen. Dabei kommt dem Scrum Master eine wesentliche Aufgabe zu, der das Team beim Erkennen und Beseitigen von Stolpersteinen und Produktivitätshindernissen unterstützt. Für viele Organisationen ist das einer der schwierigsten Schritte in Scrum. Das Management hadert beim Abgeben von Verantwortung. Aber auch die Scrum-Teams müssen lernen, diese Verantwortung neu zu übernehmen und für ein produktives Arbeitsumfeld selbst zu sorgen. Die Kommunikation der Anforderungen wird über den Product Owner gebündelt. Das Team kommuniziert über den Product Owner mit den Projektbeteiligten. Damit kommt dem Product Owner eine sehr wichtige und schwierige Rolle zu. Die Komplexität des Stakeholder Managements und die kommunikativen Herausforderung der Anforderungserhebung muss meist der Product Owner handhaben. In manchen Situationen kann es daher auch sinnvoll sein, die Rolle des Product Owners an mehrere Personen zu vergeben. Innerhalb eines Sprints können Stakeholder im Normalfall nicht mehr in die Arbeit des Teams eingreifen. Steuerungsmöglichkeiten besteht für Stakeholder nur an den Anfangsund Endzeitpunkten der Sprint. Dieses Verständnis im Management zu verankern ist eine Seite 11

16 weitere Herausforderung bei der Umsetzung von Scrum. Konsequenterweise muss das Team bei Einflussnahme von außen den aktuellen Sprint abbrechen und löst damit auch das Versprechen zum Sprint-Ergebnis auf. Damit werden in Scrum durch ein sehr einfaches Prozessmodell alle wesentlichen Einflussmöglichkeiten von außen klar geregelt. Die wichtigen Kommunikationskanäle werden definiert, ohne damit einen ungebührlichen Mehraufwand einzuführen. Prozessbezogene Dokumentationen werden nur soweit geführt, als es für die Einhaltung der Prozessregeln notwendig ist Test-Driven Development (TDD) Test-Driven Development (TDD) wird hauptsächlich von Kent Beck propagiert [Beck 2002], der auch schon Gedankenvater von XP ist. TDD ist ursprünglich als Entwicklungstechnik für qualitativ besseren Code entstanden. Im Zuge der massiven Verbreitung von agilen Methoden und deren kurzer Iterationszyklen hat sich bald die Notwendigkeit ergeben, auch die gesamten Akzeptanz- bzw. Abnahmetests zu automatisieren. Damit kann ein System mit kurzen Releasezyklen verhältnismäßig einfach regressionsgetestet werden. Qualitativ hochwertige Akzeptanz- bzw. Abnahmetests müssen die Spezifikation des Systems abdecken. Daraus entstand die Idee, die Spezifikation durch die Tests zu ersetzen. Damit wird das Spezifikationsdokument überflüssig, das ja ohnehin nur in der Ablauforganisation von Bedeutung war, jedoch keinen Wert für das Endprodukt geliefert hat. Stattdessen entstehen gleich zu Beginn die Akzeptanz- und Abnahmetests die im späteren Verlauf für die Umsetzung von agilen Vorgehensweisen von großer Bedeutung sind. Daher fordert TDD die Abnahme- und Akzeptanztests gemeinsam mit dem Kunden zu formulieren und somit auch das System zu spezifizieren. Die volle Stärke kann dieser Ansatz aber nur entwickeln, wenn die Tests auch für die automatisierte Ausführung vorgesehen sind. Dazu entstehen am Markt sowohl Open Source Werkzeuge wie [Fitnesse 2011] als auch kommerzielle Werkzeuge wie [Tosca 2011]. Damit ist TDD keine vollständige agile Vorgehensweise, sondern kann im Zuge anderer agiler Ansätze als alternative Entwicklungsmethode verwendet werden Dynamic Systems Development Method Die Dynamic Systems Development Method (DSDM) hat eine langjährige Entwicklungsgeschichte und hatte ihren Ursprung auf Basis von Rapid Application Development (RAD). Mittlerweile wurden die Buchstaben neu interpretiert und damit modernisiert. Mittlerweile soll DSDM für Dynamic Solution Delivery Model stehen. Damit kommt zum Ausdruck, dass DSDM wie alle agilen Methoden darauf fokussiert nutzbare Lösungen mit Kundennutzen in dynamischen Umfeldern zu liefern. Ein wesentlicher Unterschied zu anderen agilen Methoden ist das Verständnis als Prototyping-orientierte Methode. DSDM macht eine klare Aussage, dass Software nie beim ersten Versuch perfekt ist. Damit geht DSDM davon aus, dass Teile der Software auch wieder verworfen oder völlig neu erstellt werden. Seite 12

17 DSDM unterteilt den Software-Lebenszyklus in drei große Phasen, wobei die ersten zwei in kurzen Iterationen durchlaufen werden: Funktionales Modellieren (Functional Model), Softwaredesign und Umsetzung (Design & Build), Inbetriebnahme (Implementation). Der englische Begriff Implementation kann leicht missverstanden werden. DSDM meint damit die Inbetriebnahme der Software im Unternehmen. Das Kodieren bezeichnet DSDM mit dem Begriff Build. Ein anderer bemerkenswerter Aspekt an DSDM ist die Entscheidungsfähigkeit des Teams. DSDM fordert, dass das Team in der Lage sein muss, Entscheidungen zu treffen, die unmittelbaren Einfluss auf die Produktfunktionalität haben Crystal Methods Crystal Methods (CM) wurde von Alistair Cockburn entwickelt. Die wesentliche Grundlage dafür bildet das Verständnis, dass Softwareentwicklung ein kooperatives Zusammenspiel von Entwicklung und Kommunikation ist. Darüber hinaus hat Cockburn verstanden, dass es nicht eine einzige richtige Methode für alle Projektgrößen und Umfelder geben kann. Daher bietet Crystal Methods einen Werkzeugkasten aus Methoden (Methodology), Techniken (Techniques) und Vorgaben (Policies). Über eine dreidimensionale Darstellung von mitwirkenden Personen, kritische Einflussfaktoren und die Projektdomäne wird eine Anleitung gegeben, welche Elemente sinnvoll eingesetzt werden können. Zum Beispiel wird mit CM die Anzahl jener Projektartefakte reduziert, die nur der Ablauforganisation selbst dienen. In einer kleinen Projektorganisation sind weniger Zwischendokumente und Berichte notwendig als in einem Projekt mit mehreren hunderten Beteiligten Feature-Driven Development (FDD) Feature-Driven Development (FDD) hatte ihren Ursprung auch Mitte bis Ende der 90er Jahre in großen Projekten im australischen und asiatischen Raum. Die Konzentration auf die Features ist hier besonders bemerkenswert, da gerade große Projekte dazu tendieren, durch einen schwerfälligen Prozess unflexibel und nicht mehr steuerbar zu werden. Auf Basis dieser Erkenntnis haben Jeff De Luca und Peter Coad in Großprojekten in Banken und Versicherungen das Feature als zentrales Artefakt im Prozess in den Vordergrund gebracht. Seite 13

18 Die wichtigsten Grundlagen von FDD fasst [Coad 2000] unter anderem so zusammen: A simple, well-defined process works best. Process steps should be logical and their worth immediately obvious to each team member. Good processes move to the background so team members can focus on results. Diese Einstellung ist natürlich gerade für Großprojekte mit Entwicklern bemerkenswert. FDD selbst gliedert sich in 5 einfache Phasen: 1. Modellentwicklung, 2. Feature-Liste erstellen, 3. Features planen (priorisieren), 4. Feature designen, 5. Feature umsetzen. Die Phasen 4 und 5 werden iterativ durchlaufen. Im ersten Moment scheint FDD nicht auf Änderungen reagieren zu können, nachdem ja in Phase 2 schon die Feature Liste erstellt wird. Das ist allerdings nicht so zu verstehen. Für FDD ist Veränderung etwas so Selbstverständliches, dass es nicht im Prozess erwähnt wird. Die Feature Liste kann immer abgeändert und angepasst werden. FDD gibt auch eine grobe Anleitung in Prozent, wie viel Zeit jeder Schritt einnehmen soll. Bemerkenswert ist dabei die Phase der Modellbildung (Develop an Overall Model) mit initial rund 10% der Projektzeit. Damit werden am Beginn des Projektes eine gemeinsame Vision, ein gemeinsames Modell und damit auch eine gemeinsame Sprache entwickelt. Die Empfehlung von FDD ist hier ein Domänenmodell auf Klassenbasis zu entwickeln. Nach Meinung des Autors dieser Arbeit wäre die Ergänzung dieser initialen Phase der Modellbildung eine sehr sinnvolle Ergänzung für Scrum. Würde man diese Ergänzung vornehmen, wären sich Scrum und FDD in vielerlei Hinsicht sehr ähnlich. Außer der Ähnlichkeit im Namen zum Test-Driven Development haben TDD und FDD wenig gemeinsam. Sie sind aus unterschiedlichen Motiven entstanden und basieren auch zum Teil auf anderer Denkkultur Adaptive Software Development (ASD) Dem Vorgehen nach Adaptive Software Development (ASD) liegt die Erkenntnis zu Grunde, dass sich Software im Lebenszyklus verändert und daher stetig adaptiert werden muss. Entstanden ist ASD aus den Erfahrungen von Jim Highsmith [Highsmith 1997]. Seite 14

19 Der ASD Prozess besteht aus 5 Phasen: 1. Initialphase, 2. adaptive Planung, 3. Feature-Umsetzung, 4. Qualitäts-Review, 5. abschließende QA und Release. Die ersten beiden Phasen sind dabei explizit von großer Ungewissheit bestimmt. Es wird also von Anfang an klar gestellt, dass zwar eine gemeinsame Vision entwickelt wird, dabei aber noch keine endgültigen Entscheidungen in Stein gemeißelt sind. Die Phasen 2-4 werden iterativ durchlaufen. Die Rückkopplung bezeichnet ASD als Lernschleife (Learning Loop) und sieht damit einen Lernprozess im Laufe des Projektes vor (Rational) Unified Process Der (Rational) Unified Process (RUP) ist der wohl schwerfälligste unter den agilen Vorgehensweisen. Durch die Ausgestaltung ist der Ursprung im klassischen Phasenmodell noch deutlich spürbar und er wurde nur durch einige Aspekte agiler Softwareentwicklung ergänzt. Abbildung 3 zeigt die Grundstruktur von RUP, bei der die vier Phasen des Projekts in zeitlich begrenzten Iterationen durchlaufen werden. Zusätzlich sind noch die Tätigkeitsschwerpunkte der einzelnen Phasen dargestellt. Abbildung 3 - Übersicht über RUP (Quelle: [Kruchten 2004]) Seite 15

20 RUP bezeichnet das eigene Vorgehen als iterativ und inkrementell. Basierend auf Abbildung 3, ist unklar in weit das Vorgehen tatsächlich inkrementell ist. Es ist auf jeden Fall nicht möglich, am Ende einer jeden Iteration Kundennutzen zu erzielen. Das Ergebnis von Elaborationsphasen kann dem Kunden wohl nicht als nutzbarer Fortschritt präsentiert werden. RUP soll Anwendungsfall-, Architektur- und Risiko-zentriert sein. Es sollen also die wichtigsten Anwendungsfälle mit dem größten Risiko fokussiert werden. Dafür soll vorrangig die geeignete Architektur geschaffen werden. Wie das im Detail möglich sein soll, wenn erst nach der gesamten Elaborationsphase mit der Konstruktion begonnen wird, lässt RUP weitgehend offen. Nach Ansicht des Autors ist RUP zwar eine iterative Vorgehensweise, aber keine wirklich agile Vorgehensweise. RUP propagiert eigentlich nur ein modernisiertes Phasenmodell, in dem die einzelnen Phasen in Iterationen zeitbegrenzt abgearbeitet werden. Die zentralen Fragen agiler Softwareentwicklung, wie das Reagieren auf geänderte Anforderungen oder das Fördern von Kommunikation und Beseitigen von nutzlosen Artefakten bleibt, unbeantwortet. Seite 16

21 4. Informations- und Steuerungsbedürfnisse 4.1. Informations- und Steuerungsbedürfnis im Management Das Software Engineering konzentriert sich zumeist auf die erfolgreiche Umsetzung einzelner Projekte und beschäftigt sich daher intensiv mit den Anforderungen und Informationsbedürfnisse einzelner Projekte. In größeren Organisationen werden aber viele Projekte gleichzeitig umgesetzt. Damit stellt sich die Frage, welche Informationsbedürfnisse im IT-Management entstehen, wenn diese den Erfolg des Geschäftsbereiches über das einzelne Projekt hinaus sicherstellen müssen. Daher wird nachfolgend versucht die Unterschiede zwischen den Informationsbedürfnissen im Projekt und im IT-Management deutlich zu machen. Magisches Viereck Neben [Elzer 1994] wird auch in vielen anderen Publikationen das Spannungsfeld des Projektmanagements als Magisches Dreieck beschrieben. Das Magische Dreieck entsteht durch die Dimensionen Kosten, Qualität und Zeit. Nachdem im klassischen Projektmanagement der Funktionsumfang eines Projektes vorab definiert war, wird diese auch nicht als variable Dimension angesehen. In diesem Modell wird dargestellt, dass eine Optimierung in einer der Dimensionen immer negative Auswirkungen auf die anderen beiden Dimensionen hat. So führt der Versuch die Kosten zu minimieren auch zu Qualitätseinbußen oder der Versuch die Lieferzeit zu verkürzen wird die Kosten erhöhen. Abbildung 4 - Magisches Dreieck im Projektmanagement Durch die Etablierung von agilen Vorgehensweisen in der Softwareentwicklung wurde auch Funktionalität zur variablen und steuerbaren Größe im Projekt. Damit muss auch das Magische Dreieck des Projektmanagements angepasst werden. In [Heilwagen 2010] wir daher ein Pentagon vorgeschlagen, das zusätzlich Kundenzufriedenheit und Inhalt und Umfang beinhaltet. Die Kundenzufriedenheit kann nur durch Seite 17

22 Befragung gemessen werden. Ansonsten kann Kundenzufriedenheit nur durch Ableitung anderer Größen eruiert werden. Damit ist sie nicht Teil der primären Projektdaten und zur Projektsteuerung und Überwachung wenig geeignet. Abbildung 5 Projektpentagon nach Heilwagen Daher wird hier der Ansatz aus [Mayr 2005] verfolgt, der das Magische Viereck beschreibt. Dabei wird das klassische Dreieck um die zusätzliche Größe Funktionalität erweitert. In ähnlicher Weise wird diese Situation auch schon in [Sneed 1987] als Teufelsquadrat beschrieben. Abbildung 6 - Teufelsquadrat nach Sneed Funktionalität bzw. Quantität wird in agilen Projekten aber nicht direkt bewertet. Agile Ansätze versuchen den Kundennutzen bzw. Business Value zu maximieren. Dem liegt die Überlegung zu Grunde, dass nicht alle Funktionen einer Software für den Kunden gleich wertvoll sind. Um einen Projekterfolg zu unterstützen, sollte daher nicht die Funktionalität der Anwendung, sondern der Kundennutzen maximiert werden. Aus diesen Überlegungen heraus ergibt sich für das moderne Projektmanagement ein Magisches Viereck aus den Dimensionen Qualität, Kundennutzen (Business Value), Kosten und Zeit. Aus der Abbildung des Teufelsquadrates ist auch ersichtlich, dass die Fläche, die durch die vier Leistungspunkte aufgespannt wird, der Produktivität im Projekt entspricht. Damit wird deutlich, dass eine Optimierung in alle vier Richtungen des Quadrates nur durch eine Steigerung der Produktivität zu erreichen ist. Seite 18

23 Das Projektmanagement hat im Zuge eines konkreten Projektes hauptsächlich die Aufgabe das Projekt zu überwachen und wenn notwendig auch sinnvoll korrigierend einzugreifen. Damit muss das Projektmanagement in der Lage sein, den Projektfortschritt nachzuvollziehen. Zur sinnvollen Überwachung eines Projektes muss ein Vergleich vom geplanten Erfolg zum tatsächlich erreichten Projektfortschritt möglich sein. Für eine zielgerichtete Steuerung von Projektteams ist damit in allen vier Dimensionen des Teufelsquadrates ein Soll-/Ist-Vergleich der Daten notwendig. Somit muss ein Informationsmodell für die Steuerung die notwendigen Daten für diesen Vergleich liefern. In der Dimension Quantität ist der Projektfortschritt mit dem gesetzten Projektzielen zu vergleichen. In der Dimension Qualität ist abzusichern, dass die geforderten Qualitätsrichtlinien im fertigen Produkt auch tatsächlich eingehalten werden. Die Projektdauer kann durch die Umrechnung der Produktivität des Teams im Bezug zu den gesetzten Zielen betrachtet werden. Der Aufwand wird durch die eingesetzte Arbeitsleistung der Teams bestimmt. Die voraussichtlich verbleibenden Aufwände lassen sich wieder durch Umrechnung von prognostizierter Produktivität auf das gesetzte Ziel berechnen. Für das IT-Management ist aber neben den klaren Kennzahlen oft auch menschliche Einschätzung wichtig. Der Gedanke, dass Softwareentwicklung ausschließlich über Kennzahlen gesteuert werden könnte, ist falsch. Daher ist die Qualität von Entscheidungen im Management auch durch einen offenen und ehrlichen Kommunikationsprozess mit den Entwicklungsteams bestimmt. Nur so können nicht bezifferbare Entscheidungsfaktoren kommuniziert werden. Ein Informations- und Reportingsystem muss auch diesem Aspekt Rechnung tragen. Neben den Aufgaben der Projektüberwachung ist das IT-Management insbesondere für die strategische Ausrichtung zuständig. Damit muss das IT-Management auch strategische Fragestellungen entscheiden. Oftmals entstehen diese Fragestellungen aus der Projektarbeit. Daher muss das IT-Management auch über strategisch relevante Fragestellungen informiert werden, um qualifizierte Entscheidungen treffen zu können. Solche Fragestellungen können unter anderem die Technologieauswahl, Make-Or-Buy-Entscheidungen oder Lieferantenauswahl umfassen. Multiprojekt-Management Die meisten agilen Vorgehensweisen empfehlen die Umsetzung von Projekten zu serialisieren und damit ein Team immer nur mit einem Projekt gleichzeitig zu beschäftigen. Diese Überlegung ist in der Betrachtung von einzelnen Teams nachvollziehbar, kann aber nicht auf größere Strukturen übertragen werden. Gerade aus strategischer Sicht ist es für Entwicklungsabteilungen zu riskant, mit mehreren Teams nur ein einziges Projekt umzusetzen. Sollte dieses Projekt aus nicht vorhersehbaren Gründen abgebrochen werden, wäre eine ganze Organisationsstruktur gefährdet. Im Sinne einer gleichmäßigen Auslastung und eines vernünftigen Risikomanagements ist daher in Entwicklungsabteilungen mit mehreren Teams die Umsetzung von mehreren Projekten parallel oft notwendig und sinnvoll. Damit wird in einer Vielzahl von größeren Entwicklungsabteilungen eine Multiprojekt- Umgebung anzutreffen sein. Seite 19

24 Um in agilen Umfeldern und insbesondere im Management nicht nur einzelne Projekte sondern in einem Umfeld mit vielen Projekten arbeiten zu können, kommt auch die Frage nach Realisierbarkeit und Terminprognosen für neue Projekte ins Spiel. Das Management muss ableiten können, wie lange die Entwicklungsabteilungen ausgelastet sind und ab wann neue Projekte möglich sind. Konsequenterweise muss man damit auch die Grundgedanken von agilen Projekten auf die nächste Organisationsebene heben. Wenn sich Anforderungen und Prioritäten in einzelnen Projekten laufend ändern können und diese Veränderungen im Prozess abgebildet und vorgesehen sind, dann ist diese Flexibilität auch von agilem IT-Management zu einzufordern. Damit muss ein agiles IT-Management auch in der Lage sein, Projekte neu zu priorisieren und die Auswirkungen auf die laufende Entwicklung abschätzen zu können. Dadurch kann das IT-Management auch kurzfristig neue Projekte in die laufenden Entwicklungen einschieben und die Konsequenzen für andere Projekte abschätzen. Nachdem dem IT-Management auch die Verantwortung für die mittelfristige Ressourcenund Budgetplanung obliegt, muss das IT-Management auch die mittel- und langfristige Auslastungssituation planen. Damit muss das IT-Management in der Lage sein, die zukünftige Auslastung der Teams abzuschätzen und in Planung befindliche Projekte damit abzugleichen. Nachdem gerade im agilen Umfeld die Unsicherheit über künftige Entwicklung bewusst betrachtet wird, kommt in der künftigen Auslastungsplanung dieser Unsicherheit eine besondere Bedeutung zu. Die Auslastungsplanung muss diese Unsicherheit schon im Planungsprozess mit betrachten. Im Gespräch mit Mitarbeitern aus dem IT-Management wird immer wieder der Wunsch nach einer Ampeldarstellung geäußert, die anzeigt, ob alles in Ordnung ist. Betrachtet man den Hintergrund dieser Anforderung, wird das Bedürfnis der Kontrolle deutlich. Das IT-Management möchte Anzeichen für Planabweichungen möglichst einfach und schnell berichtet wissen. Obwohl ab einer gewissen Führungsebene meist das Verständnis für die konkrete Tätigkeit der Mitarbeiter fehlt, ist es immer wieder ein Bedürfnis zu wissen, woran einzelne Mitarbeiter gerade arbeiten. Auch dieser Wunsch soll durch ein Informationsmodell abgebildet werden. Gerade in größeren Entwicklungsabteilungen, die auch international tätig sind, entsteht der Wunsch nach der Zertifizierung der eigenen Entwicklungsabteilung nach gängigen Industriestandards und Modellen wie ISO9000 oder CMMI. Der Hintergrund dafür ist der Wunsch nach einem einheitlichen Qualitätsmanagement. Für das IT-Management wäre es natürlich wünschenswert, dass die eigenen Informationsmodelle solche Bestrebungen unterstützen. Nicht zuletzt ist für das IT-Management das Projekt-Controlling sowohl laufend als auch post-mortem von großer Bedeutung. Es muss dem IT-Management also möglich sein, die Kosten für Projekte und Projektteile laufend abschätzen und bewerten zu können. Gerade in diesem Bereich tendieren Managementstrukturen oft zu vermeintlich sehr genauen Mechanismen. Oftmals buchen dann Mitarbeiter ihre Arbeitszeit in Minutengenauigkeit Seite 20

25 auf einzelne Projektaufgaben. Im persönlichen Gespräch ist jedem klar, dass diese Aufzeichnungen in der Genauigkeit zum einen nicht richtig sind und zum anderen auch überhaupt keinen Nutzen bringen. In diesen Bereichen muss das Management auch zwischen Scheingenauigkeit und verlässlichen Zahlen unterscheiden lernen. Vernünftige Informationsmodelle sollten besser verlässliche Zahlen liefern als mit Scheingenauigkeit überzeugen zu wollen. Eine ähnliche Problematik der Übergenauigkeit ergibt sich oft auch bei der Ressourcenund Personalplanung. Eine Planung auf Personenebene ist in Entwicklungsumgebungen mit mehreren Teams vermutlich wenig sinnvoll. Insbesondere auch, da in agilen Umgebungen Mitarbeiter ihre volle Arbeitszeit in nur ein Team einbringen sollten. Zahlreiche Statistiken zeigen, dass damit die größte Produktivität zu erwarten ist. Daher sollte auch für das IT-Management eine Planung auf Teamebene völlig ausreichend sein. Will das IT-Management selbst zu einer qualitativ besseren Ressourcenplanung kommen, muss auch der ständigen Tendenz zur Überauslastung von Personen und Teams widerstanden werden. In vielen Unternehmen finden sich Ressourcenplanungen in denen Teams und Personen zu 90%-120% eingeplant sind. Wenn man die üblichen Abwesenheitszeiten und Ausbildungszeiten mit einrechnet, dann wird deutlich, dass das wohl kein Team und keine Person leisten kann. Was bedeutet dann aber eine solche Ressourcenplanung? Damit plant das Management im Grunde genommen nur den Misserfolg. Eine solche Planung ist wertlos und Zeitverschwendung für alle Beteiligten. Erschwerend kommt die völlig falsche Kommunikation auf menschlicher Ebene hinzu. Im Wesentlichen sagt das Management damit nichts anderes, als dass sie bewusst mit der Ausbeutung der eigenen Mitarbeiter über die maximale Arbeitslast plant. Im Grunde genommen muss jeder Organisation, die solche Planungen erstellt, die eigene Moral- und Ethikhaltung überdenken. Solange das IT-Management solche Pläne entwirft, ist auch nicht mit einer erfolgreichen agilen Softwareentwicklung im Unternehmen zu rechnen Informations- und Steuerungsbedürfnis des Kunden Ein wichtiger Grundgedanke in agiler Softwareentwicklung ist die enge und vertrauensvolle Zusammenarbeit mit dem Kunden. Damit ergeben sich für den Kunden sehr ähnliche Fragestellungen wie auch für das Management. Die Kunden eines Softwareprojektes werden sich daher folgende Kernfragen stellen: Wird die Anwendung meine (aktuellen) Anforderungen erfüllen? Werde ich für die bezahlte Leistung einen adäquaten Funktionsumfang erhalten? Wann kann ich die Anwendung nutzbringend einsetzen? Wird die Anwendung meine Qualitätsanforderungen erfüllen? Damit interessiert sich der Kunde ebenfalls für die Daten des magischen Vierecks. Für den Kunden weniger interessant sind strategische Fragestellungen. Seite 21

26 Der Kunde wird allerdings wesentlich größeres Interesse an der Anwendung selbst haben, als das im Management oftmals der Fall ist. Damit wird die laufende Präsentation von Zwischenergebnissen für den Kunden ein wichtiger Bestandteil der ständigen Fortschrittskontrolle sein. In agilen Projekten kann der Kunde auch seine Anforderungen an die aktuellen Bedürfnisse anpassen. Auch vor diesem Hintergrund ist frühes Testen und auch ein früher Einsatz von unschätzbarem Vorteil für den Kunden. So kann er seine Anforderungen am besten erkennen und kann besser abschätzen, wo aktuell Prioritäten zu setzen sind. In zahlreichen Projektumfeldern ist für Kunden auch die frühere Verfügbarkeit von Testfällen und Testergebnissen hilfreich. Sie dienen zur Ausräumung von Missverständnissen. Darüber hinaus kann frühzeitiges Testen des Systems auch zu einem früheren Einsatz der Software führen, da bisher sequenziell durchgeführte Projektphasen zum Teil parallelisiert werden können Informations- und Steuerungsbedürfnis im Projektteam Nachdem sich diese Arbeit mit Fragen des projektübergreifenden Projektmanagements beschäftigt, wird hier auf die projektinternen Informationsbedürfnisse nicht im Detail eingegangen. Wichtig ist hier zu erwähnen, dass jede Unternehmenskultur eine klare Unterscheidung zwischen teaminternen und Unternehmensdaten treffen sollte. In [Grady 1992] wird dieses Prinzip als Conecpt of public and private data beschrieben. Um ein vernünftiges Gesamtbild zu haben, werden hier nur die wichtigsten Kommunikationswege aus dem IT-Management und von Kundenseite dargestellt. Das zentrale Medium zur Kommunikation der offenen Anforderungen im Projekt ist ein hochwertig geführter und richtig priorisierter Backlog. Dieser bildet die wichtigste Grundlage zur Umsetzung neuer Funktionalitäten im Projekt. Für den Projekterfolg in agilen Projekten ist es jedoch besonders wichtig, dass der Backlog nur die Ausgangsbasis für eine offene und direkte Kommunikation zwischen Projektteam und Kunde bzw. Kundenvertreter darstellt. Damit ist der Backlog nicht als einziger Weg der Kommunikation zu verstehen. Vielmehr sind die Einträge im Backlog im Sinne von Scrum als Einladung zum Gespräch zu verstehen. Um dem Team eine Arbeit in gewünschter Qualität zu ermöglichen, muss das Management Qualitätsanforderungen und die übergeordnete IT-Strategie kommunizieren und verständlich machen. Das Team muss diese Anforderungen in die eigene Definition of Done integrieren und als Entscheidungsgrundlage für die unzähligen Entscheidungen in einem Entwicklungsprojekt einbinden. Die Definition of Done dient dem Team als Regelwerk, wann ein Arbeitspaket für das Team als abgeschlossen anzusehen ist. Darin sind etwa Vorgaben über einzuhaltende Regeln, zu erstellende Dokumentation und durchzuführende Tests enthalten. Das laufende Testsystem ist für das Entwicklungsteam ebenfalls von immenser Bedeutung. Es dient dem Team als System, um die geleistete Arbeit darzustellen und mit dem Kunden zu diskutieren. Seite 22

27 Neben den bisher beschriebenen Informationen braucht ein effizientes agiles Team auch Rahmenbedingungen und Zusicherungen von Seiten des Managements, um den agilen Prozess in seiner Stärke leben zu können. Auf diese Rahmenbedingungen wird nachfolgend im Detail eingegangen. Ein agiles Team ist immer als Einheit zu betrachten. Eine Fortschritts- oder Produktivitätsüberwachung auf Einzelbasis ist zu unterlassen, da es die Dynamik eines selbstorganisierten Teams untergraben würde. In fast jedem guten Team sind Teammitglieder integriert, die zwar auf Basis von Statistiken nur wenig Code produzieren, allerdings für die Kommunikation im Team so wichtig sind, dass diese Teammitglieder die Produktivität im Team wesentlich verbessern. Gute agile Teams sollten auch selbst über neue bzw. ausscheidende Teammitglieder entscheiden dürfen. Nachdem es in fast allen Unternehmen die Notwendigkeit von Zeitaufzeichnungen gibt, sollten dies die einzigen personenbezogenen Arbeitsdaten im Projekt sein. Eine Dokumentation der Arbeitszeiten auf Aufgaben- oder Backlog-Ebene bringt aus der Erfahrung des Autors keinerlei Vorteile. Es ist für den agilen Prozess völlig ausreichend, die geleisteten Arbeitsstunden bezogen auf den Sprint zu kennen. Auch [Grady 1992] teilt diese Einschätzung: Don t try to measure individuals. Das Verständnis das Team als Einheit zu betrachten führt auch dazu, dass Einzelpersonen keine Konsequenzen für Fehler in der Arbeit zu befürchten haben. In einem agilen Team muss immer das gesamte Team für Fehler geradestehen und für die Behebung des Problems sorgen. Wie das Team intern mit der Situation umgeht, ist der Selbstorganisation im Team zu überlassen. Schafft ein Unternehmen eine angstfreie Arbeitsumgebung, wird das durch nachhaltige und qualitativ bessere Arbeit der Teams belohnt. Nach [Harrison 2011] liegt die Produktivität von engagiert arbeitenden Teams im Vergleich zu unglücklichen Teams etwa 43% höher. Um Teams ein engagiertes Arbeiten zu ermöglichen, ist neben der angstfreien Umgebung auch die Möglichkeit für eigene Entscheidungen wichtig. Einmal mehr ist daher von großer Bedeutung, ein klares Rahmenwerk an Vorgaben transparent zu kommunizieren und in diesem Rahmenwerk ausreichend Spielraum für eigene Entscheidungen des Teams zu bieten (vgl. auch [Sprenger 2002]). Werden von einem agilen Team nachhaltige und zukunftsorientierte Entscheidungen erwartet, muss das IT-Management eine klare Zieldefinition haben, wie sich das Unternehmen in Zukunft weiter entwickeln will. Es ist also die IT-Strategie, an der sich auch die Entscheidungen der Teams orientieren sollen. Damit schließt sich auch der Kreis von der Strategiedefinition zum Projektteam und die wichtige Bedeutung einer klar kommunizierten IT-Strategie wird sichtbar. Ein zentrales Element von agiler Softwareentwicklung ist die Unterscheidung zwischen Anforderungen, die noch verändert werden können und solchen, an denen das Team ungestört arbeiten kann. Üblicherweise werden am Beginn der Iteration die Arbeitspakete für die aktuelle Iteration ausgewählt und diese werden ohne Störung und Intervention von außen umgesetzt. Dieser Schutz des Teams soll für geordnete Kommunikationswege sorgen und das Team vor laufender Intervention von außen schützen. Interessanterweise ist gerade das einer der schwierigsten Lernprozesse für das Management von agilen Umgebungen. Plötzlich ist es nicht mehr möglich, einzelnen Entwicklern Aufträge für Änderun- Seite 23

28 gen oder neue Arbeitspakete während einer Iteration zuzuteilen. Gerade bei Projektteams in klassischen Vorgehensweisen war das Management daran gewöhnt, Änderungen und Sonderwünsche durch Weisung oftmals direkt an einzelne Teammitglieder weiterzugeben. Eine zentrale Idee von agiler Softwareentwicklung ist die Selbstorganisation von Teams. Durch das hohe Maß an Selbstverantwortung, das ein Team durch Selbstorganisation an sich nimmt, steigt das Engagement und die Selbstverpflichtung gegenüber dem Projekt und dem Unternehmen (engl. Commitment) des Teams für seine Aufgabe. Das bringt auch in hohem Maß involvierte und agierende Teams mit sich. In klassisch hierarchischen und weisungsgebundenen Organisationsstrukturen bedarf es eines hohen Maßes an kultureller Entwicklung auf beiden Seiten. Eine notwendige wenn auch nicht hinreichende Voraussetzung dafür ist die Transparenz im Unternehmen. Nur wenn die Mitarbeiter die Entscheidungen aus dem Management kennen, verstehen und nachvollziehen können, werden diese im Rahmen der eigenständigen Entscheidungen des Teams auch weitergetragen. Nur so kann ein Erreichen der Unternehmensziele durch den Einsatz der Teams unterstützt werden. Will ein Unternehmen eine solche Kultur entwickeln, muss auch die Gesellschaftsstruktur mit in Betracht gezogen werden. In Gesellschaften, die besonders von hierarchischen Strukturen geprägt sind, ist beim Aufbau selbstorganisierter Teams mit zusätzlichen Herausforderungen zu rechnen. Seite 24

29 5. Informationsmodell für Fortschritt und Zielerreichung Auf Basis der Informationen und Einschätzungen der vorgehenden Abschnitte wird in diesem Kapitel ein Modell aufgebaut, wie die notwendigen Informationen strukturiert werden können. Zusätzlich wird beschrieben, über welche Kommunikationswege die Steuerung und Regelung der Projekte und der Teams erfolgen kann Grundlegende Überlegungen In der agilen Softwareentwicklung steht die stetige Schaffung von tatsächlich nutzbaren und für den Kunden Wert bringenden Einzelteilen im Vordergrund. Das können sowohl Verbesserungen in der bestehenden Software, die Schaffung neuer Funktionalitäten, aber auch die Schaffung von zusätzlichen Artefakten mit Kundenwert sein. So kann etwa auch die Erstellung einer Benutzerdokumentation für den Kunden Wert schaffen. Dieser Gedanke soll auch ins Informationsmodell einfließen. Es sollen nur tatsächlich sichtbare, messbare und prüfbare Aspekte in das Modell einfließen. Damit soll das klassische 90%- fertig-problem der Softwareentwicklung gelöst werden. Das 90%-fertig-Problem beschreibt die Tatsache, dass Softwareprojekte dazu tendieren für wesentlich mehr als 10% ihrer Laufzeit zu 90% fertig zu sein. Das Problem rührt daher, dass der Mensch nur sehr schwer abschätzen kann, wie lange er für noch ausstehende Arbeiten benötigen wird. Damit werden bei fast allen Projekten die verbleibenden Aufgaben zum Ende hin unterschätzt. Ein weiteres Grundprinzip für das Informationsmodell beruht auf den Erfahrungen aus Vertrauen führt [Sprenger 2002]. Darin wird davon ausgegangen, dass Führung und Management durch Vertrauen eine gute Möglichkeit darstellen, um das Potenzial von Mitarbeitern zu eigenständiger und selbstverantwortlicher Arbeit voll auszuschöpfen. Der Erfolg von Softwareentwicklung ist durch die Qualität, das Engagement und den Einsatz der beteiligten Mitarbeiter geprägt. Eine Führung der Mitarbeiter in stark weisungsorientierter Art und Weise, wie es insbesondere in Produktionsbereichen verbreitet ist, verspricht in der Softwareentwicklung keinen Erfolg. Nachdem Softwareentwickler im Automatisieren von Prozessen sehr erfahren sind, wird auch der Großteil der routinierten Abläufe innerhalb kurzer Zeit automatisiert, so dass Softwareentwicklung immer eine sehr kreative und durch soziale Interaktion geprägte Disziplin bleiben wird. Daher wird dieses Informationsmodell stark auf den Vertrauensaufbau der beteiligten Gruppen ausgerichtet sein. Aber auch [Sprenger 2002] macht ganz deutlich: Ohne normative Rahmenbedingungen können wir alle nicht leben. Vertrauen ist ohne Kontrolle schlicht nicht zu denken. Kontrolle ist die Bedingung für Vertrauen, die Basis, auf der sich Vertrauen erheben kann. Damit wird der Kontrollierbarkeit bzw. der Transparenz des Informationsmodells eine hohe Bedeutung zukommen. Es ist anzunehmen, dass die Idee Vertrauen als Instrument im IT-Management zu verankern, im ersten Moment vielfach Unbehagen auslösen wird. Betrachtet man die vorliegende Situation allerdings genauer, so bemerkt man, dass dies eigentlich schon jetzt im großen Rahmen insbesondere bei klassischen Vorgehensmodel- Seite 25

30 len - passiert. Allerdings fehlt dort das Mittel der Kontrolle und damit wird Management oft auch zum Blindflug. In einem klassischen Vorgehensmodell werden beispielsweise oftmals Meilensteine ausgerufen. Ein beliebter Meilenstein ist Implementierung abgeschlossen Start des Systemtests. Dabei stellt sich aber die Frage, ob das Management in irgendeiner Weise prüfen kann, ob dieser Meilenstein tatsächlich erreicht wurde? Vermutlich nicht, da ja erst der nachgelagerte Systemtest prüfen wird, ob die Implementierung tatsächlich abgeschlossen ist. In klassischen Vorgehensmodellen musste das Management also immer den nächsten Meilenstein abwarten, um sicher zu sein, dass der vorherige tatsächlich erreicht wurde. Hier wird wieder einmal ein Problem der Scheinsicherheit beim Vorgehen in nicht prüfbaren Meilensteinen sichtbar. Das termingerechte Erreichen eines Meilensteins hat eigentlich keine Aussagekraft für den Projektfortschritt. Daher muss bei der Verwendung von Meilensteinen in agilen Vorgehensweisen darauf geachtet werden, dass diese Meilensteine tatsächlich überprüfbar sind. Ein möglicher Meilenstein in agiler Vorgehensweise wäre daher zum Beispiel die Abnahme des 300. Storypoints. Nachdem Softwareentwicklung wie der Name schon sagt eine Entwicklungsdisziplin ist, ist sie auch immer mit dem Risiko von Entwicklungstätigkeiten verbunden. Auch wenn es immer wieder Bestrebungen zur Softwarefabrik gibt, sind diese wohl nicht mehr als Buzzwords des Marketings. Damit ist das Management von Softwareentwicklung immer vom Umgang mit verschiedenen Risiken geprägt. Es aggregieren sich unsichere Schätzungen, unstabile Anforderungen und der Einsatz neuartiger Technologien zu einem schwer regelbaren Systemkreis mit vielen Risiken, die nur durch geeignetes Risikomanagement behandelt werden können. Nach [Luhmann 1989] ist Vertrauen eine mögliche Lösung für Risikoprobleme. Das bedeutet also, dass das IT-Management beispielsweise das Risiko einer neuen Technologie erkennt, als Maßnahme das Vertrauen auf die Fähigkeiten des eigenen Teams beschließt und durch laufende Kontrolle der Arbeitsergebnisse diese Fähigkeit auch prüfen kann. Damit gibt das IT-Management aber weder das Risiko noch die Verantwortung für diese Entscheidung ab. Das Risiko wird bewusst adressiert und das IT- Management ist in der Verantwortung, durch die Kontrolle der Ergebnisse laufend zu prüfen, ob die eigene Entscheidung richtig war und das Vertrauen in die Leistung des Teams gerechtfertigt ist. Seite 26

31 5.2. Modellvisualisierung Das in Abbildung 7 dargestellte Informationsmodell zeigt die wichtigsten Elemente in der Arbeit mit agilen Projekten. Abbildung 7 - Informationsmodell Im Zentrum steht der Backlog mit den gesammelten Anforderungen und deren Bewertung nach Aufwand und Wert. Zusätzlich wird für jeden Eintrag dokumentiert, ob diese Anforderung bereits umgesetzt wurde oder durch das Team gerade bearbeitet wird. Der Backlog ist das zentrale Element in einem agilen Projekt und kann von allen Beteiligten jederzeit eingesehen werden. Als Grundlage im Projekt dienen die Vorgaben aus dem IT-Management hinsichtlich der IT- Strategie, der Qualitätsanforderungen aus Unternehmenssicht sowie auch für das Projekt im Speziellen. Zu diesen Qualitätsanforderungen zählen auch Anforderungen hinsichtlich Dokumentation, Vorgehensweise und Test. Das Team nutzt diese Grundlage und wird auf Basis dieser Informationen zahlreiche zusätzliche Artefakte erstellen und zusätzliche Informationen generieren. Das Team erstellt auf Basis der Grundlagen und Anforderungen den Quellcode und alle zusätzlich notwendigen und erforderlichen Dokumente. Der aktuelle Stand der Software ist immer auf einem lauffähigen System einsehbar. Es müssen also alle Anforderungen, die im Backlog als erledigt markiert sind, auch im lauffähigen System zum Testen zur Verfügung stehen. Seite 27

32 Damit bilden die Anforderungen im unteren Bereich der Darstellung gemeinsam mit der Projektvision und dem aktuellen Backlog die aktuelle Zieldefinition. Nachdem sich der Backlog laufend verändern kann, wird sich auch die aktuelle Zieldefinition im laufenden Projekt immer mit verändern. Damit ist auch eine Grundvoraussetzung von agiler Softwareentwicklung abgebildet. Eine wichtige Grundlage für das vertrauensvolle Management ist die Möglichkeit zur Kontrolle. Dem IT-Management und dem Kunden steht es jederzeit frei, das laufende System zu prüfen und den Fortschritt der Entwicklung zu kontrollieren. Nachdem viele Aspekte eine System nicht durch einfaches Probieren am Produkt möglich sind, stellt das Team auch alle notwendigen Unterlagen zur Validierung des Systems zur Verfügung. Damit können im Bedarfsfall auch externe Prüfungsstellen oder Auditoren den Fortschritt der Entwicklung prüfen. Das Testsystem bildet gemeinsam mit den zusätzlich erstellten Artefakten den aktuellen Projektfortschritt. Dieser wird durch die Dokumentation der erledigten Einträge im Backlog dokumentiert und ist auf Basis dieser Daten auch darstellbar. Damit ist auch ein wesentlicher Unterschied zur klassischen Messung von Fortschritt gegeben. In klassischen Vorgehensweisen beruhen Fortschrittsmessungen auf der Erreichung von Meilensteinen und der Schätzung noch verbleibender Aufwände. Die Meilensteine sind dabei oft nicht durch messbare Prüfpunkte definiert. Damit ist in klassischen Vorgehensweisen die Fortschrittsmessung auf Schätzungen oder Annahmen aufgebaut, während die Fortschrittsmessung in agilen Projekten durch geschaffenen Wert bzw. tatsächlich umgesetzten Aufgaben gemessen wird. Betrachtet man die Entwicklung von Fortschritt und Zielerreichung über die Zeit hinweg, lässt sich die Produktivität der Entwicklungsteams messen. Auf Basis der Produktivität können dann auch Kostenabschätzungen, Kostencontrolling und Vorausplanung betrieben werden. Die Pfeile in der Abbildung 7 stellen die Einflussmöglichkeiten der beteiligten Personen dar. Der Kunde kann aufgrund der Erfahrungen im laufenden System jederzeit die Anforderungen umreihen oder ändern. Damit wird auch deutlich, dass wesentliche Änderungen in den Projektvoraussetzungen sich nicht im Backlog niederschlagen, sondern in den grundsätzlichen Qualitätsanforderungen. Diese können vom Kunden auch nicht nach Belieben verändert werden. Änderungen an den grundsätzlichen Qualitätsanforderungen sind Gegenstand von Verhandlungen aller Projektbeteiligten. Ein Beispiel für eine solche Qualitätsanforderung ist die Anzahl möglicher User des Systems. Soll diese um den Faktor 10 erhöht werden, ist das sicherlich nicht eine einfache Story im Backlog, sondern eine Änderung der zugrunde liegenden Qualitätsanforderungen. Ebenso darf der Kunde keine Elemente des Backlogs ändern, die bereits fertiggestellt oder in Arbeit sind. Ändert der Kunde bestehende Anforderungen, wird damit grundsätzlich die Schätzung des Teams ungültig und die Anforderung muss neu abgeschätzt werden. Das IT-Management wiederum hat direkten Einfluss auf das Projekt, in dem es die zugrunde liegenden Qualitätsanforderungen oder die IT-Strategie ändert. Beschließt das Unter- Seite 28

33 nehmen etwa eine Realisierung des Projektes als Produkt, das später an weitere Kunden verkauft werden soll, wird das die weitere Entwicklung wesentlich beeinflussen. Das wohl am öftesten eingesetzte Steuerungsinstrument ist das Budget des Projektes, das indirekt natürlich auch die personellen Ressourcen eines Teams definiert. Im Bild nicht dargestellt ist die wesentlichste übergeordnete Steuerungsmöglichkeit des IT-Management das Schaffen und Gestalten von angenehmen, inspirierenden und produktiven Arbeitsumgebungen Vertrauen durch Validierbarkeit Wie bereits in der Einleitung zum Informationsmodell beschrieben, ist Führung durch Vertrauen ein zentraler Grundgedanke des Modells. Nachdem Führung durch Vertrauen erst durch die Möglichkeit zur Kontrolle ermöglicht wird, muss das Informationsmodell Möglichkeiten zur Kontrolle bieten, um langfristigen Vertrauensaufbau zu ermöglichen. Der Grundgedanke ist also, dass das Entwicklungsteam nach bestem Wissen und Gewissen seine Aufgaben ausführt und damit bestmöglich zum Unternehmenserfolg beitragen. Im Rahmen der Sprint Reviews werden die erledigten Einträge aus dem Backlog von Erledigt auf Abgeschlossen gesetzt. Dabei obliegt es dem Product Owner, die Anforderungen aus dem Backlog und auch die Erfüllung der Qualitätsanforderungen zu überprüfen. Erfahrungsgemäß kann auch der Product Owner diese Prüfungen nicht in vollem Umfang durchführen. Damit muss auch er auf die Angaben des Teams vertrauen. Dadurch bestätigt der Product Owner den Projektfortschritt des Teams und liefert damit die wichtigsten Kenndaten zum späteren Reporting. Auf Basis des Projektfortschrittes werden Produktivität und Kostenkennzahlen berechnet und auch die Planung der weiteren Auslastung basiert auf diesen Berechnung. Damit ist eine ordnungsgemäße Darstellung des Fortschrittes von großer Bedeutung. Auch das Management muss die Teams überzeugen, dass eine transparente und ehrliche Darstellung des Fortschrittes wichtig ist. Daher muss auch das Management akzeptieren, wenn Teams keinen Fortschritt vorweisen können und in der persönlichen Kommunikation Ursachen und Lösungswege dafür finden. Um die ehrliche Darstellung des Projektfortschrittes überprüfen zu können, dürfen Elemente des Backlogs erst dann als abgeschlossen gekennzeichnet werden, wenn alle Qualitätsanforderungen erfüllt sind und das Ergebnis auf dem laufenden System zum Testen bereit steht bzw. das geschaffene Artefakt verfügbar ist. Damit kann jeder Projektbeteiligte den Fortschritt jederzeit überprüfen. Es ergibt sich daher die ideale Möglichkeit zur Kontrolle. Es kann jederzeit überprüft werden, ob der dokumentierte Fortschritt auch tatsächlich umgesetzt wurde. Natürlich ist diese Kontrollmöglichkeit insofern begrenzt, dass durch Tests am laufenden System nur ein Teil der Qualitätsanforderungen überprüfbar sind. So wird es durch Tests am laufenden System kaum möglich sein, die Code-Qualität zu überprüfen. Ebenso wenig können typische nichtfunktionale Anforderungen (non-functional requirements) wie Sicherheitsaspekte, Lastverhalten oder Fehlertoleranz durch einfaches Ausprobieren getestet werden. Seite 29

34 Zu diesem Zweck sieht das Modell die Möglichkeit zur Validierung vor. Nach [Balzert 1998] ist Validierung die Prüfung der Eignung und des Wertes der Software hinsichtlich des Einsatzzweckes. Es wird also überprüft, ob das richtige Produkt entwickelt wird. Im Gegensatz zur Verifikation, die nur prüft, ob das Produkt der Spezifikation entspricht. Nachdem im agilen Umfeld der Kundennutzen maximiert werden soll und es bei der Umsetzung von Anforderungen nicht primär um die sture Umsetzung der Spezifikation geht, sondern um die Befriedigung der Kundenbedürfnisse, scheint Validierung in diesem Kontext als zweckmäßig. Es wird auch bewusst nicht von Testen gesprochen, da die entstandenen Artefakte bzw. die Erweiterungen der Software bereits getestet sein müssen, bevor diese als Erledigt markiert werden dürfen. Zusätzlich lehnt sich der Begriff Validierung auch an die Begriffe von gängigen Qualitätsstandards. Insbesondere im medizinischen Bereich wird der Begriff Validierung verwendet (vgl. [IEC ]). Damit soll auch zum Ausdruck kommen, dass auf Basis der vorliegenden Unterlagen auch externe Prüfungsstellen eine Prüfung des Produktes vornehmen können. Damit soll wiederum das eigene Qualitätsbewusstsein im Team gesteigert werden, aber auch das Management hat eine zusätzliche Möglichkeit zur Kontrolle. Durch die Vorbereitung auf mögliche Zertifizierungen können so auch Vorteile eines strukturierten Qualitätsmanagements mit einbezogen werden. Durch diese Sichtbarkeit des Projektfortschrittes bei allen Projektbeteiligten und die Einladung an alle den Fortschritt auch am laufenden System zu testen, wird die Vertrauensbasis gestärkt und ein effiziente Führung durch Vertrauen erst ermöglicht IT-Strategie und Qualitätsanforderungen In agilen Vorgehensweisen ist es üblich, dass sich Teams eine Definition of Done (DoD) zusammenstellen. Das ist eine Checkliste, mit der das Team selbst überprüfen kann, ob alle notwendigen Schritte zum Abschließen eines Backlog-Eintrages erfüllt sind. Die DoD umfasst üblicherweise Einträge wie: - Code implementiert und durch Checkstyle und Findbugs geprüft, - Mindestens 75% Testabdeckung des neuen Codes, - Funktionalität auf Integration ausgerollt und getestet, - Benutzerhandbuch erweitert und korrigiert, - Funktionalität hinsichtlich Lastanforderungen geprüft, - Regressionstestplan ergänzt. Damit umfasst die DoD alle Anforderungen, die über das Projekt hinweg gelten und bei der Umsetzung aller Elemente des Backlogs zu beachten sind. Die DoD muss damit auf das Projekt und auch auf die IT-Strategie abgestimmt sein. Wenn in der IT-Strategie verankert ist, dass alle Tests automatisiert werden sollen, muss das auch in den DoD der Projekte mit betrachtet werden. Es bietet sich also an, für das Unternehmen eine minimale DoD für alle Projekte zu definieren. Theoretisch kann durch den Verzicht auf Qualitätsstandards die Produktivität eines Teams kurzfristig erhöht werden. Im agilen Umfeld bezeichnet man ein solches Vorgehen als Seite 30

35 Aufbau von technischer Schuld (engl. technical dept), da dieser Produktivitätsgewinn später mit übermäßigem Mehraufwand (Zinsen) wieder zu bereinigen ist. Dass der Verzicht auf Qualität langfristig sehr teuer ist, ist in der Software Literatur mehrfach bewiesen (vgl. [Sneed 1987]) dennoch lässt sich diese Erkenntnis nur schwer dem Management erklären. Damit sind diese grundlegenden Anforderungen im Projekt auch ein wichtiges Steuerungselement des IT-Managements, um Einfluss auf die nachhaltige Entwicklung im Projekt zu nehmen Backlog Der Backlog ist das wichtigste Artefakt in einer agilen Softwareentwicklung nach Scrum. Im Backlog werden alle Anforderungen an die Software in Form von User Stories gesammelt. Dabei soll jeder Eintrag eine abgeschlossene Funktionalität beschreiben, die der Benutzer nach der Realisierung sinnvoll einsetzen kann. In der Praxis ist das zwar nicht immer möglich, aber dennoch ist jeder Eintrag im Backlog möglichst danach auszurichten. Durch die Beschreibung im Backlog soll auch das Nutzenpotenzial deutlich werden. Nähere Informationen zur Erstellung von Backlog Elementen finden sich zum Beispiel in [Cohn 2010]. Der Backlog muss immer mit dem Kunden priorisiert sein, wobei die Reihung nach dem Wert für den Kunden absteigend sortiert ist. Es sollen also immer die für den Kunden wertvollsten Anforderungen umgesetzt werden. Gleichzeitig mit der hohen Priorisierung von Elementen müssen diese aber auch so detailliert beschrieben werden, dass eine Abschätzung des Umfangs und spätere Umsetzung möglich ist. Der Kunde kann in Zusammenarbeit mit dem Product Owner den Backlog jederzeit verändern, ergänzen und die Priorisierung ändern. Damit ist der Backlog das wichtigste Werkzeug, um der stetigen Veränderung von Anforderungen Rechnung zu tragen. Elemente des Backlogs, die bereits umgesetzt wurden oder gerade in Arbeit sind, dürfen nicht mehr verändert oder anders gereiht werden. Im Backlog ist also auch immer ersichtlich, welche Elemente im aktuellen Sprint in Arbeit sind und welche Elemente bereits fertiggestellt sind. Um den realisierten Kundennutzen und Methoden des Earned Value Managements (vgl. [Rawsthorne 2010]) anzuwenden, ist eine numerische Bewertung des Kundennutzens (Business Values) sinnvoll. Dabei können gemeinsam mit dem Kunden ähnliche Schätzmethoden angewendet werden, die das agile Team auch selbst nutzt. Das Team schätzt die Elemente des Backlogs hinsichtlich des Aufwands der Umsetzung in einer abstrakten Einheit zumeist Story-Points (SP). Die Idee beruht auf der vergleichenden Schätzung, wonach ein Team sehr gut einschätzen kann, ob 2 Arbeitspakete vergleichbar groß sind bzw. in welchem Verhältnis diese zueinander stehen. Softwareentwickler sind aber meist nicht sehr gut darin, die Zeit abzuschätzen, die sie zur Realisierung einer Aufgabe benötigen. Daher wird auf Basis von Erfahrungen erhoben, wie viele Story-Points ein Team pro Sprint schafft. Damit ergibt sich ein sehr zuverlässiger Umrechnungsfaktor von Story-Points zu Personalaufwand. Seite 31

36 5.6. Ziel- und Fortschritt In einem agilen Projekt lassen sich über den Backlog auf sehr einfache Art und Weise das Projektziel und der Projektfortschritt beschreiben. Das aktuelle Ziel eines Projektes wird durch die Gesamtheit des Backlogs beschrieben. Nachdem in einem agilen Projekt der Backlog stetig in Veränderung ist, wird damit auch das Ziel eines Projektes laufend verändert. Der Begriff Ziel ist in diesem Kontext als Gesamtheit der umzusetzenden Funktionalitäten zu sehen. Das deckt sich keinesfalls mit der Projektvision, die das zu lösende Problem im Groben umschreibt. Weiterhin ist es wichtig zu verstehen, dass ein agiles Projekt nicht erst dann erfolgreich ist, wenn alle Funktionalitäten umgesetzt sind. Ein agiles Projekt ist erfolgreich, wenn der Kunde mit dem Fortschritt zufrieden ist. Daher wird ein agiles Projekt auch dann erfolgreich beendet, wenn die Projektbeteiligten entscheiden, dass die Kosten für weitere Funktionalitäten den Kundennutzen überwiegen. Der aktuelle Fortschritt in einem agilen Projekt wird durch die erledigten Einträge des Backlogs dokumentiert. Werden im Backlog Fortschritte dokumentiert, die im Testsystem nicht nachvollziehbar sind, ist das eine grundlegende Verletzung des agilen Prozesses und muss zu umgehenden Konsequenzen in der Prozessorganisation führen. Im Backlog wird der geschätzte Aufwand für Stories durch Story-Points (SP) dokumentiert. Damit errechnet sich die Produktivität eines agilen Teams durch folgende Formel (Einheiten jeweils in den eckigen Klammern): Produktivität [SP/Sprint] = SP der erledigten Backlogelemente [SP] / Anzahl Sprints [Sprint] Um Prozessveränderungen in der Produktivität einzurechnen, ist es sinnvoll, die Anzahl der betrachteten Sprints zu begrenzen. Auch bedingt durch den Jahreszyklus ist eine Betrachtung für bis zu einem Jahr sinnvoll. Aufbauend auf der Produktivität lassen sich intuitiv auch weitere Kennzahlen berechnen: Umsetzungsdauer für ein Backlogitem [Sprints] = SP des Elements [SP] / Produktivität [SP / Sprint] Restaufwand für das Projekt [Sprints] = SP der offenen Elemente [SP] / Produktivität [SP / Sprint] Zur Darstellung von Ziel- und Fortschritt in agilen Projekten hat sich das Burndown- Diagramm etabliert, das in späteren Abschnitten noch genauer beschrieben wird. Wird vom Kunden bzw. Produktverantwortlichen eine Bewertung des Business Values parallel zu den Story-Points vorgenommen, können Analysen des gewonnenen Kundennutzens durchgeführt werden. Das kann die Projektbeteiligten bei der Beurteilung der weiteren Entwicklungsschritte unterstützen, um den richtigen Zeitpunkt eines erfolgreichen Projektabschlusses zu beurteilen. Für eine genaue Einschätzung des zu erwartenden Fortschrittes sind damit Erfahrungswerte aus dem Team notwendig. Das ist ein weiteres Argument dafür, dass agile Teams langfristig Bestand haben sollten, um die gesammelten Erfahrungen auch langfristig nutzen zu Seite 32

37 können. Liegen keine Erfahrungsdaten vor, muss aus ähnlichen Entwicklungseinheiten abgeschätzt oder schlichtweg geraten werden. Das passiert aber in klassischen Schätzmethoden in vergleichbarer Art und Weise. Daher ist es wichtig, die angenommenen Werte zu dokumentieren und auch ihre Herkunft und ihre Genauigkeit festzustellen Kosten/Budget Die detaillierte Finanzplanung von Projekten ist eine sehr komplexe und vielschichtige Aufgabe. Es ist nicht Ziel dieser Arbeit die Budgetierung und Kostenkontrolle von agilen Projekten im Detail zu betrachten. Dieser Abschnitt konzentriert sich darauf, wie ein agiler Prozess die notwendigen Daten liefern kann, um die Arbeitszeit der Mitarbeiter zu berechnen. In der Softwareentwicklung ist die Arbeitszeit der Mitarbeiter der größte Kostenfaktor. Daher ist es für eine sinnvolle Kostenkontrolle notwendig, die Arbeitszeiten von Mitarbeitern auf die Projekte aufzurechnen. Ebenso müssen die zu erwartenden Kosten für künftige Projekte abgeschätzt werden können. Die Aufzeichnung der Arbeitszeiten von Softwareentwicklern und anderen Projektbeteiligten ist sehr kontrovers. Das Management wünscht sich eine Zuordnung der Arbeitszeiten auf einzelne Arbeitsaufgaben, um genaue Daten zu haben, woran die Mitarbeiter arbeiten, wie hoch die Overheadkosten sind und wo die größten Einsparungspotenziale liegen. Andererseits sehen sich die Projektbeteiligten durchwegs außer Stande, solche Aufzeichnungen im gewünschten Detailgrad auf einfache Art und Weise zu erstellen. Nachdem in agilen Projekten wiederum die Selbstorganisation des Teams im Vordergrund steht und daher auch das Team selbst entscheiden muss, wie es die Arbeitszeit einteilt, fällt das wichtigste Argument für eine detaillierte Zeitaufzeichnung ohnehin weg. Daher sollte nach Meinung des Autors in agilen Projekten auf eine zugeordnete Erfassung der Arbeitszeiten verzichtet werden. Die Aufzeichnung der absolut gearbeiteten Zeiten ist meist sowohl gesetzlich als auch für die Abrechnung ohnehin notwendig. Damit ist aufgezeichnet, wie viel Arbeitszeit respektive welche Kosten in einem bestimmten Zeitraum aufgelaufen sind. Über die Dokumentation im Backlog wird auch ersichtlich, an welchen Projekten und wie viele Story-Points in einem vorgegebenen Zeitraum erledigt worden sind. Damit kann errechnet werden, welche Kosten in einem Projekt entstanden sind. Hat ein Team nach einigen Sprints auch eine einigermaßen gleichmäßige Produktivität erreicht, kann über die fertiggestellten Story-Points und die aufgelaufenen Kosten sehr genau abgeschätzt werden, welche Kosten pro Story-Point zu erwarten sind. Schätzt man nun Projekte schon in einer frühen Phase rudimentär über die zu erwartende Anzahl an User Stories und deren Story-Points ab, lassen sich auch unter Berücksichtigung der ursprünglichen Schätzunsicherheit die zu erwartenden Kosten abschätzen. Seite 33

38 6. Konzept eines Leitstandes 6.1. Metapher des Software-Leitstandes In der Softwareentwicklung ist mittlerweile die Einführung von Software-Cockpits für das Projektmanagement und Controlling verbreitet. Software-Cockpits konzentrieren sich meist auf die Darstellung von Schlüsselkennzahlen zur Performanzmessung (Key Performance Indicators, KPI) in ansprechender Form. Auf der deutschen Seite von Wikipedia wird ein Cockpit so beschrieben: Vom Cockpit aus wird die gesamte Steuerung vorgenommen. Ferner werden hier sämtliche fliegerischen und technischen Prozesse veranlasst und kontrolliert. [Wikipedia 2011a] Würde man diese Vorstellung eines Cockpits auf die Softwareentwicklung übertragen, ergibt sich das beängstigende Bild, das IT-Management die Teams von ihrem Bildschirm aus nur mit Hilfe der Kennzahlen steuern und kontrollieren könnte. Man könnte annehmen, dass das Management mit ihrem Software-Cockpit das Büro gar nicht mehr verlassen muss. Diese Vorstellung entspricht dem agilen Gedanken so wenig, dass der Autor an dieser Stelle die neue Metapher des Software-Leitstandes einführt. Dazu bedienen wir uns wieder der Beschreibung aus Wikipedia und adaptieren den zitierten Text auf die Softwareentwicklung: Ein [Software-]Leitstand ist eine technische Einrichtung ( ), die den Menschen bei der Leitung eines [Softwareentwicklungs-]Prozesses unterstützt. Er ist Teil eines Leitsystems. In diesem Zusammenhang ist Leiten die Gesamtheit aller Maßnahmen, die einen im Sinne festgelegter Ziele erwünschten Ablauf eines [Softwareentwicklungs- ]Prozesses bewirken (DIN 19222). Die Maßnahmen werden vorwiegend unter Mitwirkung des Menschen aufgrund der aus dem Prozess oder aus der Umgebung erhaltenen Daten mit Hilfe der Leiteinrichtung getroffen. Sollwerte, Sollzustände oder Gütekriterien können hierbei Ziele sein. Ein Leitstand verfügt daher über ein oder mehrere Geräte oder Verbindungen zu Geräten zum Messen, Regeln, Steuern, Anzeigen, Alarmieren, Registrieren, Schalten oder Rechnen. [Wikipedia 2011b] Der Software-Leitstand soll also das Management in seinen Entscheidungen unterstützen. Keinesfalls kann vom Leitstand aus alles gesteuert, geregelt und korrigiert werden. Insbesondere bei großen Abweichungen von der Norm ist die Zusammenarbeit des Leitstandes mit den qualifizierten Mitarbeitern notwendig und erst durch die kreative Lösung der auftauchenden Probleme kann das Gesamtsystem optimiert und verbessert werden. Insbesondere zeigt die Idee des Leitstandes auch, dass Prozessverbesserungen nicht einfach im Normalbetrieb passieren, sondern durch die Zusammenarbeit der beteiligten Personen entwickelt werden. Das Ziel ist also, dem IT-Management einen Leitstand für die Entwicklungsabteilung zur Verfügung zu stellen, der ihnen Daten aus der laufenden Entwicklung aufbereitet und Seite 34

39 wichtige Entscheidungsgrundlagen liefert. Gleichzeitig soll der Leitstand zur Kommunikation und zur kreativen Bewältigung aktueller Probleme und zur nachhaltigen Prozessverbesserung einladen Grundlegende Überlegungen Bei der Konzeption des Software-Leitstandes werden wie schon beim Informationsmodell selbst wieder einige Grundüberlegungen angestellt, die in die Konzeption mit einfließen werden. Die Mehrzahl dieser Überlegungen stammt aus einem Experteninterview [Larndorfer 2010]. Besondere Bedeutung kommt der Vermeidung von dysfunktionalen Effekten zu. Dysfunktionale Effekte treten auf, wenn versucht wird, erfasste Messdaten zu optimieren, ohne das System selbst zu verbessern (vgl. [Austin 1996]). Eine gute Illustration des Problems findet sich in [Larndorfer/Ramler/Buchwiser 2009]. Um dysfunktionale Effekte zu vermeiden, sollen nur Primärdaten gemessen werden, die tatsächlich im Prozess entstehen und direkten und unmittelbaren Zusammenhang zur gewünschten Information stehen. So wird Projektfortschritt im agilen Umfeld ausschließlich durch die Anzahl der fertiggestellten Elemente aus dem Backlog gemessen. Da Elemente nur in Zusammenarbeit mit dem Kunden bzw. einem Kundenvertreter abgenommen werden, kann das Team nicht durch Täuschung einen Fortschritt vorspielen. Nach [Goldberg/Rubin 1995] muss eine gute Messgröße wohl definiert sein. Das bedeutet empirisch gemessen, entsprechend der Intuition der beteiligten Personen und abgebildet auf ein passendes Zahlensystem. Wenn also die Projektbeteiligten eine Kennzahl unterschiedlich interpretieren, ist das ein deutlicher Hinweis auf eine nicht brauchbare Messgröße. Auch die Aggregation von Kennzahlen insbesondere durch individuelle Bewertungsformeln ist mit großer Sorgfalt vorzunehmen. Durch den Einsatz von Aggregatfunktionen und die Wahl der Gewichtungen kann beinahe jede beliebige Aussage erzeugt werden. Daher sind auch klassische Ampel-Aggregationen nur in Einzelfällen wirklich brauchbar. Ein interessantes Beispiel für eine gleich mehrfach falsche Messdatenerhebung findet sich In [Goldberg/Rubin 1995]. Dort wird eine Anekdote von fehlgeleitetem Projektcontrolling erzählt, bei der auf Basis von der Anzahl von Klassen der Fortschritt und die Größe des Systems beurteilt wurden. Der erste Fehler liegt schon darin, dass die Anzahl an Klassen sicherlich keinen direkten Zusammenhang mit dem Projektfortschritt hat. Des Weiteren fördert es dysfunktionale Effekte, da das Team, um Fortschritt vorzutäuschen, bloß viele neue Klassen generieren muss. Das kann über einfache Refactorings in Entwicklungsumgebungen im Minutentakt geschehen. Um einen Software-Leitstand auch sinnvoll aktuell halten zu können, müssen die Messwerte im Prozess entstehen. Müssen Messwerte von Mitarbeitern manuell erfasst oder gesammelt werden, nur um den Leitstand zu bedienen, wird dieser dazu neigen, mangelhaft gepflegt, nicht aktuell und damit wertlos zu sein. Seite 35

40 Nachdem im agilen Umfeld und in dem hier beschriebenen Informationsmodell das gegenseitige Vertrauen und der respektvolle Umgang miteinander wichtig ist, müssen auch im Software-Leitstand die Informationen transparent und nachvollziehbar zur Verfügung stellen. Den beteiligten Personen muss klar sein, welche Daten gesammelt werden und wozu diese eingesetzt werden. Der Leitstand muss eine Einladung zur Kommunikation über positive Entwicklungen und Verbesserungspotenziale sein. Nicht zuletzt müssen auch alle gesetzlichen Bestimmungen zum Datenschutz eingehalten werden hier können insbesondere Betriebsvereinbarungen und Kollektivverträge wirksam werden. Es ist darauf zu achten, dass die Kennzahlen aus dem Entwicklungsprozess in einer für Planungs- und mittelfristige Steuerungsaufgaben geeigneten Aggregation zur Verfügung gestellt werden. Für Managementpositionen außerhalb des Projektteams darf die kurzfristige Variabilität einzelner Kennzahlen kein Auslöser für übereifrige Steuerungsmaßnahmen sein. Die Steuerung der Produktivität innerhalb einzelner Iterationen bzw. von einer zur nächsten ist keine Frage der Führung, sondern eine Frage der Projektdurchführung, die im Bereich der Selbstverantwortlichkeit des Teams liegt. Diesen Ansatz unterstützt indirekt auch [Mayr 2005], der die Durchführung des Projektes als Aufgabe der Entwicklung sieht und nur die Planung und Überprüfung auf Gesamtprojektsicht beim Management ansiedelt. Erst wenn ungünstige Entwicklungen über mehrere Iterationen hinweg sichtbar sind, sollte das IT-Management über Maßnahmen nachdenken und beraten. Führung im Allgemeinen und agile Führung im Speziellen baut immer auf die Kommunikation der beteiligten Personen auf. Miteinander über aktuelle Projektsituationen zu kommunizieren muss ohnehin in den Alltag verwoben sein. Bei der Erstellung von Werkzeugen und der Abbildung von Informationsmodellen wird immer auch eine Sprache in der Unternehmenskultur gepflegt. Nachdem die Sprache auch Mutter des Gedankens ist, muss in einem Software-Leitstand auch bewusst auf die Sprach- und Begriffswahl geachtet werden. Der Software-Leitstand soll im Gesamteindruck die Ideen von agiler Softwareentwicklung und vertrauensvoller Führung unterstützen. In [Grady 1992] wird die Thematik so zusammengefasst: Apply your best management sensitivity to the interpretation and use of software metrics data. Seite 36

41 6.3. Datenmodell für einen Leitstand Nachdem ein Software-Leitstand viele Daten aus dem Projektalltag visualisiert, muss vorab geklärt werden, auf welchem Datenmodell der Leitstand aufsetzten soll und woher diese Daten stammen. Nachdem die Unternehmen verschieden organisiert sind, wird sich auch das Datenmodell eines Leitstandes nur schwer vereinheitlichen lassen. Die Hersteller von Projektmanagement-Werkzeugen tragen dem auch großteils Rechnung, indem die Datenmodelle von Administratoren anpassbar sind. Für die weitere Betrachtung in dieser Arbeit wird das Datenmodell aus Abbildung 8 verwendet, das in dieser Form auch von gebräuchlichen Werkzeugen in der Softwareentwicklung eingesetzt wird. Abbildung 8 - Datenmodell für den Leitstand Das Modell zeigt, dass Projekte in Initiativen (oftmals auch Programme genannt) gesammelt werden. Eine Initiative ist also ein weitreichendes Vorhaben, das zur besseren Umsetzbarkeit in mehrere Projekte aufgeteilt wird. In den Projekten können dann Epics mit umsetzbarem Nutzerwert definiert werden, die dann durch Stories in für einzelne Teams umsetzbare Arbeitspakete geteilt werden. Ein Item im Backlog kann aber auch ein gefundener Fehler (Defect) sein. In Multiprojekt-Umgebungen ergibt sich oftmals eine Form von Matrixorganisation. Die Backlog Elemente werden im Zuge von Projekten aus der Ablauforganisation umgesetzt. Die Umsetzung selbst muss aber in Produkte integriert werden, die wesentlich langlebiger als einzelne Projekte sind. Um klar aufzuzeigen, in welchem Teil der Software eine Story umzusetzen ist, wird diese einer Komponente und damit einem Produkt zugeordnet. Backlog Items werden schon vor der Umsetzung von einem Team geschätzt und später in einem Sprint umgesetzt. Abhängig vom Zeitpunkt der Umsetzung wird das Backlog Item dann in einer Version bzw. Release des Produktes an den Kunden geliefert. Mit einem solchen Datenmodell lassen sich die wichtigsten Fragen für das Projektcontrolling beantworten. Insbesondere lässt sich beantworten, wie viel Seite 37

42 Funktionalität eines Projektes zu welchem Zeitpunkt von wem fertiggestellt wurde und welche Arbeiten noch offen sind. Das dargestellte Modell für das Projektmanagement erhebt weder den Anspruch auf Vollständigkeit, noch wird es in dieser Form universell einsetzbar sein. So ist in diesem Modell etwa die Verbindung zum Testmanagement und zur Dokumentation nicht dargestellt. Für ein Unternehmen, das mehrere Projekte parallel betreibt, ist es aber wichtig, eine gemeinsame Sprache für diese Begriffe zu finden, sodass etwa Prozessbeschreibungen für die Vorgehensweise in Projekten einheitlich verstanden werden und Reports und Kennzahlen einheitlich aggregiert werden können. Insbesondere die Begriffe Anwendung, Programm, Projekt und Komponente, Story oder Issue werden immer wieder unterschiedlich eingesetzt. Gerade für einen Leitstand des IT- Managements sind die Aggregationsmöglichkeiten wichtig, um sinnvoll einen Überblick zu erhalten. Daher sollte die Software für einen Leitstand hier auch flexible Konfigurationsmöglichkeiten bieten Gesamtkonzept des Leitstandes Wie schon weiter oben angedeutet, soll der Leitstand ein Informationssystem sein, in dem alle Beteiligten zur Zusammenarbeit und Kommunikation eingeladen sind. Dazu eignen sich insbesondere kollaborative IT Werkzeuge wie etwa WIKI Systeme. Zusätzlich muss das System aber auch die Einbindung verschiedener Elemente ähnlich wie in einem Portal unterstützen, um verschiedene Informationsquellen flexibel anbinden zu können. Nachdem wohl kein Hersteller alle möglichen Informationsquellen anbinden kann, muss auch eine Eigenentwicklung für Elemente des Portals möglich sein. Als Kandidaten für einen Software-Leitstand kommen damit insbesondere Implementierungen des JAVA Portal Standards in Frage (vgl. [JSR ]). Ein anderes, sehr weit verbreitetes Werkzeug ist [Confluence 2011], eine WIKI Implementierung der Firma Atlassian, mit dem sich die hier beschriebenen Ideen vermutlich auch sinnvoll umsetzen lassen. Abbildung 9 zeigt einen Vorschlag für die Gestaltung des Software-Leitstandes. Dabei ist die Anordnung der Elemente stark an das Informationsmodell aus Abschnitt 5.2 angelehnt. Dabei wurde aber die mittlere Spalte konzeptionell umgedreht und die IT-Strategie als zentrales Leitmotiv in den Mittelpunkt gerückt. In der linken Spalte finden sich die Elemente, die die konkrete Arbeit der Teams spiegeln. Im mittleren Bereich finden sich die Vorgaben des Managements und die Anforderungen des Kunden. Im rechten Bereich sind die Informationen gesammelt, die über die aktuelle Arbeit hinausgehen und mehr Vorschau und Planungscharakter haben. In weiterer Folge wird jedes einzelne Element näher beschrieben. Seite 38

43 Abbildung 9 - MockUp des Leitstandes Seite 39

44 Wie schon bei der Einführung des Datenmodells beschrieben, ist für die Darstellung der Daten eine Aggregation notwendig. Nachdem die Benutzer des Leitstandes unterschiedliche Informationsbedürfnisse haben, soll auch die verwendete Aggregation auswählbar sein. Kunden sollen zum Beispiel nur die eigenen Projekte einsehen können. Teammitglieder wollen abhängig von der aktuellen Situation entweder nur die Daten des eigenen Teams oder bestimmter Projekte sehen. Das IT-Management wird zumeist die Gesamtdaten einsehen, um einen umfassenden Überblick über die aktuelle Situation zu erhalten. Um eine gute Benutzbarkeit des Leitstandes zu erhalten, sollte die Auswahl des aktuellen Informationskontextes vereinheitlicht sein. Als mögliche Aggregationsstufen bieten sich Teams, Projekte, Anwendungen oder Organisationseinheiten an. Bei der Aggregation von Daten ist besonders auf die Vergleichbarkeit von Daten zu achten. Zum Beispiel ist die Produktivität von Teams in der Einheit Story-Points pro Sprint nicht sinnvoll über Teams hinweg zu aggregieren. Entscheidend für den Erfolg eines Leitstandes ist die Transparenz für alle Mitarbeiter. Daher muss der Leitstand für alle Mitarbeiter frei zugänglich sein. Die Mitarbeiter sollen eingeladen sein, die Erkenntnisse zu kommentieren und diskutieren. Daher soll der Leitstand auch gängige Mechanismen aus den sozialen Medien mit einbinden. Dazu zählen Diskussions- und Kommentarmöglichkeiten, aber auch die Verbindung mit RSS-Feeds, um einfach auf dem Laufenden zu bleiben. Der Trend zur stärkeren Einbindung von kollaborativen Kommunikationstechnologien ist auch in der neuen Entwicklungsplattform [Jazz 2011] von IBM sichtbar. Dem IT-Management muss aber auch klar sein, dass der Umgang mit Techniken aus sozialen Medien kein rein technisches Problem ist. Ohne die Bereitschaft, solche Diskussionen zu führen und die Mitarbeiter mit ihren Bedürfnissen und Meinungen ernst zu nehmen, können solche Werkzeuge sogar kontraproduktive Effekte haben. Um den kollaborativen Gedanken noch weiter zu stärken, soll der Leitstand kein reines Reporting-Werkzeug sein. Zu jeder Grafik bzw. zu allen Elementen sollen auch direkt die notwendigen Werkzeuge und Informationen verlinkt sein, um sinnvoll weitere Arbeitsprozesse einzuleiten. Das Grundkonzept eines Elements ist in Abbildung 10 skizziert. So soll zum Beispiel auf der Grafik für offene Fehler auch direkt in das Issue Tracking verlinkt werden, um dort die Fehler näher zu analysieren aber auch um jederzeit neue Issues anlegen zu können. Für jedes Element im Leitstand müssen auch Informationen hinterlegt sein, wie die Zahlen zu lesen und zu interpretieren sind und wodurch Abweichungen bedingt sein können. Abbildung 10 - Konzept eines einzelnen Elements Seite 40

45 Insbesondere für die Interpretation und Diskussion von Grafiken ist ein weiteres Werkzeug sinnvoll, das so auch in Google Analytics [Google Analytics 2011] implementiert ist. Dabei können auf den Grafiken Markierungspunkte gesetzt und kommentiert werden. So können besondere Ereignisse in den Grafiken gekennzeichnet und Missinterpretationen vermieden werden. Die Umsetzung in Google Analytics ist in Abbildung 11 dargestellt. Abbildung 11 - Kommentarfunktion in Google Analytics Wie bereits mehrfach angesprochen ist die Umsetzung agiler Softwareentwicklung auch eng mit der IT-Strategie der Organisationseinheit verbunden. Damit muss der Leitstand den engen Zusammenhang darstellen und kann damit die Kommunikation der IT-Strategie unterstützen. Wenn eine IT-Strategie bereits vorliegt und zum Beispiel in einer externen Dokumentation beschrieben ist, empfiehlt sich eine enge Verzahnung des Leitstandes mit der IT-Strategie Dokumentation. Besser noch ist es, die IT-Strategie und deren Dokumentation in einer Einheit mit dem Leitstand zu betrachten. Damit wird der Leitstand zum Teil der IT-Strategie und kann in einem gemeinsamen Werkzeug abgebildet und einheitlich kommuniziert werden. Die Idee eines IT-Strategieportals wurde vom Autor bereits im Rahmen einer Seminararbeit [Schmelzer 2010] beschrieben. Seite 41

46 6.5. Elemente des Software-Leitstandes Nachdem sich der Software-Leitstand wie ein Portal aus einzelnen Elementen zusammensetzen kann, wird in weiterer Folge eine Auswahl möglicher Elemente beschrieben. In Portalen werden diese Elemente oft auch Widgets genannt. Daher wird dieser Begriff auch hier eingesetzt. Natürlich sollte auch die Auswahl der Widgets an die Bedürfnisse und die Situation im Unternehmen angepasst werden IT-Strategie Nachdem eine klare Kommunikation der strategischen IT-Ausrichtung in vielen Unternehmen unterschätzt wird, soll die IT-Strategie auch im Leitstand kommuniziert werden. Eine mögliche Darstellungsform zeigt Abbildung 12. In einer guten IT-Strategie findet sich auch ein prägnantes Leitmotiv oft auch unterstützt von einem Piktogramm oder Logo. Das Leitmotiv sollte sich auch als Element im Leitstand finden und von dort aus mit der ausführlichen Strategiedokumentation verlinkt sein. Damit kann eine höhere Identifikation aller Mitarbeiter mit der IT-Strategie erreicht werden. Abbildung 12 - Element IT-Strategie Qualitätsanforderungen Durch das Widget Qualitätsanforderungen sollen die wichtigsten Richtlinien und Vorgaben zum Qualitätsmanagement und dafür notwendige Werkzeuge kommuniziert werden. Es wird natürlich sehr stark vom konkreten Projekt bzw. vom konkreten Umfeld abhängen, welche Vorgaben das sind. In diesem Element können zum Beispiel Verweise auf die einzuhaltenden Normen hinterlegt sein. Sinnvoll ist auch die Einbindung automatisierter Werkzeuge zur Kontrolle der Qualitätsanforderungen. Gerade Werkzeuge, die den Quellcode und die Softwarearchitektur gegen vorgegebene Richtlinien prüfen, sind mittlerweile weit verbreitet und effektiv einsetzbar. Für weitere Informationen zum Qualitätsmanagement wird auf [Pfeifer 2001] verwiesen. Seite 42

47 6.5.3 Backlog Der Backlog kann im Leitstand nur in stark vereinfachter Form dargestellt werden (siehe Abbildung 13). Abhängig vom gewählten Kontext werden die aktuellsten Elemente angezeigt. Wichtiger ist die direkte Verlinkung in das Softwarewerkzeug für das Backlog- Management. Auch dort sollte der Kontext aus dem Leitstand direkt übernommen werden. Abbildung 13 - Element Backlog Es soll im Leitstand nur ein schneller Überblick über die aktuell anstehenden Themen und die derzeit laufenden Arbeiten gegeben werden. Damit wird ein wichtiges Informationsbedürfnis des IT-Managements abgedeckt Burndown-Diagramm Einen besseren Überblick als der Backlog gibt das Burndown-Diagramm wie in Abbildung 14 dargestellt. Das Burndown-Diagramm ist eine weit verbreitete Darstellung der offenen Funktionalitäten im Verhältnis zur bereits fertiggestellten Funktionalität SP erledigt SP offen Abbildung 14 Element Burndown-Diagramm In Abbildung 14 zeigt die obere Linie die Summe aller Story-Points der Backlogeinträge, die aktuell durch die Kontextauswahl ausgewählt sind. Der Name Burndown kommt von der unteren Linie, die nur die offenen Aufwände aufzeigt und damit im Zeitverlauf konstant Seite 43

48 abfallend sein sollte. Damit stellt die obere Linie das aktuelle Gesamtziel des Projektes dar. Steigt die obere Linie an, wünscht sich der Kunde laufend mehr Funktionalität. Die Fläche zwischen den Linien zeigt den Fortschritt im Projekt auf. In einem gut eingespielten agilen Team sollte die untere Linie immer konstant linear abfallen. Durch eine konstante Produktivität kann eine lineare Abwicklung der offenen Story-Points erreicht werden. Der Burndown ist die wichtigste Darstellung von Ziel und Fortschritt in einem agilen Projekt. Auf Basis des Burndowns lässt sich ableiten, ob der agile Prozess stabil funktioniert, wie sich die Kundenwünsche entwickeln und es kann die voraussichtliche Projektdauer abgeschätzt werden. Auch hier ist wiederum entscheidend, dass die gute Planbarkeit im Vordergrund stehen muss. Ein gutes agiles Vorgehen besticht durch Stabilität im Prozess und führt damit zu gleichmäßigen und vorhersehbaren Fortschritt und damit auch zu gleichmäßigen Burndown-Diagrammen Ergebnisse / Systeme Im Element für die Ergebnisse sollen alle Artefakte verlinkt werden, die im Rahmen der Entwicklung entstehen. Das können zum Beispiel direkte Links auf die Systeme sein, oder wiederum Verlinkungen zu WIKI-Seiten, wo diese gesammelt werden. Um auch auf den ersten Blick, die Verfügbarkeit des Testsystems prüfen zu können, ist es sinnvoll, dass der Systemzustand durch eine einfache Ampeldarstellung zusammengefasst wird. In Abbildung 15 ist eine mögliche Umsetzung dargestellt. Es ist darauf zu achten, dass jeder Projektbeteiligte auch einfach Zugriff auf die Systeme hat. Das Hauptziel dieser Verlinkung ist eine hohe Integration der Anwender und die Schaffung der Kontrollmöglichkeit für Kunden und Management. Die stetige Lieferung nutzbarer Software bzw. nutzbarer Artefakte ist ein wichtiges Grundprinzip von agiler Softwareentwicklung. Ist ein Team nicht in der Lage ein nutzbares System oder wertvolle Artefakte bereitzustellen, ist der agile Prozess in großer Gefahr. Sind also die verlinkten Produkte nicht nutzbar, erfordert das auf jeden Fall die Reaktion des Teams bzw. auch des IT-Managements. Daher ist auch eine direkte Möglichkeit zur Kontaktaufnahme in diesem Element wichtig. Abbildung 15 - Element Ergebnisse Seite 44

49 6.5.6 Build- und Testergebnisse Um agile Techniken effektiv einzusetzen, wird in der Softwareentwicklung die Methode Kontinuierliche Integration (engl. Continuous integration, CI) eingesetzt. Dabei wird der entwickelte Code möglichst häufig idealerweise nach jeder Änderung compiliert und die Software vollständig gebaut. Dabei werden auch alle automatisierten Tests durchgeführt und ausgewertet. Die Build- und Testergebnisse also die Resultate der kontinuierlichen Integration bilden die Lebensader eines agilen Teams. Nur wenn die Software laufend in auslieferbarer Qualität vorliegt, kann agiles Vorgehen sinnvoll umgesetzt werden. Nachdem in jeder Definition of Done die Verwendbarkeit des neuen Inkrements enthalten sein soll, können Elemente des Backlogs auch nur nach erfolgter Integration als erledigt markiert werden. Damit blockiert eine nicht funktionierende CI das gesamte Team und die Probleme bzw. Fehler müssen mit höchster Priorität beseitigt werden. Abbildung 16 - Element Build-/Testergebnisse In einem agilen Projekt müssen Build und Tests immer erfolgreich ausführbar sein. Eine Abweichung davon ist (fast) immer ein Anzeichen für Fehler im System oder ein Zeichen für die falsche Anwendung von Entwicklungstechniken. Daher soll der Software-Leitstand den aktuellen Zustand der CI immer anzeigen (siehe Abbildung 16). Zusätzlich soll das CI System so konfiguriert sein, dass die Teammitglieder unmittelbar über das aktuelle Problem informiert werden. Die Zustandsanzeige im Leitstand soll direkt mit dem CI System verbunden sein, um unmittelbar mit der Ursachenanalyse des Fehlers beginnen zu können Offene Defekte Die offenen Defekte (Defects) sind in einem Projekt ein wichtiges Qualitätsmerkmal. Als Defekt wird jeder Fehler bezeichnet, den der Kunde oder ein anderer Projektbeteiligter in Funktionalitäten findet, die durch bereits abgeschlossene User Stories umgesetzt wurden. In der agilen Softwareentwicklung ist das Ziel, Software zu produzieren, die vom Benutzer jederzeit ohne Probleme verwendet werden kann. Damit zeigen Defekte auch immer Schwächen im Entwicklungsprozess auf. Es wird in agilen Prozessen empfohlen, dass Defekte sofort behoben werden und die laufende Entwicklung unterbrochen wird. In der Praxis ist das so nicht durchführbar und es wird immer eine Triage geben, die die Dringlichkeit von Problemen einstuft. Seite 45

50 Auf jeden Fall ist es Ziel, die Anzahl der Defekte so gering wie möglich zu halten. Daher eignet sich auch die Darstellung im typisch agilen Burndown-Diagramm wie in Abbildung 17. Dabei werden die Anzahl der offenen Defekte und die Anzahl aller Defekte im Laufe der Zeit dargestellt. Idealerweise soll die Anzahl der offenen Defekte immer niedrig bleiben. Daher auch der Name Burndown-Diagramm Abgesch. Defekte Offene Defekte Abbildung 17 Element Defekt Burndown-Diagramm Diese Metrik ist besonders gefährdet für dysfunktionale Effekte, da diese Metrik die Gefahr birgt, dass Probleme nicht mehr ehrlich dokumentiert werden, um die Kennzahl nicht ungünstig zu beeinflussen. Dem muss durch klare Kommunikation und einen einfachen Prozess der Defekt-Meldung entgegengewirkt werden. Im Element soll direkt die Möglichkeit zum Anlegen neuer Defekte ermöglicht werden damit wird klar kommuniziert, dass das gewünscht ist und zu keinen negativen Sanktionen führt. Zusätzlich ist auf die positive Darstellung von günstigen Entwicklungen zu achten. Diese können nur schwer automatisiert werden, da sie von Unternehmenskultur und Kreativität abhängig sind. Einige Beispiele sind: - ein Dank , dass erstmals weniger als 100 Defekte offen sind, - eine freundliche Sonne, solange sich das Chart positiv entwickelt, - Regen und Gewitterwolken bei ungünstiger Entwicklung, - die Keine-Defekte-Pizza immer wenn keine offenen Defekte bekannt sind, wird vom Management Pizza spendiert. Auch wenn diese Maßnahmen ungewöhnlich erscheinen, ist es doch so, dass Softwareentwicklung in sozialen Gruppen passieren. In sozialen Gruppen sind solche Maßnahmen richtig eingesetzt und passend gestaltet eine wichtige Grundlage für guten Teamzusammenhalt und positive Einstellung zur Arbeit und zum Team. Seite 46

51 6.5.8 Vogelperspektive Eine typische Ampeldarstellung durch die Definition von Schwellwerten für bestimmte Messgrößen lässt sich im agilen Umfeld nur schwer realisieren. Insbesondere ist die Aggregation von Messwerten hierbei mit großer Sorgfalt einzusetzen. Im agilen Umfeld sieht man oft ein binäres System zur Anzeige von Zuständen. So ist etwa ein Backlog-Eintrag fertig, oder er ist es nicht. Es gibt keinen 80%-Fortschritt für einen Eintrag im Backlog. Überträgt man diese Idee auf die Ampeldarstellung, so kann die Ampel nur rot oder grün sein. Es wird damit gewisse Ereignisse oder Eigenschaften geben, die eine Ampel auf Rot setzten und die ein eindeutiges Signal darstellen, dass im laufenden Prozess etwas nicht in Ordnung ist. Um diesem Unterschied zu üblichen Ampeldarstellungen auszudrücken, wird der Begriff Vogelperspektive verwendet. Damit kommt die unpräzise Darstellung auch im Namen gut zum Ausdruck. Das Element soll wie in Abbildung 18 den Zustand grafisch darstellen und auch das auslösende Ereignis angeben. Abbildung 18 - Element Vogelperspektive Folgende Beispiele könnte die Vogelperspektive durch eine Warnung darstellen: Der Build ist länger als 2 Tage nicht erfolgreich. Eines der Testsysteme läuft nicht. Die Produktivität ist um mehr als 50% gefallen. Backlog Items wurden nicht regelkonform geändert. Ein Projektbeteiligter hat eine Eskalation ausgelöst. Ein Sprint wird abgebrochen. Ein kritischer Fehler ist aufgetreten und noch nicht behoben. Wichtig ist wiederum das agile Verständnis, dass entweder alles in Ordnung ist oder eben nicht. Die erste kritische Situation löst auch eine Warnung in der Anzeige aus. Es gibt keine Berechnungsregeln, die etwa erst ab 5 kritischen Fehlern oder ähnliches reagieren. Jedes Problem muss ernst genommen und behoben werden. Seite 47

52 Produktivität / Sprint (%) Produktivität Die Darstellung der Produktivität von Teams ist eine der sensibelsten Aufgaben im Projektmanagement. Die Messung von Produktivität ist schwierig, da es nur wenige hochwertige Kenngrößen für nachhaltigen und qualitativ hochwertigen Fortschritt in einem Projekt gibt. Agile Vorgehensweisen adressieren dieses Problem durch die eindeutige Definition, wann ein Backlog-Eintrag als erledigt markiert werden darf. Nachdem die Größe von Backlog-Einträgen aber in der für jedes Team spezifischen Einheit Story-Points abgemessen wird, ist die Produktivität von Teams in absoluten Zahlen nicht vergleichbar. Eine zusätzliche Gefahr bei der Messung von Produktivität ist der starke Einfluss von dysfunktionalen Effekten. Will man etwa ein Team dazu bringen, die Produktivität in Story- Points / Sprint zu verdoppeln, wird das Team wohl sehr schnell beginnen, die Stories einfach mit mehr Punkten abzuschätzen und schon steigt anscheinend die Produktivität. Kombiniert man diese Überlegungen mit dem Grundgedanken aus [Grady 1992], dass Prozessverbesserung als begleitende Maßnahme zu verstehen ist, aber nicht Aufgabe des Projektmanagements einzelner Projekte ist, kann man Produktivität auch unter einem anderen Licht sehen. Für eine nachhaltige Softwareentwicklung, die gut planbar ist, ist vor allem eine konstante und vorhersehbare Produktivität wichtig. Agile Softwareentwicklung versucht durch stetige Qualitäts- und Fortschrittskontrolle eine vorhersehbare und konstante Produktivität zu sichern. Damit ist die konstante Produktivität ein wichtigeres Qualitätsmerkmal als die absolute Kennzahl selbst. Nachdem aber Schwankungen bis zu 25% von Sprint zu Sprint üblich sind, muss eine Form von Sliding Window Messung etabliert werden, bei der der Durchschnitt der letzten 3-6 Iterationen als Maßstab herangezogen wird. Daher bietet sich für das Management die Darstellung der Produktivität gemäß Abbildung 19 an. Dabei wird der langfristige Durchschnitt mit 100% dargestellt. Der Durschnitt der letzten 3-6 Iterationen wird als Linie dargestellt und die einzelnen Sprintergebnisse als Fehlerbalken Sprint Abbildung 19 - Element Produktivität Der langfristige Durchschnitt eine wichtige Kenngröße für die Kostenberechnung und Planung. Daher wird er dort auch als absolute Größe Verwendung finden. In der Darstellung der Produktivität wird aber der absolute Wert nicht angezeigt. Seite 48

53 Damit ist die Stabilität der Produktivität ein wichtiges Merkmal für die Qualität des agilen Prozesses. Eine stark schwankende Produktivität deutet auf eine mangelhafte Umsetzung des agilen Prozesses oder damit verbundener Entwicklungstechniken hin. Eine stetig steigende Produktivität deutet wenn nicht andere sehr positive Entwicklungen dagegen sprechen vor allem auf dysfunktionale Effekte im Reporting hin. Das wichtigste Ziel des IT-Managements muss damit die Stabilisierung der Produktivität sein. Erst wenn diese gesichert ist, kann durch Maßnahmen zur Team- und Prozessverbesserung versucht werden, die Produktivität zu steigern. In einem aktuellen Projektumfeld des Autors konnte in bestimmten Zyklen immer wieder Produktivitätsrückgänge beobachtet werden. Nach Diskussion mit dem Team hat sich herausgestellt, dass diese Rückgänge immer mit den großen Software-Rollouts im Unternehmen zusammenfallen. In weiterer Folge hat sich gezeigt, dass hier agile Techniken noch nicht ausreichend umgesetzt wurden und daher der Rollout mit zusätzlichen Arbeits-, Test- und Bugfixing-Aufwand verbunden war und daher jeweils während einer Iteration mit Rollout weniger Funktionalität umgesetzt werden konnte Projektvorschau Die wesentliche Grundidee zum Planning-Burndown und zur Projektvorschau stammt von [Mayer 2011], der diese Werkzeuge in ähnlicher Form im Projektalltag einsetzt. Eine Projektvorschau aus Abbildung 20 informiert alle Beteiligte über zukünftig geplante Projekte und deren Termine und Priorisierung. Einerseits stellt das eine wichtige Planungsgrundlage dar, kann aber auch eine Rolle bei mittelfristigen Entscheidungen wie etwa Technologieauswahl sein. Andererseits dient es auch der transparenten Kommunikation der Mitarbeiter gegenüber. Wünscht man sich, dass ein Unternehmen gemeinsam an einem gemeinsamen großen Ziel arbeitet, ist es auch sinnvoll, weiter als das aktuelle Projekt zu informieren. Die Projektvorschau soll folgende Daten in tabellarischer Form enthalten: - Projektname (inkl. Verlinkung auf Beschreibung und bereits vorhandener Dokumentation), - geratene Anzahl an Backlog Elementen, - frühester Start, - voraussichtlicher Liefertermin, - Umsetzungswahrscheinlichkeit (Hoch, Mittel, Niedrig). Man könnte jetzt annehmen, dass die Angabe dieser Eckdaten nicht agil wäre. Erfahrungsgemäß sind diese Eckpfeiler aber unabhängig von der Vorgehensweise notwendige Daten, um Projekte vorzubereiten und planen zu können. Seite 49

54 Abbildung 20 - Element Projektvorschau Für jede Form der Vorausplanung ist eine Abschätzung des Projektumfangs notwendig. In agilen Prozessen kann eine genaue Abschätzung erst erfolgen, wenn die Elemente des Backlogs erfasst und beschrieben sind. Nachdem aber in der Planungsphase bereits eine Abschätzung notwendig ist, kann dieser Prozess in der Form nicht eingehalten werden. Daher muss auf andere bereits bekannte - Methoden zurückgegriffen werden. Nachdem der Mensch in der vergleichenden Abschätzung relativ gut ist, wird dieses Prinzip auch hier eingesetzt, das Projekt mit allen seinen Unklarheiten grob in eine Anzahl möglicher Elemente für den Backlog zu zerlegen. Dieser Arbeitsschritt wird üblicherweise vom Produktverantwortlichen oder erfahrenen Business Analysten gemacht. Die Abschätzung wird eine ähnliche Ungenauigkeit haben, wie das auch in klassischen Vorgehensweisen der Fall ist, und die Qualität wird vor allem von der Erfahrung der abschätzenden Person abhängig sein. Um diese Ungenauigkeit zu kommunizieren, wird bewusst der Begriff geratene Anzahl verwendet. Das Ergebnis kann dann mit den durchschnittlichen Story-Points multipliziert werden. Aus Erfahrungswerten kann errechnet werden, wie viel die Umsetzung eines Story-Points kostet und man erhält so eine Grobabschätzung für ein Projekt. Durch die Erfahrungswerte zur Produktivität des Teams lassen sich daraus geratene Kosten und geratener Zeitaufwand berechnen. Die Schätzgrundlage kann entweder als eigenes Dokument oder direkt in Form von rudimentären Backlog-Einträgen dokumentiert werden. Der Vorteil zu klassischen Schätzmodellen ist hierbei, dass in der Nachbetrachtung gut abzuklären ist, warum ein Projekt falsch eingeschätzt wurde. Vervielfachen sich in der Projektumsetzung die Anzahl der Einträge im Backlog, wurde der Projektumfang falsch eingeschätzt. Sinkt allerdings die Produktivität im Team, wurden Umgebungsfaktoren wie Technologien, Kommunikation oder Test unterschätzt. Die Umsetzungswahrscheinlichkeit ist wichtig für die Szenarioplanung. So kann es sinnvoll sein, in der mittelfristigen Planung die Teams zu überlasten, wenn viele Projekte mit niedriger Umsetzungswahrscheinlichkeit eingeplant sind. Im Gegensatz dazu ist es sehr riskant, die Teams zu überlasten, wenn die Projekte alle hohe Umsetzungswahrscheinlichkeit haben. Es ist wichtig zu verstehen, dass auch die Projektvorschau ein lebendiges Artefakt ist, das sich laufend verändert. Es können Projekttermine, Projektprioritäten oder Abschätzungen geändert werden. Seite 50

55 Planning-Burndown Der Planning-Burndown ist in dieser Form bisher in der Literatur nicht beschrieben und wird daher hier auch näher ausgeführt. Die Idee des Planning-Burndown ist, die Mechanismen des Burndown-Diagrammes für laufende Projekte auch auf die Planung von künftigen Projekten auszuweiten. Eine Umsetzung des Planning-Burndowns in Tabellenform stammt von [Mayer 2011] und dient ebenfalls als Basis für die folgenden Überlegungen. Eine graphische Umsetzung des Planning-Burndown ist in Abbildung 21 dargestellt. Abbildung 21 Element Planning-Burndown Das Planning-Burndown dient zur Szenarioplanung von künftigen Projekten. Es zeigt den idealisierten Burndown, der auf Basis der aktuellen Produktivität erstellt wird. Die aktuelle Produktivität ist das beste Planungsinstrument für künftige Entwicklung, da es die höchste Zuverlässigkeit auf Basis von Erfahrungswerten hat. Jeder der Blöcke im Diagramm stellt ein Projekt dar. Die Höhe ergibt sich auf Basis der grob abgeschätzten (geratenen) Story- Points. Der Block wird links vom frühesten Starttermin und rechts durch den Projektliefertermin begrenzt. Anschließend werden die Blöcke vom spätesten Termin rückläufig hochgestapelt. Die Kennlinie zeigt den zu erwartenden Burndown auf Basis der aktuellen Produktivität, wobei die die Produktivitätskennlinie bei der Summe aller Story-Points der geplanten Projekte startet. Damit können wichtige Rückschlüsse über die Projektplanung einfach abgelesen werden. Ein Projekt kann planmäßig umgesetzt werden, wenn die Produktivitätskennlinie an der oberen und unteren horizontalen Linie des Projekts schneidet. Das aktuelle Projekt und Projekt 2 können also planmäßig umgesetzt werden. Anschließend verläuft die Produktivitätskennline kurz außerhalb eines Projektblockes. In dieser Zeit herrscht nach aktueller Planung eine Auslastungslücke. Bei Projekt 3 ist derzeit ein Planungsproblem. Durch den späten möglichen Start kann das Projekt nicht mehr rechtzeitig fertiggestellt werden. Es wäre also sinnvoll, das Projekt 3 neu zu planen und Möglichkeiten auszuloten, um das Projekt schon früher zu beginnen. Das Projekt 4 wird nach derzeitiger Planung eine Punktlandung hinlegen und ist damit mit Vorsicht zu betrachten. Da bei Projekt 5 die Produktivitätskennlinie an der Seitenlinie geschnitten wird, ist dieses Projekt mit dem aktuellen Terminplan nicht realisierbar. Hier ist also eine Projektverschiebung notwendig. Seite 51

56 Zusätzlich können noch die Projekte nach deren Umsetzungswahrscheinlichkeit eingefärbt werden. Dann können zum Beispiel Projekte mit niedriger Umsetzungswahrscheinlichkeit bewusst risikoreich eingeplant werden. Bei allen diesen Planspielen ist allerdings immer auch [Goldberg/Rubin 1995] zu beachten: Plan truthfully. Avoid planning beyond the limits of your understanding. Seite 52

57 7. Anwendung des Modells auf vorhandene Daten Die vorliegenden Daten stammen aus einer Entwicklungsabteilung eines Telekommunikationsunternehmens, die großteils Projekte für interne Kunden abwickelt und dabei Software zur Unterstützung interner Geschäftsprozesse entwickelt. Die Daten wurden aus dem Issue Tracking System exportiert, in dem der Backlog und die Sprint Backlogs verwaltet werden. Alle Projektnamen und Backlog Einträge wurden anonymisiert. Die Abschätzung der Story-Points und die Typen der Backlog-Einträge wurden beibehalten. Die Daten stammen aus 15 Projekten im Zeitraum von bis In dieser Zeit wurden 643 Issues bearbeitet, von denen 195 Defects waren. Die 372 Stories wurden mit 842 Story-Points abgeschätzt und in 28 Sprints großteils fertiggestellt. Im angegebenen Zeitraum wurden 42 Versionen (inklusiver aller Hotfixes) ausgerollt. Um die Daten richtig aufbereiten zu können, mussten diese teilweise manuell nachbearbeitet werden. So konnte zum Beispiel das Planning-Burndown nicht über die Projekte aufgebaut werden, sondern musste aufgrund der Rollout-Versionen erstellt werden. Die Planning-Burndown Diagramme stellen im Beispiel also eine Release-Planung dar. Das Burndown-Diagramm in Abbildung 22 zeigt sowohl den Fortschritt als auch das Ziel sehr deutlich. Die obere Fläche üblicherweise grün dargestellt - repräsentiert die erfolgreich umgesetzte Funktionalität und wächst ständig an. Damit wird auch ein positiver psychologischer Effekt erreicht. Die untere Fläche üblicherweise rot dargestellt - zeigt die noch nicht implementierte Funktionalität. Der Burndown beginnt in diesem Beispiel nicht bei null Story-Points, da das Team bereits vorher gearbeitet hat und bei der Umstellung nach Scrum den Backlog initial befüllt hat. Trotz der lokalen Schwankungen pro Sprint zeigt die obere Fläche eine konstante V-Form, die den gleichmäßigen Fortschritt darstellt. Abbildung 22 - Burndown-Diagramm des gesamten Backlogs Seite 53

58 Aus den Daten der einzelnen Sprints erfolgt dann die Produktivitätsrechnung. Im Diagramm wird die Produktivität normalisiert auf 100% angezeigt. Diese Normalisierung ist insbesondere auch dann wichtig, wenn die Produktivität von mehreren Teams zusammengefasst wird. Wie bereits früher beschrieben, liegt dabei der besondere Augenmerk auf die Gleichmäßigkeit. Im Produktivitätsdiagramm in Abbildung 23 ist der Durchschnitt der letzten fünf Sprints in rot (dunkel) dargestellt. Der Durchschnitt der letzten 10 Sprints ist blau (hell) dargestellt. Die Abweichung zu den individuellen Sprintergebnissen wird als Fehlerstrahl eingezeichnet. In dem Diagramm wird ersichtlich, dass die Produktivität im Team von Sprint zu Sprint sehr stark schwankt. Erst der Durchschnitt über zehn Sprints pendelt sich einigermaßen ein. Die Produktivität des Teams schwingt also sehr stark. Durch den Scrum Master und in den Retrospektiven müssen daher Maßnahmen für eine gleichmäßigere Produktivität gesetzt werden. Im konkreten Beispiel sind die wesentlichen Faktoren die Releasezyklen der Software, die mit zusätzlichen Aufwänden verbunden sind und auch die Schwankungen in der Arbeitszeit des Teams. Besonders schmerzhaft waren die Entwicklungen in den Sprints In diesem Zeitraum wurden zwei neue Teammitglieder integriert und ein technologisch neues Projekt wurde in Angriff genommen. Es wird also deutlich, dass neue Teammitglieder meist erst über viele Sprints hinweg die Leistung eines Teams steigern werden. Abbildung 23 - Produktivität Im Defekt-Burndown in Abbildung 24 wird die Entwicklung aller gefundenen Fehler und der noch offenen Fehler dargestellt. Die meisten agilen Prozesse fordern die sofortige Behebung aller gefundenen Fehler. Das ist sicherlich wünschenswert, wird in der Praxis aber meist erst nach einer ersten Triage erledigt. Kritische Defekte werden sofort behoben. Defekte, die den Einsatz der Software nicht wesentlich behindern, werden analog zu neuer Funktionalität im Backlog priorisiert, erhalten aber keine Story-Points. Die Entwicklung in diesem Fall zeigt eine relativ gleichbleibende Qualität, da die Anzahl der gefunden Fehler einigermaßen linear verläuft. Steigen die Fehler überlinear an, signalisiert das eine fallende Qualität der Software. Entwickelt sich die Anzahl der Fehler unterlinear, ist das ein Anzeichen für steigende Softwarequalität oder aber auch für fehlende Rückmeldung der Anwender. Auch hier wird wieder deutlich, dass die Zahlen erst durch Kommunikation und Interpretation aussagekräftig werden. Seite 54

59 Abbildung 24 Defekt-Burndown Das Planning-Burndown in Abbildung 25 wurde auf Basis der historischen Releasedaten erstellt. Damit wurde also quasi die Planung mit den tatsächlichen Daten nachgespielt. Damit ist das Planning-Burndown für diese Daten natürlich ideal und alle Termine können genau eingehalten werden. Man erkennt aber auch schon in dieser ersten Variante, dass es zwei sehr knappe Termine gegeben hat. Die Version WFM 1.7 konnte gerade noch fertiggestellt werden und auch bei den Versionen elek2.1.4 und wurde die Zeit knapp. Das kann man daran ablesen, dass die Kennlinie der Produktivität die Projektflächen erst knapp vor der rechten unteren Ecke schneiden. Abbildung 25 - Planning-Burndown mit passender Auslastung Seite 55

60 Das Planning-Burndown in dieser Darstellungsweise gibt allerdings keine Auskunft darüber, wie Projektarbeiten parallelisiert werden sollten. Dem Diagramm liegt die vereinfachende Annahme zugrunde, dass alle Teammitglieder ausschließlich und mit vollem Einsatz an einem einzigen Projekt arbeiten können. Das entspricht oftmals nicht der Realität, da Projekte in sich selbst eine Mindestlaufzeit haben und sich nicht beliebig schnell erledigen lassen. Aufgrund der visuellen Darstellung im Planning-Burndown lassen sich aber bereits Empfehlungen ableiten, welche Projekte parallel betrieben werden sollten. Um auch andere Ausprägungen im Burndown-Diagramm aufzuzeigen, wurden die gleichen Daten nochmals verwendet. Nun wurde aber eine höhere Produktivität zugrunde gelegt. Während in der Abbildung 25 die Produktivität 30 Story-Points / Sprint betragen hat, stellt Abbildung 26 dieselbe Projektsituation dar, allerdings bei einer Produktivität von 40 Story- Points / Sprint. Abbildung 26 - Planning-Burndown mit geringer Auslastung Dabei wird deutlich, dass schon bei Sprint 12 kaum mehr Arbeit für das Team im Backlog ist und ab Sprint 18 wird das Team nicht mehr ausgelastet sein, da die später folgenden Projekte noch nicht bearbeitet werden können. Damit müssen für eine Auslastung über die nächsten 30 Sprints (etwas mehr als ein Jahr) zusätzliche Projekte eingeplant werden oder auch der Umfang bereits geplanter Projekte kann erhöht werden. In Abbildung 27 ist die Situation bei geringerer Produktivität in diesem Fall bei 25 Story- Points / Sprint dargestellt. Das entspricht einem Produktivitätsrückgang von etwas unter 20%. Dabei erkennt man, dass schon die Version WFM 1.9 terminlich gefährdet ist und im weiteren Verlauf viele der Projekte mehr rechtzeitig fertiggestellt werden kann. Hier ist also auf jeden Fall eine Neuplanung notwendig. Die Version kann aber bei aktueller Planung dennoch umgesetzt werden. Seite 56

61 Abbildung 27 - Planning-Burndown mit Überlastung Wichtig für den nutzbringenden Einsatz des Planning-Burndowns ist die Möglichkeit, flexibel mit der Planung zu experimentieren. Das Werkzeug muss also ein einfaches Verschieben und Verändern der Projekte ermöglichen und verschiedene Szenarien auch abspeichern können. Das Planning-Burndown sollte eines der wichtigsten Werkzeuge für die mittelfristige Planung sein. Seite 57