Projekte der öffentlichen Hand sind wie die meisten Projekte zunehmend durch vielfältige und sich schnell ändernde Anforderungen gekennzeichnet. Umso wichtiger ist es, schnell und effektiv auf diese Anforderungsänderungen zu reagieren.

Das wird durch agile Arbeitsmethoden ermöglicht. Sie schaffen die Voraussetzung dafür, dass Teams schneller und flexibler auf Veränderungen reagieren können. Dadurch kann agiles Arbeiten dazu beitragen, die Effektivität, Effizienz und Servicequalität der öffentlichen Verwaltung zu verbessern. 

Aus diesem Grund ist agiles Projektmanagement fester Bestandteil des ganzheitlichen Projektmanagementsystems PMflex. PMflex beinhaltet deshalb neben Leitfäden für Projekt-, Programm- und Portfoliomanagement einen eigenen Leitfaden für agiles Projektmanagement. 

Das folgende E-Learning beschäftigt sich mit PMflex Agil, dessen Kernelement die Methode PM²-Agile der Europäischen Kommission ist.

In jeweils einem Schulungsvideos stellen wir Ihnen vor, was Agilität eigentlich ist, und geben Ihnen einen Überblick über die Methodik. Außerdem stellen wir Ihnen die Rollen und Verantwortlichkeiten in agilen Projekten vor. In weiteren Schulungsvideos erhalten Sie einen Überblick über typische agile Themen, Events und Artefakte. Zu guter Letzt geben wir Ihnen noch einen Überblick zu den meistverwendeten agilen Tools und Techniken.

Ich wünsche Ihnen nun viel Spaß bei den Schulungsvideos zu PMflex Agil.

Agilität ist ein Ansatz, dessen Schwerpunkt auf der schnellen Bereitstellung vollwertiger Lösungen liegt. Er fördert adaptive Planung, frühzeitige Bereitstellung von Ergebnissen, kontinuierliche Verbesserung sowie eine schnelle und flexible Reaktion auf Veränderungen. Insgesamt lässt sich also sagen, dass der Ansatz dazu dient, alle Projektprozesse fortlaufend zu verbessern und zu straffen. Agilität kann dies leisten, weil es auf einer Reihe von Grundwerten und Prinzipien beruht, die wir Ihnen im Folgenden näher erläutern möchten.

Agile Werte

Das agile Manifest bildet eine Grundlage für agiles Projektmanagement. Es besteht aus vier Werten, die wie folgt lauten: 

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Erstens, Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Prozesse und Werkzeuge stoßen häufig an ihre Grenzen. Hier kann die Fähigkeit von Menschen zur effektiven Zusammenarbeit die erforderliche Reaktions- und Problemlösungskapazität bereitstellen. 

Funktionierende Lösungen mehr als umfassende Dokumentation

Zweitens, funktionierende Lösungen sind höher zu bewerten als eine umfassende Dokumentation. In Projekten wird für die Dokumentation viel Zeit aufgewendet. Diese geht von der Zeit für Entwicklung der Lösungen und der Teammitglieder ab. Weil sich in agilen Projekten durch kontinuierliches Feedback die Spezifikationen häufig und schnell ändern, ist es wichtig die Dokumentationen schlank zu halten. Dadurch sind Dokumentationsanstrengungen nicht umsonst, wenn ein Großteil der Spezifikationen verändert wird. 

Zusammenarbeit mit Stakeholderinnen und Stakeholder mehr als Vertragsverhandlungen

Drittens, die Zusammenarbeit mit den Stakeholderinnen und Stakeholdern ist wichtiger als Vertragsverhandlungen. Verträge werden häufig zu einem frühen Zeitpunkt unterzeichnet, was dann zu aufwendigen Änderungsmanagementverfahren führt. Änderungen sind zwar unvermeidlich, aber es ist besser, sie durch eine effiziente Zusammenarbeit mit Stakeholderinnen und Stakeholdern zu bewältigen.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Viertens, das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Es ist zwar wichtig einen Plan zu haben, dieser sollte jedoch nur für die aktuelle Iteration ausgearbeitet sein. Dadurch können mit Hilfe des eingehenden Feedbacks Anpassungen des Plans für die nächste Iteration vorgenommen werden.

Prinzipien von PM²-Agile

Die 12 Prinzipien des agilen Manifests basieren auf den soeben vorgestellten Werten. PM²-Agile hat diese Prinzipien mit einigen Modifizierungen übernommen. Diese sind:

