Agiles Projektmanagement

Wer über Jahre – ja Jahrzehnte sein Wissen im Projektmanagement aufgebaut, angewandt, erweitert, verbessert und optimiert hat – der hat einen beachtlichen Werkzeugkasten zur Verfügung. Mit Elementen aus dem agilen Projektmanagement stehen weitere Methoden und Techniken zur Verfügung. Die kluge, sorgfältige, bewusste, gezielte und passende Anwendung der Methoden und Techniken erfolgt Schritt für Schritt. Agiles Projektmanagement bietet einiges für diesen Werkzeugkasten an. Einige dieser Werkzeuge sind vielleicht neu, doch viele sind wahrscheinlich bereits bekannt. Hier finden Sie eine wohl nie fertigzustellende Zusammenstellung einiger Methoden für Ihr (nicht nur) agiles Projektmanagement.

Werte – und deren Bedeutung !!!APM_1

Setzen Sie Werte (auch agile Werte und Prinzipien) nicht voraus. Sie können diese auch nicht mit einer Power Point Präsentation vermitteln. Die Werte die in einem Projekt Bestand haben, werden von den Projektteilnehmern praktiziert und von den Rahmenbedingungen gefördert (oder behindert). Hier stehen Fragen wie:

  • Wie oft sehen und begegnen sich die Projektmitarbeiter?
  • Welche spontane und geplante, formelle und informelle Kommunikationsmöglichkeiten bestehen?
  • Welche Ziele verfolgt das Unternehmen, stehen Kennzahlen über allem? Kann auch ein Diskurs zur IT-Architektur oder zur IT-Sicherheit Aufmerksamkeit erlangen?
  • Welche Freiräume stehen den Mitarbeitern zur Verfügung? Ist das Home-Office nur ein ausgelagertes Büro mit erhöhtem Überwachungsstatus?

Agilität – agiles Projektmanagement – kann nicht befohlen werden. Sicher nicht mit nachhaltigem Erfolg. Agiles Projektmanagement baut auf Überzeugung auf. Der erfolgreiche Einsatz basiert auf Verstand, Offenheit, Verantwortungsbewusstsein, Fachwissen und dem Engagement jedes Einzelnen.

Agiles Projektmanagement und dessen Wirkung auf die Organisation

Von den gelebten (auch agilen) Werten im Projekt ist der Weg in die Organisation dann sehr nahe – und manchmal auch sehr weit. Spurlos jedoch garantiert nie. Platzieren wir das Projekt gedanklich in der Mitte des Systemkontext-Digramms (Projekt entspricht dann dem System), so gehört die Unternehmung in den Systemkontext. Die Zusammenarbeit und die Interaktionen vom System mit dem Systemkontext („stabile“ Stammorganisation) ist einer der wesentlichen Erfolgsfaktoren für die Zielerreichung in anspruchsvollen Projekten. Durch agiles Projektmanagement – vielleicht wäre Projektführung die passendere Bezeichnung (Management: planen, koordinieren, anweisen, kontrollieren, … / Führung: Orientierung geben, Sinn und Bezug herstellen, Wahrnehmung, Lernprozesse) – verändert sich diese Zusammenarbeit und Interaktion entscheidend. Viele Unternehmen schaffen es, diese Veränderung für die Dauer
eines absehbar fertigzustellenden Projekts zu akzeptieren. Doch wie sieht es mit einer nachhaltigen Veränderung aus? Gelingt es dem Unternehmen diesen Weg zu gehen, ist der Wille und die Kraft dazu da? Unabhängig der Antwort auf diese Frage, die Wirkung eines agilen Projektansatzes wirkt sich entscheidend auf die Organisation aus.

 

Übersicht zu Techniken, Muster und ModelleAPM2

Planungswand / Planungsworkshop

Die Planungswand unterstützt die Projektplanung innerhalb der Teams und zieht die Mitglieder in den Prozess der Planung mit ein. Die Planungswand sollte möglichst zentral, zugänglich und bei jedem Team-Meeting vor Ort sein.