• Stelle die Kunden durch frühe und kontinuierliche Lieferung wertvoller Lösungen zufrieden.
• Anforderungsänderungen sind erwünscht.
• Generiere regelmäßig Wert durch funktionierende Lösungen.
• Fachleute und das Projektkernteam müssen während des gesamten Projekts zusammenarbeiten.
• Bringe motivierte Mitarbeitende zusammen und gib ihnen das Umfeld und die Unterstützung um selbstorganisiert zu arbeiten.
• Das effizienteste und wirksamste Kommunikationsmittel ist das persönliche Gespräch.
• Das wichtigste Maß für Fortschritt sind der Wert und die Brauchbarkeit dessen, was geliefert wurde.
• Ebenso muss ein ständiges Augenmerk auf die Qualität gelegt werden.
• Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
• Das Team analysiert regelmäßig, wie es besser werden kann, und ändert und passt sein Verhalten entsprechend an.
• Agile Prozesse fördern nachhaltige Entwicklung.
• Und zu guter Letzt - Agile Praktiken sollten unternehmensorientiert sein.

Agile Teams

Agilität geht davon aus, dass der wichtigste Produktivitätsfaktor in einem Team die Menschen sind und die Art, wie sie miteinander interagieren. Agile Teams organisieren sich selbst und arbeiten kollaborativ zusammen. Das bedeutet, dass das Team so zusammenarbeitet, um die effektivste Vorgehensweise zu finden, mit der sich die Arbeitsschritte bestmöglich durchführen lassen. Ebenso sind agile Teams funktionsübergreifend zusammengesetzt und bestehen aus Mitgliedern mit der benötigten Expertise zur Entwicklung und Bereitstellung einer Lösung. 

Kontinuierliche Verbesserung und validiertes Lernen

Ein wichtiges Prinzip und eine Kernphilosophie agilen Arbeitens sind kontinuierliche Verbesserung und stetiges Lernen. 

Agile Teams folgen daher einer Feedback-Schleife. Es handelt sich um einen Lernzyklus, in dem Ideen in Produkte umgesetzt werden. Anschließend werden die Reaktionen und das Verhalten der Nutzenden in Bezug auf die entwickelten Produkte gemessen. Auf dieser Basis wird anschließend darüber entschieden, ob die Idee unverändert weiterverfolgt oder „umgeschwenkt“ (geändert) werden soll. Dieser Prozess wird beliebig oft nach Bedarf wiederholt. Ziel dieser Schleife ist eine Reduzierung der Gesamtzeit. Dies erfolgt durch häufige Reviews und Retrospektiven. Konkret sind damit Routinen gemeint, mit denen Teams aus Erfahrungen und Planänderungen lernen und das Gelernte in den nächsten Zyklus einbringen

Minimum Viable Product (MVP)

Ein weiteres zentrales Prinzip agilen Arbeitens ist die Fokussierung auf ein Minimum Viable Product. Die Wirksamkeit eines agilen Teams bemisst sich nach seiner Fähigkeit, Ideen zu generieren, daraus schnell ein Minimum Viable Product zu erschaffen, die Marktresonanz darauf zu messen und durch die Analyse der generierten Daten zu lernen.

Insofern ist das Minimum Viable Product (MVP) das Ergebnis eines fortlaufenden validierten Lernprozesses, das grünes Licht für die inkrementelle Entwicklung oder auch einen Hinweis darauf gibt, dass eine Idee nicht weiterverfolgt werden sollte.

Die PM²-Methodik ist eine schlanke, einfach umzusetzende Methodik, die Projektteams an ihre spezifischen Anforderungen anpassen können. Die nahtlose Integration der PM²-Methode und agilen Methoden hilft den Teams, richtlinien-, prozess- und auditkonform zu arbeiten. Hierzu sind in PM²-Agile die folgenden Elemente enthalten:

• eine Darstellung agiler Werten und Prinzipien
• ein agiles Rollenmodell mit Verantwortlichkeiten
• Hinweise zum Umgang mit bestimmten Themen im agilen Kontext
• Hinweise zu agilen Artefakten
• Eine Beschreibung von Tools und Techniken im agilen Kontext
• sowie ein Set an agilen Events.

Diese Elemente sind sowohl für diejenigen hilfreich, die agile Methoden bereits praktizieren, als auch für diejenigen, die bereit sind, in ihren Projekten agile Ansätze auszuprobieren.

PM²- Lebenszyklus