Mit dem Planungsworkshop wird mit vernünftigem Aufwand viel Wissen zu einem zu planenden Vorgang gewonnen. Dies erscheint zweckmässig, wenn noch wenig Wissen (typischerweise die ersten Versionen eines Plans) vorhanden ist und mehrere Personen beteiligt werden sollen. Ein mögliches Vorgehen:

  • Ausgangsbasis klären (kurz halten, Informationen austauschen, Informationen des Auftragegebers weitergeben)
  • Ersten Plan „parallel“ erstellen (unabhängig durch die Beteiligten, Identifikation von Abhängigkeiten, ersten groben Plan erstellen)
  • Gegenseitige Vorstellung (Individuelle Pläne der Reihe nach vorstellen, (noch) keine Kritik üben, VISUALISIEREN)
  • Diskussion (freie Diskussion und Weiterentwicklung der Planungsideen, Vor- und Nachteile diskutieren, Fragen klären)
  • Protokollieren (möglichst neutral die diskutierten Punkte „stichwortartig“ notieren)
  • Gemeinsam einen neuen Plan erstellen (idealerweise geführt durch einen neutralen Moderator)
  • Offene Fragen und erkannte Risiken abgleichen (da kommt das Protokoll wieder zur Hand, nicht alles muss vollständig bereinigt werden -> es ist eine Planung)
  • Plan fertigstellen und kommunizieren

Burn-down-Chart

Beim Burn-down-Chart wird auf der x-Achse der zeitliche Fortschritt, auf der y-Achse der Umfang der noch zu erledigenden Arbeiten aufgeführt. Bekannt ist dieser Burn-down-Chart bei Scrum, der Einsatz kann jedoch auch ausserhalb von Srcum zweckmässig sein. Der Planungsfortschritt wird mit der tatsächlichen Menge an erbrachter Leistung und den geplant noch zu erledigenden Arbeiten dargestellt.

Staffelholzträger

Bevor Sie den Einsatz der Technik Staffelholzträger zur Verhinderung von Terminverzügen vorsehen, bitte ich Sie, sich intensiv mit den Werten und deren Bedeutung (siehe erster Titel) auseinanderzusetzen. Staffelholzträger wird die Person, welche aktuell mit ihrer eigenen Arbeit andere Teammitglieder entscheidend beim Projektfortschritt behindert oder behindern könnte. Also die Person mit der aktuellen Arbeit auf dem kritischen Pfad. Diese Technik hilft, die Rahmenbedingungen immer wieder zu prüfen und die Aufmerksamkeit auf bestimmte Tätigkeiten zu fokussieren. Und machen Sie keine Wissenschaft daraus. Projekte sind nur bedingt planbar, also darf es auch mal der aktuell wahrscheinlichste Staffelholzträger sein.

Produktkarton

Mit dem Produktkarton beschreibt das Team auf beschränkt zur Verfügung stehendem Raum die wichtigsten Zielsetzungen und
Vorstellungen des zu erstellenden Produkts. Dies hilft einerseits sich auf das Wesentliche zu konzentrieren, APM3andererseits dient es jedoch bereits in einer frühen Phase erste Anforderungen und Features zu ermitteln. Sich nicht ergänzende Zielsetzungen können sichtbar gemacht werden. Natürlich verfügt der Produktkarton auch über eine symbolischen Wert und eignet sich für die gemeinsame Fokussierung und Zusammenarbeit. Der Produktkarton sollte dann auch gut sichtbar aufgestellt werden.

Feature

Wir unterscheiden zwischen Produkt- und Iterationsfeature. Ein Produktfeature bündelt mehrere Anwendungsfälle (Use Case, UC) zu einem sinnvollen Ganzen. Es repräsentiert ein Leistungsmerkmal des zu erstellenden Produkts. Es beschreibt eine Funktionalität, welche dann auch testbar ist. Ein planungsrelevantes Produktfeature:

  • ist iterationsunabhängig
  • bezieht sich auf genau ein Produkt, bei uns ein Softwareprodukt
  • bildet die höchst-mögliche Ebene einer hierarchischen Zerlegung

Ein Iterationsfeature repräsentiert geplante Ausbaustufen eines oder mehrerer zusammengehöriger Anwendungsfälle. Ein planungsrelevantes Iterationsfeature:

  • wird genau einem Produktfeature zugeordnet
  • wird genau einer Iteration zugeordnet
  • gehört immer genau zu einem Release