Der bereits aus der PM²-Projektmanagementmethodik dargestellte Projektlebenszyklus umfasst alle Ereignisse und Aktivitäten ab dem Zeitpunkt, der Idee bis zum endgültigen Abschluss des Projekts.

Ergänzend zu diesen Phasen gibt es bei PM²-Agile iterative Zyklen auf drei Ebenen, die sich in die Durchführungsphase des PM² Projektlebenszyklus einfügen: tägliche Zyklen, Iterationen und Releases. Dies ist möglich, weil die PM² Projektmanagementmethodik auf der Umsetzungsebene keine spezifischen Prozesse vorschreibt und sich die Projektergebnisse in der Durchführungsphase problemlos agil erarbeiten lassen.

Tägliche Zyklen

Am Anfang des Projekts geht es vor allem darum, zu verstehen, was entwickelt werden soll. Dafür wird eine Gesamtvision festgelegt, die Stakeholderinnen und Stakeholder identifiziert sowie die Erfolgskriterien ermittelt. In dieser Phase ist noch vieles unsicher. Es müssen nämlich erst alle Annahmen ermittelt und formuliert werden. Dafür ist eine angemessene Kommunikation entscheidend, die in Form von täglichen Kommunikationszyklen stattfindet.

Iterationen

Mit Fortschreiten des Projekts verlagert sich der Schwerpunkt der fachspezifischen Aktivitäten zum inkrementellen Aufbau der Lösung. Das Verständnis, welche Aufgaben in welcher Weise erstellt werden, wird durch die Validierung der Hypothesen erhöht. Die Entwicklung vollzieht sich in verschiedenen Iterationen. Dadurch werden die Anforderungen fortlaufend überprüft und klargestellt. Eine agile Iteration ist eine Zeitspanne innerhalb eines Projekts, in der das agile Projektkernteam einen stabilen, potenziell lieferbaren Teil der Lösung zusammen mit anderen notwendigen Begleitdokumenten oder Liefergegenständen erstellt.

Releases

Zum Ende des Projekts hin verlagert sich der Schwerpunkt darauf, sicherzustellen, dass die Lösung gut in die Liefergegenstände des Gesamtprojekts integriert ist. Außerdem muss sie zur Realisierung des von der Organisation gewünschten Nutzens beitragen. Ein Release ist das Ergebnis eines inkrementellen Prozesses über mehrere Iterationen. Dabei gibt das Team die Lösung als marktfähiges Produkt oder als Minimum Viable Product frei.

Nochmal zur Erinnerung: Die PM² Projektmanagementmethodik sieht die in dieser Abbildung dargestellten Rollen vor. Dazu zählen vor allem die vier Schlüsselrollen der Projekteigner, der Anforderungsmanager, die Lösungsanbieterin und die Projektleitung. 

PM²-Agile fügt sich in diese Projektorganisation ein und erweitert sie in der Ausführungsebene um weitere Rollen. Der Teamkoordinator, der Product Owner, die Systemarchitektin sowie agile Teammitglieder werden zusätzlich aufgenommen. 

Teamkoordinator

Der Teamkoordinator fungiert im agilen Team als Moderator und Team-Coach. Seine Hauptaufgabe besteht darin, Bedingungen für das Team zu schaffen, damit Aufgaben fokussiert bearbeitet und Ziele erreicht werden können. 

Product Owner

Der Product Owner vertritt in erster Linie die Anliegen der Kunden und Endnutzenden; und ist insofern deren Stimme in agilen Projekten. Deshalb sollte er sollte ein tiefes Verständnis der Anforderungen und Wünsche der Stakeholderinnen und Stakeholder entwickeln. Dadurch kann er die Arbeitselemente mit dem größten Kundennutzen erfassen und priorisieren

Systemarchitektin

Die Systemarchitektin ist die Lösungsarchitektin, die in IT-Projekten für die architektonischen Entscheidungen des agilen Projektkernteams zuständig ist. Die Systemarchitektin unterstützt die Erstellung und Weiterentwicklung des übergeordneten Lösungsdesigns und beurteilt erfolgte oder geplante Investitionen in andere Informationssysteme oder Komponenten.

Agile Teammitglieder

Agile Teammitglieder konzentrieren sich auf die Erstellung der eigentlichen Lösung für die Bedürfnisse der Stakeholderinnen und Stakeholder, also beispielsweise der Produktion des eines Informationssystems. Sie verfügen über interdisziplinäre Kompetenzen, der Spezialisierungsgrad in den einzelnen Disziplinen variiert jedoch von Person zu Person. 

Andere agile Rollen

Neben den genannten PM²-Agile Kernrollen können weitere Rollen vorgesehen werden. Typischerweise treten diese dem agilen Projektkernteam vorübergehend bei und helfen bei der Bewältigung und der Überwindung bestimmter fachlicher oder technischer Herausforderungen. Darunter fallen beispielsweise fachkundige Personen, technische Sachverständige oder unabhängige Testerinnen und Tester. 

Projektleitung und Anforderungsmanager

Mit der Einführung neuer Rollen wie Product Owner und Teamkoordinator und dadurch, dass Entwicklungsteams als „selbst organisierte Einheit“ arbeiten, verändern sich auch die Rollen der Projektleitung und des Anforderungsmanagers.

Projektleitung

In agilen Projekten teilt sich die Projektleitung die Verantwortung für die Einhaltung der Methodik mit dem Teamkoordinator. Gemeinsam mit ihm muss er für eine ordnungsgemäße Anwendung der im Projekthandbuch beschriebenen Methodiken sorgen. Typischerweise übernimmt der Teamkoordinator hier die Verantwortung für die agilen Elemente.

Weil agile Teams selbstorganisiert arbeiten verschiebt sich seine Rolle im Team- und Fortschrittsmanagement. An die Stelle der Zuweisung und Überwachung von Aufgaben rückt die Lösung von im Projekt identifizierten Hindernisse und Problemen.

Zu Guter Letzt wird die Zuständigkeit der Projektleitung für das Management der Erwartungen von Stakeholderinnen und Stakeholdern vom Product Owner übernommen. Die Projektleitung greift hier nur zusammen mit dem Anforderungsmanager ein, wenn Erwartungen nicht abgestimmt sind oder der Product Owner und der Rest des agilen Projektkernteams nicht zu einem Konsens gelangen können.

Anforderungsmanager

Die Rolle des Anforderungsmanagers wird in agilen Projekten deutlich erweitert, weil mit dem Product Owner ein permanente und aktive „Kundenstimme“ auf Seiten des Leistungserbringers geschaffen wird. Dies stellt höhere Anforderungen an den Anforderungsmanager. Als Nutzervertretung ist er viel stärker in das Projekt eingebunden und muss sich aktiv an dem Iterationsreview beteiligen, um den Iterations-Output des Entwicklungsteams zu validieren.

Ebenso muss sich der Anforderungsmanager eng mit dem Product Owner abstimmen. Der Anforderungsmanager erteilt Befugnisse und stimmt diese wiederum mit dem Product Owner.

PM²-Agile erfordert Anpassungen an einigen Projektmanagementkonzepte und -praktiken, die sie vielleicht bereits aus PM²-Projektmanagement kennen. Das liegt daran, dass der agilen Vorgehensweise andere Werte und Prinzipien zugrunde liegen. In der eingeblendeten Grafik werden diese Anpassungen in „Themen“ unterteilt. Im Folgenden werden wir Ihnen die Kernaspekte der Themen kurz erläutern. 

Lean UX

PM²-Agile ist stark durch Lean UX beeinflusst. Bei klassischen Projekten wird im Vorfeld auf ein detailliert definiertes Ergebnis hingearbeitet. Der Grundgedanke von Lean UX besteht darin, durch schnelle Prototypen ein gemeinsames Verständnis, kontinuierliche Verbesserung und validiertes Lernen zu fördern.

Planung

Der Planungsaufwand ist bei agilen Projekten größer als bei herkömmlich gemanagten Projekten. Vom Führen der Arbeitselementeliste und Schätzen des Aufwands für die Arbeitselemente bis hin zu Stand-up-Meetings und Iterationsplanung: der Erfolg hängt explizit von einer wirksamen und effizienten Planung ab.

Abstimmung und Berichterstattung

Für agile Praktiken haben sich spezielle Begrifflichkeiten, Rituale, Formate und Metriken für eine effiziente Kommunikation und Koordinierung der Arbeit im Team entwickelt. Damit diese teamintern gut funktionieren und damit diese auch mit den spezifischen Informationsbedürfnissen und -präferenzen der Stakeholder und Stakeholderinnen übereinstimmen, bedarf es einer internen als auch externen Abstimmung.

Anforderungen