User Story

Die User Story beschreibt anhand einer „Geschichte“ ein bekanntes Bedürfnis eines Users / Anwenders. Die Sprache ist dabei bewusst einfach und
natürlich gehalten, auf Fachbegriffe sollte soweit möglich verzichtet werden. Die User Story ist bedeutend weniger detailliert als der Use Case und legt den Schwerpunkt auf das wirklich wichtige.

Eigene Erfahrungen zeigen, dass der Umgang mit User Stories bei Usern einfacher und beliebter ist mit als Use Cases, APM4insbesondere der gemeinsame Austausch zu den Stories erscheint
kommunikativ besser zu gelingen. Beispiel:

<<Ich in der Rolle als Projektleiter erwarte, dass wenn Teilprojektleiter die Projektplanung verändern, das vor der Freischaltung eine Genehmigung durch mich oder meinen Stellvertreter erfolgt.>>

Ergänzt wird die User Story mit einem aussagekräftigen Titel und den Akzeptanzkriterien (an was und wie messe ich den Erfolg der Umsetzung?).

Iteration

Der Begriff stammt eigentlich aus der Mathematik. Im Projektmanagement verstehen wir unter Iteration eine Wiederholung eines definierten Zyklus (wie bspw. Planung, Analyse, Entwurf, Implementierung, Test). Im agilen Projektmanagement werden von der Iteration ausgehend diverse Aufgaben abgeleitet. Die Iterationskapazität bezeichnet den Aufwand der innerhalb einer Iteration vom Projektteam geleistet werden kann. Der Iterationsplan dient der Gesamtübersicht über den geplanten Zuwachs an Funktionen.

Jourfix

Jourfix beschreibt einen regelmässig (in der Regel wöchentlich) stattfindenden Termin mit beispielsweise den Projektleitern des Kunden und des Auftraggebers. Mit dem Jourfix können Informationen ausgetauscht, Entscheidungen vorbereitet, Vorgehensweisen koordiniert und die Fortschritte kontrolliert werden. Den am Projekt beteiligten Personen soll die Möglichkeit offen stehen, zu Handen des Jourfix Informationen vorzulegen oder Entscheidungen anzufordern.

Retroperspektive

Achtung, die Retroperspektive ist nicht als Meilenstein, Prüfpunkt oder Review gedacht. Es geht nicht (nur) um die erreichten Zielen und den aktuellen Fortschritt im Projekt. Es geht bei der Retroperspektive um das gemeinsame lernen aus den bisherigen Arbeiten und Tätigkeiten. Die erzielten und nicht erzielten Ergebnisse werden kritisch hinterfragt.

  • Was hat sich bewährt, was hat nicht gut funktioniert?
  • Was lief gut, was weniger?
  • Was müssen und was wollen wir verbessern?
  • Wie gehen wir die Verbesserungen an?

Retroperspektiven können grundsätzlich auf allen Ebenen stattfinden. In der Projektleitung, bei den Teamleitern, im Security-Team oder im Architektur-Team.

Use Case

Der Use Case (= Anwendungsfall) beschreibt einen zusammenhängenden Arbeitsablauf aus der Sicht der Akteure. project_managerDer Use Case definiert das gewünschte Verhalten des Systems je nach Eingabe oder vorangehendem Ereignis. Die Methode beschreibt eine skalierbare, agile Technik zur Entwicklung von Anforderungen, mit denen die inkrementelle Systementwicklung gesteuert werden kann. Im Requirements Engineering bestehen einige Möglichkeiten für die Notation von funktionalen Anforderungen. Eine bekannte und oft eingesetzte ist dabei UML 2. Ein Use Case ist ein Vertrag zwischen den Stakeholdern eines Systems hinsichtlich des Systemverhaltens. Ein vollständiger Use Case besteht aus mindestens den Elementen „Beschreibung“ und „Ablaufdiagramm“, optional stehen Zustands- und Sequenzdiagramme zur Verfügung. Eine Use Case Struktur kann wie folgt aussehen:

  • Titel, Kurzbeschreibung
  • Zielsetzung (dieses Use Cases)
  • Actor (Auslöser des Use Cases)
  • Auslöser (Grund, wie kommt es zur Ausführung des Use Cases)
  • Vorbedingung
  • Szenarien
  • Ergebnis (welche Information werden vom Use Case geliefert)
  • Ausführungshäufigkeit (wie oft)
  • Nicht funktionale Anforderungen an diesen Use Case