Anforderungen sind Merkmale, die ein Produkt oder eine Dienstleistung haben soll, um die Bedürfnisse der Stakeholderinnen und Stakeholder bestmöglich zu erfüllen. In Projekten, in denen die Anforderungen umfassend bekannt und beschrieben sind, kann ein Vorab-Planungsansatz, wie er aus herkömmlichen Projekten bekannt ist, angewendet werden. Sind die Anforderungen jedoch nicht gänzlich bekannt oder ist die Änderungsrate hoch, liefern agile Ansätze die besseren Ergebnisse.

Schätzung und Priorisierung

Die agile Schätzung unterscheidet sich von „traditionellen“ ausführlichen Schätzungen dadurch, dass sie das Konzept „gerade genug Details im Voraus“ beinhaltet. Dabei wird der Aufwand der Schätzung mit den verfügbaren Informationen und den Erwartungen an die Genauigkeit der Schätzung abgewogen. Sowohl die Schätzung als auch die Priorisierung sind Arbeitselemente, die während des Projekts kontinuierlich durchgeführt werden sollten. So kann mit Voranschreiten des Projekts der Plan, wie die angestrebten Ziele erreicht werden sollen, besser angepasst werden. 

Risiken

Agiles Risikomanagement umfasst die Beseitigung von Hindernissen, die den Arbeitsfortschritt der Mitglieder des Projektteams behindern. Aufgrund der engen Teamzusammenarbeit, dem Grundsatz die Menge an nicht erledigter Arbeit zu minimieren und dem hohen Anteil an Reflexionsaktivitäten gelten agile Projekte als weniger risikoreich als phasenbasierte Projekte. Dennoch sind auch in agilen Projekten Maßnahmen des Risikomanagements vorzusehen. 

Qualität

Qualität wird in herkömmlich gemanagten Projekten durch eine ausführliche Dokumentation von Anforderungen und Abnahmeprozesse sichergestellt. PM²-Agile unterscheidet zwischen zwei verschiedenen, aber sich ergänzenden Arten von Qualität: Zum einen die Qualität des Entwicklungsprozesses und zum anderen die Qualität der Outputs des Prozesses. PM² stellt eine hohe Qualität dadurch sicher, dass das gesamte agile Projektteam, der Anforderungsmanager und die Nutzervertretung in jedem Arbeitszyklus eng einbezogen werden. Dies kann beispielsweise durch häufige Nutzer-Demonstrationen erfolgen.

Weiterentwicklung und Veränderung

PM²-Agile betont insbesondere das Erfordernis, die natürliche Weiterentwicklung des Projektumfangs anzuerkennen und zu begrüßen. Mit dem Voranschreiten des Projekts gewinnt das Projektteam ein immer besseres Verständnis für das zu lösende Problem und die Art und Weise, wie es angegangen werden kann.

Architektur

Die spezifischen Software-Architekturentscheidungen, die im Rahmen eines IT-Projekts getroffen werden, müssen in die allgemeine Unternehmensarchitektur implementiert werden. Wie bei anderen agilen Praktiken wird bei PM²-Agile dieses Prinzip auch auf die Lösungsarchitektur angewendet.  

Compliance und Sicherheit

In Zusammenhang mit Informationssystemen müssen auch bei PM² Agile folgende Aspekte in einer Organisation berücksichtigt werden: Dokumentenmanagement, Datenschutz und Sicherheit. 

Entwicklung

Im Mittelpunkt von PM²-Agile steht die Entwicklung von Informationssystemen, die Teil der Lösung des Projekts sind. In diesem Kontext werden durch Entwicklungsaktivitäten wie Konzeption oder Entwicklung die Spezifikationen zu etwas Greifbarem und ermöglichen es dem System, Gestalt anzunehmen. Das Hauptziel besteht darin, sicherzustellen, dass die Anforderungen angemessen konzipiert, umgesetzt und verfügbar gemacht werden.

Software-Konfigurationsmanagement

Bei der Entwicklung einer Lösung werden Hunderte von Artefakten wie Dokumente, Code-Dateien, Skripte oder Liefergegenstände erstellt, die verwaltet werden müssen. Um Änderungen an Konfigurationen konsistent zu kontrollieren und ihre Integrität und Nachverfolgbarkeit zu gewährleisten, sieht PM² Agile für das Software-Konfigurationsmanagement eine Reihe von Aktivitäten vor.

Test

Agile Testaktivitäten sollten iterativ und inkrementell sein. Durch die Anwendung der Strategie „frühes Testen und häufiges Testen“ können Risiken früh im Lebenszyklus des Projekts erkannt und gemindert werden. Es wird empfohlen, die Testaktivitäten in jeder Iteration durchzuführen, beginnend mit den ersten „Builds“ des Systems.

Deployment und Einführung

Egal um welches Projekt es sich handelt, muss das sich in Entwicklung befindliche Informationssystem, effektiv in die technische Infrastruktur der Organisation eingebunden werden. Alle entsprechenden technischen und infrastrukturbezogenen Aspekte der Bereitstellung des Informationssystems werden im Geschäftsmodell beschrieben. Die Deployment- und Einführungsaktivitäten sind außerdem entscheidend dafür, dass Abhängigkeiten mit anderen Projekten und Informationssystemen berücksichtigt werden.

Ein wesentliches Element agilen Arbeitens ist die Durchführung sogenannter agiler Events. Diese lassen sich nach ihrer wesentlichen Funktion in drei Gruppen einordnen: Koordination, Implementierung und Überprüfung.
Im Hinblick auf die Koordinationsfunktion gibt es drei Events: Die Iterationsplanung, das Daily Stand-up sowie das Release Planning. Die Implementierung konzentriert sich auf die Entwicklung der bestmöglichen Lösung. Hierfür sind keine speziellen Events, sondern eine Reihe verschiedener Tools und Techniken vorgesehen. Die Überprüfung, beinhaltet Aktivitäten und Events, die dazu dienen, die Nützlichkeit der entwickelten Lösung zu bewerten. Dazu gehören das Iterationsreview und die Iterationsretrospektive. Im Folgenden stelle ich Ihnen die Events nochmal im Detail vor.

Iterationsplanung

Die Iterationsplanung zielt darauf ab, auf Grundlage der Verfügbarkeit und Kapazität des Teams, einen Plan und eine Strategie zu erstellen, um das vereinbarte Ziel zu erreichen. Wie oft eine Iterationsplanung stattfindet und wie lange sie dauern soll, sind zwei weitere wichtige Faktoren, die sorgfältig zu erwägen sind. Die Iterationsplanung sollte nicht häufiger als nötig durchgeführt werden und es sollte dafür nicht mehr Zeit als tatsächlich notwendig aufgewendet werden.

Daily Stand-up

Besonders wichtig für die tägliche Routine eines Projekts, das agilen Werten und Prinzipien folgt, ist Kommunikation. Deshalb ist das Daily Stand-up besonders wichtig. In diesem überprüfen die agilen Teammitglieder den „Herzschlag“ des Projekts. Sie informieren sich gegenseitig über die letzten und nächsten Aktivitäten sowie über mögliche Hindernisse. Zudem holen sie voneinander individuelles Commitment bis zum nächsten Daily Stand-up ein. 

Release Planning

Das primäre Ziel des Release Plannings ist es sicherzustellen, dass die Organisation dem agilen Projektkernteam laufende Änderungen mitteilt, die sich auf die Lösungsstrategie auswirken. Wenn eine Releasestrategie veraltet, kann dies dazu führen, dass eine Lösung ganz oder teilweise unbrauchbar wird, was entsprechende negative Folgen hat.

Iterationsreview

Der Hauptzweck des Iterationsreviews besteht darin, zu beurteilen, ob das Iterationsziel erreicht wurde. Dies kann zum Beispiel dadurch erfolgen, dass die agilen Teammitglieder ihre Entwicklung praktisch demonstrieren. Eine solche Demonstration ermöglicht es dem Product Owner und anderen Stakeholderinnen und Stakeholdern, Feedback zu geben. Dieses hilft den agilen Teammitgliedern zu beurteilen, ob ihre Arbeit in die richtige Richtung geht. 

Iterationsretrospektive

Die Iterationsretrospektive zielt darauf ab, die in einer Iteration gesammelten Erfahrungen zu erfassen und Empfehlungen für die Zeit danach zu erfassen. Dabei kann das Team von den im Rahmen der Iteration gewonnenen Erfahrungen profitieren. Darüber hinaus empfehlen wir Ihnen, diese Verbesserungsmöglichkeiten nicht erst zum Abschluss eines Projekts zu erfassen, sondern während der gesamten Projektlaufzeit.

PM²-Agile unterstützt die Projektarbeit durch eine Reihe von Artefakten, die wir Ihnen in diesem Schulungsvideo vorstellen wollen. Diese Artefakte werden insbesondere in Softwareentwicklungsprojekten eingesetzt. Sie dienen zur Erfassung und Dokumentation von Informationen über den Managementansatz und zur Berichtserstattung über Aktivitäten, Meilensteine, Probleme und Fortschritte des agilen Projektkernteams. 