Use Case Points

Analysten prognostizieren ein jährliches Wachstum von [Capgemini, 2007] 5.6% im Bereich der Entwicklung von Individualsoftware. Die Abschätzung des Aufwands für die Entwicklung solcher Projekte ist mit einigen Unsicherheiten verbunden. Standardisierte Schätzmethoden können die beeinflussenden Aspekte nur bedingt erfassen. Trotzdem muss zu einem frühen Zeitpunkt eine Aufwandschätzung erfolgen. Die Use Case Points Methode ist eine Schätzmethode. Die ursprüngliche Methode von Gustav Karner (Diplomarbeit anfangs der 90er Jahre) wurde unter anderen von der Credit Suisse, Ericsson und IBM weiterentwickelt. Für jeden Use Case wird die Komplexität anhand der einzelnen Transaktionen (1-3 = einfach, 3-7 = mittel, >7 = komplex) klassifiziert. Im zweiten Schritt werden die Actors bewertet, die den Use Cases zugeordnet sind (bspw. API = einfach, Protokoll (TCP/IP) = mittel, GUI = komplex). Im letzten Schritt werden weitere Einflüsse wie Effizienz, Anforderungen an die Sicherheit, Installationsaufwand oder Portabilität einzeln bewertet. Die Use Case Points ergeben sich aus der Multiplikation der Ergebnisse der drei Schritte.

Agiler Festpreis

Der agile Festpreis wird im Vertrag auf der Basis von bekannten und abgestimmten Anforderungen festgelegt. Mit dem agilen Festpreis kann der Auftraggeber Anforderungen flexibel anpassen und abändern. Damit dies funktioniert ist ein gegenseitiges, gutes Vertrauen eine wichtige Voraussetzung. Zudem hat der Auftragnehmer eine Sicherheit bezüglich des Umsatzes und die Chance auf höhere Gewinne wenn der die Anforderungen effizient und günstiger als geplant umsetzen kann. Das traditionelle Change Management kann bei Bedarf mit dem agilen Festpreis kombiniert werden.

Projektsponsorentreffen

Regelmässig stattfindendes Meeting (Treffen) mit Personen, welche das Projekt unterstützen und fördern. Das Projektsponsorentreffen dient dem Austausch von Hinweisen, Informationen, wohl-wollend-kritische Betrachtungen, APM5zusätzlichen Perspektiven und dem Erfahrungsaustausch. Integrieren Sie Projektsponsoren auch mit dieser Technik.

Agiles Projektmanagement und die mögliche Erfolgsfaktoren

  • In regelmässigen Abständen einen neuen Release entwickeln
  • Der zukünftige Anwender testet Features → Feedback
  • Aufgaben für nächsten Sprint werden mit den Anwendern festgelegt
  • Priorisierung der Aufgaben / Features mit den Anwendern

und …

  • wir können Features die viel bringen bevorzugen
  • für Aufgaben kann der Detail-Aufwand geschätzt werden
  • gegen das Ende des Projektes sind die wichtigsten Features implementiert
  • das Projekt kann beendet werden, wenn das Budget aufgebraucht ist

Bleiben Sie beweglich! Wenn Sie den Projekterfolg (bspw. die funktionierende Software) in den Mittelpunkt der Tätigkeiten setzen, dann erkennen Sie, dass viele Sachen „nur“ Mittel zum Zweck sind. Dazu gehören dann beispielsweise die Dokumentation, die Konzepte, die Modellierungen und Weitere. Arbeiten Sie am Mittel zum Zweck solange, wie es der Zielerreichung dient. Vergessen Sie jedoch nie, welche Ziele Sie im Projekt zu erreichen haben. Ob Sie dabei nur agiles, nur klassisches oder einen gesunden Mix einsetzen – bleiben Sie beweglich!

[Quellennachweis: APM – Agiles Projektmanagement, Erfolgreiches Timeboxing für IT-Projekte, Bernd Österreich und Christian Weiss, 1. Auflage 2008]