Initiierungsphase

Die Initiierungsphase eines agilen Projekts wird durch zwei Artefakte unterstützt. Die Systemarchitekturübersicht und das Geschäftsmodell.

Die Systemarchitekturübersicht bietet einen groben Überblick über die zu entwickelnde Softwarearchitektur des Informationssystems. Dies beinhaltet die wichtigsten Bausteine der Softwarearchitektur und eine Beschreibung des Beitrags der Architektur zu den Gesamtkapazitäten des Systems. 

Das Geschäftsmodell beschreibt die Aspekte der Architektur eines IT-Systems. Der Schwerpunkt liegt hierbei auf der Infrastruktur des Systems, sowohl aus logischer als auch aus physischer Perspektive. Es beschreibt umfassend das geschäftliche und technische Umfeld, das zur Unterstützung der Nutzenden des Systems eingesetzt wird.

Planungsphase

Die Planungsphase wird durch vier Artefakte unterstützt. Durch das Entwicklungshandbuch, den Entwicklungsarbeitsplan, den Testplan und den Bereitstellungsplan. 

Das Entwicklungshandbuch ist eine Erweiterung des Projekthandbuchs und sollte auf die wichtigsten Kontrollprozesse, Projektrichtlinien, Regeln und den übergeordneten Managementansatz abgestimmt sein.

Im Entwicklungsarbeitsplan werden alle relevanten Informationen zusammengestellt, die bei der Steuerung des Entwicklungsaspekts des Projekts helfen. Er beinhaltet die Arbeitselementeliste, den entsprechenden Releaseplan und die unterstützenden Iterationen. Die Arbeitselementeliste ist eine Aufstellung der während eines Projekts zu erledigenden Arbeit. Arbeitselemente sollten priorisiert, hinsichtlich ihres Aufwands geschätzt und hinsichtlich ihres Fortschritts nachverfolgt werden. Beim Releaseplan liegt der Schwerpunkt darauf, zu beschreiben was, wann getan werden muss. Bei dem Iterationsplan liegt der Schwerpunkt darauf, wie etwas vom agilen Projektkernteam getan werden soll.

Der Hauptzweck des Testplans besteht darin, die notwendigen Testarbeiten zu skizzieren und zu kommunizieren. In ihm werden die Ziele und der der Umfang der Tests, die zu testenden Elemente, der zu verfolgende Ansatz, die benötigten Ressourcen und die zu produzierenden Liefergegenstände festgelegt.

Im Bereitstellungsplan werden Strategie, Rollen und Verantwortlichkeiten sowie Aufgaben festgelegt, damit das Informationssystem von dem zuständigen IT-Betriebsteam bereitgestellt, betrieben und verwaltet werden kann.

Durchführungsphase

Die Durchführungsphase agiler Projekte wird durch die Artefakte Entwicklungsstatusbericht und verschiedene Protokolle unterstützt.

Der Entwicklungsstatusbericht dokumentiert und vermittelt den Stand des agilen Projektkernteams bei der Erreichung der Entwicklungsziele und ist in das Berichtswesen auf Projektebene integriert.

Um die allgemeine Überwachung der Projektleistung zu ermöglichen, sollten bereichsspezifische Risiken, Probleme, Entscheidungen und Änderungen in Projektprotokollen dokumentiert werden. Darüber hinaus sollte der Entwicklungsaspekt des Projekts sowie bereichsspezifischen Informationen über den Entwicklungsstand und Fortschritt in die Projektberichte einfließen. Hier finden die entsprechenden Managementpläne und -protokolle aus der PM² Projektmanagementmethodik Verwendung. 

Abschlussphase

In der Abschlussphase wird auch im agilen Kontext ein Projektabschlussbericht erstellt. Dieser enthält die gesammelten Erfahrungen sowie Empfehlungen für die Zeit nach dem Projekt für beispielsweise Folgesysteme, Erweiterungen und für die Wartung.

Bewertung der Teamarbeit

Eine Methode zur Bewertung agiler Teams sind die „fünf Grundbausteine für den Aufbau eines effektiven, reifen und leistungsfähigen Teams“ nach Patrick Lencioni. Hierbei geht es insbesondere um Vertrauen, Konfliktfähigkeit, Commitment, Rechenschaftspflicht und Ergebnisse. Die Bewertung dieser Grundbausteine und regelmäßige Rückmeldungen helfen Teams dabei ihre Teamleistung zu optimieren.

Selbst organisierte Teams

Selbst organisierte Teams sind ein Schlüsselelement des agilen Arbeitens. Sie arbeiten selbstorganisiert, unabhängig und eigenverantwortlich, um bestimmte Ziele zu erreichen. Durch ein mehr an Verantwortung und Entscheidungsfreiheit wird die Motivation und Effizienz der Teammitglieder erhöht. Zudem führt die Selbstorganisation zu flexibleren Arbeitsabläufen und einer besseren Anpassungsfähigkeit.

Design Blocks

Design Blocks beruhen auf den Techniken des Design Thinking, die sich drauf konzentrieren, die in der nächsten Iteration zu liefernden Arbeitselemente zu konkretisieren. Aus praktischer Sicht handelt es sich bei Design Blocks um eine Reihe von Workshops, in denen das agile Projektteam und andere Stakeholderinnen und Stakeholder zusammenkommen, sich über Anforderungen austauschen und die Annahmen für ein Arbeitselement für die nächste Iteration formulieren.

Features und Storys

Features und Storys sind eine Möglichkeit auszudrücken, welche Anforderungen eine Lösung erfüllen sollte. Features sind Funktionen, die zur Erfüllung der Stakeholder Bedürfnisse bereitgestellt werden. Weil diese häufig zu groß, um sie in einer Iteration umsetzen zu können, werden sie in. kleinere Segmente geschnitten, zum Beispiel Storys. Storys sind äußerst praktisch, weil sie konkrete Liefergegenstände darstellen, die in kurzer Zeit implementiert werden können und einen Mehrwert für die Stakeholderinnen und Stakeholder generieren.

Zerlegen von User Storys

Eine wichtige Technik in agilen Projekten ist das Zerlegen von User Storys. User Storys können während des Lebenszyklus eines Projekts unterschiedlich groß sein. Eine umzusetzende User Story sollte die richtige Größe aufweisen, damit Schätzung, Priorisierung und Entwicklung innerhalb einer Iteration möglich sind.

Definition of Done

Die Definition of Done sollte das Ergebnis der Gespräche und Vereinbarung des Entwicklungsteams darüber sein, was „Fertig“ im Kontext eines Projekts bedeutet. Eine vereinbarte Definition of Done besteht aus einer Checkliste mit Kriterien, anhand derer die agilen Teammitglieder prüfen, ob ein umgesetztes Arbeitselement den Qualitätsstandards des Teams entspricht.

Planning Poker

Planning Poker ist eine konsensorientierte Technik zur Schätzung des relativen Umfangs von Entwicklungszielen. Sie ermöglicht dem Team, effizient eine Einigung erzielen, ohne zu viel Zeit mit einem bestimmten Thema zu verbringen. Zudem gibt sie den Teammitgliedern Raum, ihre Meinungen, Gedanken und Bedenken zu äußern.

Kanban-Methode

Kanban ist ein visuelles Management-Tool. Mit seiner Hilfe können Teams, ihre Prozesse kontinuierlich verbessern, indem sie Workflows visualisieren. Kanban stellt den Prozess in Form von Karten auf einer Tafel dar und beschreibt, was wann zu produzieren bzw. welches Feature zu welchem Zeitpunkt im Entwicklungsprozess hinzuzufügen ist.

Burndown-Charts

Mit Burndown-Charts kann der Fortschritt in einem agilen Projekt nachverfolgt werden. Sie zeigen den Aufwand der noch zu erledigenden Arbeit, um ein Projekt abzuschließen. 

Testgetriebene Entwicklung

Bei der testgetriebenen Entwicklung handelt es sich um eine Technik bei der Entwicklerinnen und Entwickler zuerst einen kleinen Testfall entwickeln, um ein Stück Code zu validieren. Sie führen den Test anschließend aus, um zu bestätigen, dass er fehlschlägt. Anschließend programmieren sie gerade so viel Implementierungscode, wie nötig, damit der Test fehlerfrei ausgeführt werden kann. Dieser Zyklus ist kurz und dauert selten länger als zehn Minuten.

Pairing

Pairing ist eine Technik, bei der zwei agile Teammitglieder gemeinsam an einer Aufgabe arbeiten. Hierbei kann es sich zum Beispiel um die Entwicklung einer Lösung oder das Testen einer Funktion handeln. Die gemeinsame Arbeit führt unterschiedliche Standpunkte zusammen, führt zu besseren Lösungen und verbessert die Qualität der Arbeit.