Was ist Agiles Projektmanagement?

Die Entwicklung von Software ist ein klassischer Fall für Projekte: neben den Randbedingungen wie Kosten, Zeit und Leistung haben solche Projekte ganz besonders den Faktor „neuartig“ und „risikoreich“ als Kennzeichen. Einer der vielfältigen Gründe dafür ist, dass man Software nicht „angreifen“ kann und es damit sehr schwierig ist, beispielsweise einen Fertigstellungsgrad zu berechnen. Auch sind Fehler nicht unmittelbar erkenntlich – ein Haus, das auf dem Kopf steht, wird man unschwer als fehlerhaft erkennen, bei Software ist dies nur durch aufwändige Überprüfungen möglich.

Da in der Software-Entwicklung trotz vorhandener Engineering-Methoden seit den 1960er-Jahren die Ergebnisse von Entwicklungsprojekten immer noch unbefriedigend waren, haben sich Anfang der 2000er-Jahre einige Personen zusammengeschlossen und das Agile Manifest erstellt:

Aus diesem Ansatz heraus hat sich auch das agile Projektmanagement entwickelt.

Agil bedeutet laut Duden „flink, wendig, beweglich, rege“. Der agile Gedanken hat den Grundsatz „so wenig wie möglich, so viel wie nötig“, der leider auch oft missverstanden und missbraucht wurde, nämlich indem einige Personen die falsche Meinung vertraten, deshalb beispielsweise keine Dokumentationen erstellen zu müssen, weil „dies ja nicht so wichtig sei“.

Die agile Idee beruht zunächst auf der Vorgangsweise des klassischen Projektmanagements:

• Projekt planen
• Projekt führen und laufend überwachen
• Projekt abschließen

Man nennt dies auch ein antizipatives Vorgehen, d.h. man geht davon aus, „alles“ zu wissen und daher ein Projekt in einem vorgegebenen Rahmen durchführen zu können. Beim agilen Projektmanagement kommen jedoch einige wesentliche Aspekte hinzu:

• Projekt laufend planen
• Projekt führen und laufend überwachen

• Kontinuierliches Risikomanagement und Qualitätsmanagement durchführen
• Auf Veränderungen und Anpassungen rasch reagieren
• Auf Kundenzufriedenheit und motivierte Teams besonders achten
• Angemessen handeln
• Projekt abschließen

Dies wird auch als adaptives Vorgehen bezeichnet. Agiles Projektmanagement erfordert somit nicht weniger, sondern mehr Aufmerksamkeit und Aktivitäten als das klassische Projektmanagement. Es kann jedoch mit den richtigen Voraussetzungen erfolgreichere Ergebnisse liefern, als dies mit einem klassischen Projektmanagement der Fall wäre.

Was sind die wichtigsten Hintergründe?

Ein Hauptgrund, warum Projekte schwierig und herausfordernd sind, ist, dass der Weg zum Ziel nicht klar ist. Auf diesem Weg gibt es eine Menge an Unwägbarkeiten – Risiken, die gemanagt werden sollen, Unklarheiten, zu nehmende Hürden und mit hoher Wahrscheinlichkeit auch Änderungen und neue Erkenntnisse, die wiederum Einfluss auf das Ergebnis haben. Und es entsteht etwas Neues, etwas noch nicht da Gewesenes – ansonsten wäre es ja kein Projekt, sondern ein „normaler Auftrag“.

In den bisherigen Modulen sind wir davon ausgegangen, dass es für die zu erledigenden Arbeitspakete Schätzungen gibt, wie lange es in Stunden oder in Tagen dauert, bis das jeweilige Arbeitspaket erledigt ist.

Nun handelt es an sich bei einer Schätzung um einen Blick in die Zukunft. Es ist klar: je kleiner ein Arbeitspaket ist und je mehr Erfahrung vorliegt, wie das Arbeitspaket erledigt werden kann, desto genauer werden die Schätzungen. 

Es bleibt aber eine Ungewissheit, ob man eine Aufgabe in genau so und soviel Stunden erledigen kann oder nicht. Dazu kommt, dass eine Planung, die ja auf Schätzungen basiert, und die mehr als etwa 6 Monate in die Zukunft schaut, nur mehr sehr grob durchgeführt werden kann. 

Weiter sind wir davon ausgegangen, dass der zu erbringende Leistungsumfang klar ist, sprich überlegt wurde, dokumentiert und geprüft wurde und eine Umsetzbarkeit bestätigt wurde.

Dem ist aber in der Realität nicht so. Es gibt meist durchaus einigermaßen klare Vorstellungen, was am Ende des Projekts herauskommen soll – allerdings ist es kaum möglich, alle notwendigen Details bereits im Vorfeld zu wissen und zu berücksichtigen. 

Dazu kommt, dass Projekte durchaus oft ein, zwei oder mehr Jahre dauern und sich in dieser Zeit auch viele Voraussetzungen ändern können, von denen man zu Beginn der Überlegungen ausgegangen ist. Das heißt, dass es mit hoher Wahrscheinlichkeit im Verlauf eines Projekts zu Änderungen kommen wird, die unterschiedlich starke Einflüsse auf den ursprünglich geplanten Leistungsumfang haben werden. Es macht damit auch gar keinen Sinn, in der Phase der Definition des Leistungsumfangs bereits alles bis ins kleinste Detail festzulegen, weil davon ausgegangen werden kann, dass sich bei einer Projektlaufzeit von etwa über 6 Monaten mit Sicherheit das Endergebnis vom ursprünglichen Plan unterscheiden wird.

Auf diese Aspekte nimmt das agile Projektmanagement Rücksicht und bindet die Ungewissheiten bewusst in den Prozess mit ein. Insbesondere nimmt die agile Vorgangsweise für sich in Anspruch, auf Änderungen schnell und flexibel reagieren zu können. Gleichzeitig erfordert die agile Vorgangsweise sowohl reife Projektteams als auch reife Kunden.

Das bedeutet nicht, dass sich konventionelles und agiles Projektmanagement gegenseitig ausschließen – schließlich basiert ja agiles Projektmanagement auf dem konventionellen Ansatz – sondern a) situationsspezifisch eingesetzt werden muss und b) sinnvoll integriert werden kann:

Üblicherweise wird ein Projekt in einem vorgegebenen Zeit- und insbesondere auch Kostenrahmen von einem Kunden in Auftrag gegeben. Wenn nun bewusst Änderungen in Kauf genommen werden, welche Auswirkungen auf den Zeit- und/oder Kostenrahmen mit sich bringen, ist dies ein Widerspruch zu der strikten Vorgabe zur Projektbeginn. Setzt man daher in solchen Situationen ein agiles Projektmanagement ein, müssen sich alle Projektbeteiligten dieser Situation und der Vorgangsweise bewusst sein.

Was gehört zu den Grundlagen?

Agiles Projektmanagement macht besonders unter folgenden Voraussetzungen Sinn:

• Es handelt sich um ein Projekt einer kleinen bis mittleren Größenordnung
• Es ist eine kurze Time-to-Market erforderlich
• Es handelt sich um ein Projekt ohne sicherheitskritische Elemente
• Es handelt sich um ein änderungsanfälliges Projekt
• Im Projekt sind ein reifes Team und ein reifer Kunde vorhanden
• Die Teamgröße beträgt etwa 7 ± 2 Personen

Überschreitet ein Projekt eine bestimmte Größenordnung, wird man mit einem Team von 7 ± 2 Personen meist nicht mehr auskommen. Überschreitet die Teamgröße die 7 ± 2 Personen, geht die Flexibilität durch den drastisch steigenden Kommunikationsaufwand verloren. Eine Möglichkeit ist es dann, entsprechend kleine Subteams zu bilden.

Bei sicherheitskritischen Projekten sind strengere Voraussetzungen als bei „normalen“ Projekten gegeben. Meist erfordern sicherheitskritische Projekte auch eine sehr genaue Dokumentation und eine spezifische Vorgangsweise.

Welche wichtigen Begriffe muss du kennen?

Wir beziehen uns bei den folgenden Begriffen und Ausführungen auf eine agile Methode namens SCRUM. SCRUM ist laut Definition „ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern“. (

SCRUM hat sich als eine weit verbreitete Methode zur Führung agiler Projekte etabliert und umfasst die folgenden Rollen:

Was ist ein Team?

• Ein Team hat von jeder benötigten Qualifikation einen Spezialisten
• Das Team übernimmt die Verantwortung für die Zielerreichung
• Während einer Iteration organisiert sich das Team selbst und wählt dafür die Methoden aus
• Das Team ist idealerweise räumlich eng beisammen

Was ist ein Agile Master (SCRUM Master)?

• Der Agile Master ist das Bindeglied zwischen Team und Product Owner und unterstützt diese zur Zielerreichung
• Der Agile Master sorgt dafür, dass jede funktionale Erweiterung auslieferungsreif ist
• Der Agile Master verwaltet die Fortschrittsinformationen und schafft Transparenz für alle Beteiligten
• Der Agile Master moderiert die Meetings 

Was ist ein Product Owner?

• Der Product Owner ist eine zentrale Stelle im agilen Management
• Der Product Owner legt die gemeinsamen Ziele fest, welche das Team zusammen mit ihm erreichen muss
• Der Product Owner setzt die Prioritäten der Elemente des Product Backlogs fest
• Der Product Owner ist das Bindeglied zwischen Kunden und dem Projektteam und ist für den Projekterfolg verantwortlich

Um auf Änderungen rasch und flexibel reagieren zu können, entstehen in einem agilen Umfeld alle 4 Wochen brauchbare und funktionierende Ergebnisse. Dieser Zeitraum wird als Iteration oder in SCRUM als Sprint bezeichnet.

Was ist eine Iteration (Sprint)?

• In einer Iteration werden vom Team die im Backlog festgelegten und zugeordneten Anforderungen umgesetzt
• Eine Iteration endet in einem auslieferbaren Produkt
• Eine Iteration beginnt mit einem Planungsmeeting und endet mit einem Review meeting
• Während einer Iteration darf das Backlog für die Iteration nicht geändert werden
• Das Team übernimmt gemeinsam die Verantwortung, dass die Ziele der Iteration erreicht werden

Innerhalb einer Iteration (eines Sprints) gibt es tägliche Abstimmungsmeetings zu einem fixen Zeitpunkt mit der Dauer von typisch 15 Minuten. Dabei werden die Aktivitäten des Teams synchronisiert und die Planung für die nächsten 24 Stunden abgestimmt. Mit diesem „Daily Scrum Meeting“ erhöht das Team die Wahrscheinlichkeit, dass das Sprint-Ziel erreicht wird.

Was ist ein Backlog?

Damit bekannt ist, woran gearbeitet wird, existiert ein sogenanntes Backlog. Das Haupt-Backlog, das Product Backlog, ist eine geordnete Liste von allem, was im Endprodukt enthalten sein kann und stellt damit die einzige Anforderungsquelle dar.

Im Product Backlog zeigt sich die Flexibilität des agilen Ansatzes: es ist niemals vollständig und beinhaltet zu Beginn nur die anfangs bekannten und am besten verstandenen Anforderungen. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter und lebt so lange wie das dazugehörige Produkt.

• Das (Product) Backlog enthält sämtliche priorisierten Anforderungen an das Gesamtsystem (ursprüngliche Anforderungen, abgeleitete und geänderte Anforderungen, funktionale und nicht-funktionale Anforderungen)
• Das (Product) Backlog wird ausschließlich vom Product Owner verwaltet und priorisiert

Aus dem Product Backlog werden für jede neue Iteration bestimmte Anforderungen aus dem (Product) Backlog in das Backlog der Iteration (= Sprint Backlog) übertragen; diese definieren damit die Ziele der Iteration.

Grafisch lässt sich ein SCRUM-Prozess wie folgt darstellen:

Wie ist der Ablauf?

Die Auflistung der adaptiven versus der antizipativen Vorgangsweise gibt bereits Einblick, worin sich konventionelles Projektmanagement von einem agilen Ansatz unterscheidet:

Konventionelles PM	Agiles PM
Projekt planen	Projekt laufend planen
Projekt führen und laufend überwachen	Projekt führen und laufend überwachen
	Kontinuierliches Risikomanagement und Qualitätsmanagement durchführen
	Auf Veränderungen und Anpassungen rasch reagieren
	Auf Kundenzufriedenheit und motivierte Teams besonders achten
	Angemessen handeln
Projekt abschließen	Projekt abschließen

Was ist die Planung?

Bereits in den anderen Modulen dieses Lehrgangs wurde darauf eingegangen, dass Planung – auch im konventionellen Projektmanagement – nicht mit der Startphase abgeschlossen ist, sondern die Projektdurchführung ständig begleitet. Beim konventionellen Projektmanagement sind diese Planungstätigkeiten jedoch eher auf Verfeinerung und auf Änderungen konzentriert, während die Planung im agilen Projektmanagement ein ständiger Task ist.

Planung kommt hier – getrieben durch die iterativen Zyklen – mehrfach und regelmäßig vor.

Was ist Sprint Planning?

Im Sprint Planning wird gemeinschaftlich die Arbeit für den kommenden Sprint geplant. Bei Sprints von 30 Tagen ist das Spring Planning auf 2 x 4 Stunden begrenzt. 

Im ersten Teil des Sprint Planning beschreibt der Product Owner das Ziel des Sprints und die zugehörigen Einträge im Product Backlog. Das Team erstellt eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll. Gemeinsam wird ein Verständnis über die Arbeitsinhalte des Sprints erarbeitet.

Im zweiten Teil des Sprint Planning überlegt das Team, wie die ausgewählten Anforderungen aus dem Product Backlog in Tasks umgewandelt werden können. Daraus entsteht das Sprint Backlog, welches neben den ausgewählten Einträgen aus dem Product Backlog auch den Umsetzungsplan enthält. Es handelt sich somit um einen ausreichend detaillierten Plan, der auch während des Sprints angepasst wird.

Was ist Daily Scrum?

Das Daily Scrum Meeting dauert 15 Minuten, in denen das Entwicklungsteam seine Aktivitäten synchronisiert und die Planung für die nächsten 24 Stunden vornimmt. Dabei wird die Arbeit seit dem letzten Daily Scrum überprüft und eine Prognose jener Arbeitsergebnisse erstellt, die bis zum nächsten Daily Scrum erreicht werden könnten.

Im Daily Scrum überprüft das Team seinen Fortschritt in Richtung des Sprint-Ziels und den Trend bei der Abarbeitung der Sprint Backlog-Einträge. Detaillierte Diskussionen, Anpassungen oder Umplanungen finden außerhalb des Daily Scrum Meetings statt.

Was ist Sprint Retrospektive?

Die Sprint Retrospektive ist im eigentlichen Sinn keine Planungs-Sitzung, sie bietet dem Team jedoch die Gelegenheit, sich selbst zu überprüfen und daraus einen Plan für den kommenden Sprint zu erstellen, wie die Arbeitsweise des Teams verbessert werden kann.

Was ist der Vergleich mit konventionellen Methoden?

Bei konventionellen Methoden wird über die gesamte Projektlaufzeit von meist mehreren Monaten bis zu einigen Jahren ein zu Beginn erstellter Plan verfolgt und einem Vorgehensmodell gefolgt. Das Controlling und damit auch die laufende Adaptierung des Plans erfolgt regelmäßig, typisch zumindest einmal pro Monat.

Bei agilen Vorgehensweisen wird das Produkt nach und nach entwickelt und in Perioden von jeweils ca. 30 Tagen zum Feedback an den Product Owner ausgeliefert.

Vergleicht man die Vorgehensweise der obigen Abbildung, so stellt sich heraus, dass es sich bei der agilen Vorgehensweise im Grund nach um denselben Ablauf wie in der konventionellen Vorgehensweise handelt – auch innerhalb eines Sprints müssen die Aufgaben wie Entwurf, Implementierung und Test durchgeführt werden, bevor es zu einem auslieferbaren Produkt-Inkrement kommt. Das Controlling wird in SCRUM durch das Sprint Planning „ersetzt“.

Der wesentliche Unterschied zwischen den beiden Vorgehensweisen liegt eben darin, dass der Entwicklungszyklus im agilen Projektmanagement in kleinen Schritten erfolgt, sich laufend wiederholt, jedes Mal am Ende eines Sprints ein verwendbares Produkt entsteht und ein Review die Möglichkeit zur Verbesserung gibt.

Was ist Risikomanagement?

Aus Sicht des Risikomanagement-Ablaufs besteht kein Unterschied zwischen einem konventionellen und einem agilen Vorgehen. In beiden Fällen ist der Zyklus Risikoidentifizierung – Risikobewertung und Risikoanalyse – Entwicklung von Maßnahmen zur Risikobewältigung sowie die Risikoverfolgung laufend durchzuführen (vergleiche z.B. Risikomanagement).

Agile Methoden haben jedoch den Anspruch, Risiken in Projekten zu minimieren, d.h. sie verfolgen das Prinzip der Risikoverminderung. Um dies zu erreichen, kann die Eintrittswahrscheinlichkeit und/oder das Schadensausmaß und damit auch das Risiko vermindert werden.

SCRUM erreicht dies durch folgende Ansätze:

Was ist Sprint-Dauer?

Sprints sind auf einen Zeitraum von 30 Tagen beschränkt. Wenn der Zeithorizont eines Sprints zu groß gewählt wird, kann sich die Definition des Ergebnisses ändern, die Komplexität ansteigen und sich damit auch das Risiko erhöhen. 

Die Ergebnisse von Sprints, die Produkt-Inkremente, sind vollständig verwendbar und werden einmal monatlich vom Auftraggeber und dem Product Owner als dessen Vertreter auf Einsetzbarkeit und Übereinstimmung mit den Anforderungen beurteilt. Sprints reduzieren damit das maximale Risiko eines fehlerhaften Ergebnisses auf die Kosten eines Monats.

Was ist Transparenz?

Scrum basiert auf Transparenz. Entscheidungen zur Wertoptimierung und Risikokontrolle werden auf der Basis des festgestellten Zustands der Artefakte vorgenommen. Artefakte sind dabei das Product Backlog und das Sprint Backlog sowie die nach einer Iteration vorliegenden Ergebnisse, die Produkt-Inkremente.

Dadurch, dass das gesamte SCRUM-Team mit der Unterstützung des Agile Masters an der Transparenz der Ergebnisse sowie am Verständnis des Transparenz-Begriffs arbeitet, wird erreicht, dass mit einer möglichst vollständigen Transparenz deren Überprüfung erleichtert und damit auch das Risiko vermindert wird.

Was sind Standard-Risiken?

Laut DeMarco & Lister gibt es in Softwareprojekten u.a. folgende Standard-Risiken, hier als Kernrisiken bezeichnet:

• Fehlerhafter Zeitplan
• Inflation der Anforderungen
• Ausfall von Mitarbeitern
• Mangelnde Arbeitsleistung

Diese Kernrisiken lassen sich 1:1 auch auf alle anderen Arten von Projekten umlegen. Agile Methoden wie SCRUM begegnen diesen Kernrisiken auf folgende Art und Weise:

Was ist ein fehlerhafter Zeitplan?

Beim Einsatz von agilen Methoden ist durch die iterative und inkrementelle Vorgangsweise schon zu Projektbeginn klar, dass es zwar einen Zeitrahmen für das Projekt geben wird, aber dass der exakte Endtermin und der dann enthaltene Produktumfang nicht vorherbestimmt werden können, sondern sich das Produktergebnis im Laufe des Projekts entwickelt. 

Handelt es sich um neuartige Aufgabenstellungen oder unbekannte Technologien, so ist eine Genauigkeit der Zeit- bzw. Aufwandsschätzung von ¼ bis zu einem Faktor 4 zu Beginn eines Projekts schon als gut zu bezeichnen (!). Die Genauigkeit nimmt im Laufe der Projektdauer zu, da die Anforderungen immer besser bekannt sind und auch immer besser verstanden werden:

Das Risiko, dass der Umfang eines Projekts falsch eingeschätzt wird und damit der Zeitplan fehlerhaft ist, bleibt nach wie vor – durch den agilen Ansatz ist jedoch von vornherein klar, dass eben Zeit und/oder Leistungsumfang nicht zu 100% vorbestimmt werden können (vergleiche Einflüsse in der Projektabwicklung).

Was ist Inflation der Anforderungen?

Das Produktergebnis zu Projektende wird sich mit hoher Wahrscheinlichkeit von dem unterscheiden, was zu Beginn als Anforderungen auf dem Tisch lag. Das hat insbesondere bei mittleren bis längeren Projekten (Größenordnung > 6 Monate) mit der parallel laufenden Änderung der Umgebung zu tun, in der das Produkt eingesetzt werden soll, womit sich auch die Anforderungen laufend ändern.

Im klassischen Projektmanagement begegnet man dieser Tatsache mit einem Änderungsmanagement, wobei Änderungen in deren Auswirkung auf Zeit, Kosten und Leistungsumfang beurteilt werden (vergleiche Change Management). In agilen Projekten ist von vornherein klar, dass Änderungen etwas Normales sind und einmal monatlich in die Sprint-Planung einfließen. Zusätzlich sind in einem gut geführten Product Backlog jederzeit der Status der Anforderungen sowie vorgenommene Änderungen für alle ersichtlich (Stichwort  „Transparenz“).

Was ist Ausfall von Mitarbeitern?

Es ist nichts ungewöhnliches, dass Mitarbeiter während einer Projektlaufzeit nicht mehr zur Verfügung stehen oder ausfallen, sei es durch Krankheit oder Kündigung. Das dadurch entstehende Problem ist nicht nur der Wegfall einer Ressource, sondern die dadurch entstehende Zeitverzögerung durch Suche nach Ersatz und der benötigten Einarbeitungszeit neuer Mitarbeiter.

Im konventionellen Projektmanagement begegnet man diesem Risiko durch den Einbau von Pufferzeiten. In agilen Methoden ist das natürlich ebenso – beispielsweise für krankheitsbedingte Ausfälle – eine vernünftige Strategie; gleichzeitig wird jedoch versucht, durch „motivierte Teams“ (siehe 2.4.6 Motivierte Teams) eine Fluktuation von Mitarbeitern zu minimieren.

Was ist mangelnde Arbeitsleistung?

Mitarbeiterleistungen innerhalb verschiedener Projektteams können sehr unterschiedlich sein, wobei sich die Leistung ganzer Projektteams eher ausgleicht als die Leistung einzelner Mitarbeiter innerhalb eines Teams.

Dieses Risiko ist natürlich auch mit agilen Methoden nicht unmittelbar zu ändern. Durch das Daily Scrum Meeting gibt es jedoch eine tägliche Kontrolle der Einzelleistungen im Vergleich zum Sprint-Plan, womit eine sehr kurzfristige Reaktion auf Abweichungen oder Schwierigkeiten möglich ist. Ebenso wird jedes Monat auch nach außen hin sichtbar, was das Team in diesem Zeitraum geleistet hat.

Außerdem steht hier klar die Maxime im Vordergrund, dass immer das gesamte Team für das Produktergebnis gemeinsam verantwortlich ist. Um dies zu erreichen, gibt es in SCRUM folgende Ansätze:

• (Entwicklungs-)Teams sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem (Entwicklungs-)Team, WIE es aus dem Product Backlog potentiell auslieferbare Funktionalität machen soll. 
• (Entwicklungs-)Teams sind interdisziplinär tätig. Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Produkt-Inkrement zu erstellen. 
• Scrum kennt keine Titel außer „Entwickler“ für Mitglieder des (Entwicklungs-)Teams. Dies ist unabhängig von der Arbeit, die diese Personen erledigen. Es gibt keine Ausnahmen von dieser Regel. 
• Scrum kennt keine weiteren Unterteilungen innerhalb des (Entwicklungs-)Teams, ungeachtet von bestimmten zu adressierenden Domänen, wie „Test“ oder „Analyse“. Es gibt keine Ausnahmen von dieser Regel. 
• Individuelle Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem. 

Dass diese vorausgesetzten Eigenschaften somit ein reifes Team erfordern, wurde bereits eingangs angedeutet. Aus diesen Eigenschaften ergibt sich auch die optimale Teamgröße – ein zu kleines Team kann kein Produkt-Inkrement liefern, da es nicht über alle benötigten Fähigkeiten (Analyst, Designer, Architekt, Entwickler, Systemingenieure, Tester, Spezialisten …) verfügt. Ein zu großes Team erfordert zu viel Koordination und erzeugt zu viel Komplexität, um auf diese Art und Weise gemanagt zu werden.

Was ist Qualitätsmanagement?

Qualitätsmanagement ist zwangsläufig Bestandteil jedes Projekts – muss doch laufend und am Ende überprüft werden, ob das Ergebnis den gesetzten Zielen und den vereinbarten Anforderungen entspricht.

In der Qualitätssicherung in klassischen Projekten kommt es vor, dass sich die standardisierten Prozesse an großen und anspruchsvollen Projekten orientieren und für kleine und mittlere Projekte nicht angemessen angepasst werden können. Außerdem wird durch eine starke Prozessorientierung alleine noch keine Produktqualität sichergestellt. Ist zusätzlich eine externe Überprüfung des Qualitätsmanagements erforderlich (beispielsweise um die Einhaltung von vorgegebenen Prozessen zu auditieren), müssen meist zusätzliche Dokumente erstellt werden, die für das Projektteam selbst nicht hilfreich sind.

In agilen Projekten ist die Dokumentation zweitrangig (vergleiche Agiles Manifest: „Funktionierende Software mehr als umfassende Dokumentation“). Dies hat zu völlig falsch verstandenen Interpretationen geführt wie beispielsweise, dass eine Dokumentation überhaupt nicht mehr notwendig sei.

Für die Qualitätssicherung, für die Überprüfung eines Produkts gegenüber den Anforderungen, als Bedienungsanleitung bzw. Hilfetext für Benutzer oder für die langfristige Dokumentation einer Architektur ist immer eine Dokumentation notwendig. Die Agilität liegt hier darin, dass so wenig wie möglich und gleichzeitig so viel wie nötig Dokumentation erstellt wird.

Ein zentraler Punkt von SCRUM ist die „Definition of Done“. führt dazu aus:

„Es müssen alle verstehen, was „Done“ bedeutet, sobald ein Product Backlog-Eintrag oder ein Produkt-Inkrement als „Done“ bezeichnet wird. … Alle Teammitglieder müssen ein gemeinsames Verständnis davon haben, wann eine Arbeit fertiggestellt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition of Done des Teams und wird dazu verwendet festzustellen, wann die Arbeit an einem Produkt-Inkrement fertig ist. 

Die gleiche Definition leitet das (Entwicklungs-)Team bei der Entscheidung, wie viele Product Backlog-Einträge es während des Sprint Plannings selektieren kann. Der Zweck eines jeden Sprints ist es, Inkremente potentiell auslieferbarer Funktionalität zu liefern, die der aktuellen Definition of Done des Teams entsprechen.

Von gereiften Scrum Teams wird erwartet, dass sie ihre jeweilige Definition of Done erweitern, um strengere Kriterien für eine höhere Qualität sicherzustellen. Jedes einzelne Produkt oder System sollte eine Definition of Done haben, welche den Standard für jegliche daran durchgeführte Arbeit darstellt“.

Diese gemeinsam erstellte und im Projektverlauf weiterentwickelte Definition von „Fertig“ führt dazu, dass es beispielsweise nicht mehr möglich sein wird, eine Funktionalität in einem Produkt-Inkrement auszuliefern, die nicht ausreichend getestet wurde.

„Der Agile Master bestärkt das Team darin, innerhalb des Scrum Prozessrahmenwerks seine Entwicklungsprozesse und -praktiken zu verbessern, um im kommenden Sprint effektiver und befriedigender arbeiten zu können. In jeder Sprint Retrospektive erarbeitet das Scrum Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Definition of Done“.

Wird also beispielsweise in einer Sprint Retrospektive festgestellt, dass die gewünschte Qualität mit der bisher getroffenen Vereinbarung von „Done“ noch nicht erreicht werden konnte, erarbeitet das Team gemeinsam eine erweiterte bzw. geänderte Definition von „Done“ und setzt diese unmittelbar beim folgenden Sprint Planning für die Iterationsplanung ein. Damit wird wiederum gewährleistet, dass eine höhere Qualität erreicht wird – sowohl im Ergebnis als auch beispielsweise in der Zeitplanung.

Was sind Reaktion auf Veränderungen?

Bei einem Projekt wird davon ausgegangen, dass sich Zeitdauer, Kosten und der damit erzielbare Leistungsumfang von vornherein festlegen lassen. Dass dem nicht so ist zeigt die Realität der meisten Projekte, die sich in Zeit- und/oder Kostenüberschreitung äußert.

ründe dafür wurden bereits genannt: es handelt es sich bei einem Projekt um etwas Neues, um etwas noch nicht da Gewesenes. Man weiß daher zu Beginn schlichtweg nicht auf Tag und Euro genau, wieviel die Entwicklung des gewünschten Endprodukts kostet.

Hinzu kommt, dass sich das Geschäftsumfeld bei längeren Projekten verändert, sodass Anpassungen die Normalität sind. Es darf ja auch nicht vergessen werden, dass, bevor es zu einem Projekt kommt, eine Vorphase im Spiel war, welche dazu diente, die Anforderungen an das gewünschte Endergebnis festzulegen. Eine solche Vorphase kann selbst wiederum viele Monate bis Jahre dauern. Es ist daher nicht verwunderlich, dass sich dann im Zuge der Umsetzung Gegebenheit ändern und diese in das Projekt einfließen.

Wenn es nun zu einem Projekt kommt, dann ist es Aufgabe des Projektmanagers, die im Projektauftrag (siehe Projektdefinition) festgehaltenen Randbedingungen auf Machbarkeit zu überprüfen und mit seiner Unterschrift „ja“ zu sagen. Er wird sich in Folge nach Kräften bemühen, den Projektumständen zu begegnen und zumindest die Parameter Kosten, Zeit und Leistungsumfang in dem vorgegebenen Rahmen zu erfüllen (siehe Einflüsse in der Projektabwicklung).

Wenn es zu Änderungen kommt, setzt das Change Management ein (siehe PM-102 Projektcontrolling). Ein ordentlich aufgesetztes und durchgeführtes Change Management macht es möglich, dass der Auftraggeber einer (meist nach oben gerichteten) Veränderung von Zeit und/oder Kosten zustimmt, wenn die Änderungen notwendig sind.

Dies klingt einfacher als es ist, denn es stellt sich immer die Frage, was eine Leistung wert ist. Mit dem Projektauftrag ist ja ein Gesamtkostenrahmen verbunden – welche Einzelleistung wieviel kostet, ist eher selten bekannt. Eine mögliche Gefahr ist daher, dass der Auftragnehmer im Zuge einer Änderung versucht, zu mehr Geld oder Zeit zu kommen, als dies eigentlich der Änderung entspricht oder resultierende Zeit- und Kostenverschiebungen dem Auftraggeber verständlich gemacht werden können.

Die agilen Methoden gehen von vornherein darauf ein, dass es Änderungen gibt – siehe auch agiles Manifest „Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans“. Nun ist dies natürlich kein Freibrief für völliges Chaos und Agieren jenseits jeglichen roten Fadens. Es ist lediglich eine Maxime, die klar macht, dass es Änderungen gibt und diese Vorrang vor einem einmal ausgearbeiteten Plan haben.

SCRUM unterstützt diese Vorgangsweise unter anderem wie folgt:

Zunächst ist klargestellt, dass es Änderungen gibt: „Änderungen an den Geschäftsanforderungen, Marktbedingungen oder der Technologie können Änderungen am Product Backlog nach sich ziehen“.

Änderungen spiegeln sich also im Product Backlog wieder: „Das Product Backlog ist eine geordnete Liste von allem, was in dem Produkt enthalten sein kann. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. … Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes, dessen Wertsteigerung sowie durch das Feedback des Marktes zu einer längeren, ausführlicheren Liste. Anforderungen werden nie aufhören, sich zu ändern. Daher ist das Product Backlog ein lebendes Artefakt“.

Alle Änderungen an den Anforderungen sind somit transparent und nachvollziehbar. Da der Product Owner die Schnittstelle zum Kunden darstellt, ist er auch gleichzeitig „Herr“ über die Inhalte des Product Backlog: „Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich“.

Änderungen im Product Backlog werden ja einmal monatlich zusammen mit allen anderen Anforderungen durchgesehen und fließen damit in einen der nächsten Sprints ein. Auf keinen Fall dürfen während eines Sprints Änderungen vorgenommen werden, die das Sprint-Ziel gefährden – das Team hat sich ja zur Erfüllung eines bestimmten Leistungsumfangs verpflichtet.

Hier schließt sich auch ein Stück des Kreises: agile Methoden sind für änderungsanfällige Projekte und mit einer kleineren bis mittleren Größenordnung besonders gut geeignet. Die Aussage, dass auch der Kunde = Auftraggeber unter den oben angeführten Aspekten „reif“ sein muss, bekommt hier ein besseres Verständnis

Was ist Kundenzufriedenheit?

In einem konventionellen Projekt dauert es relativ lange, bis der Auftraggeber ein Produkt oder zumindest einen Teil eines Produkts „in die Hände“ bekommt. Oft gibt es ein angreifbares oder testbares Ergebnis erst kurz vor dem Projektende, bestenfalls ein Zwischenprodukt zu dem einen oder anderen Meilenstein.

Das resultiert darin, dass Auftraggeber nach Monaten, eventuell sogar nach Jahren, ungeduldig werden können und „endlich etwas sehen wollen“. Der klassische Projektzyklus ist aber nicht unbedingt darauf ausgelegt, Zwischenprodukte zu produzieren. 

In manchen Projekten ist dies einfacher – wenn beispielsweise ein Haus gebaut wird, sind die Fortschritte klar erkennbar. Um diese Situation zu verbessern, ist es üblich, beispielsweise Prototypen zu bauen. Diese erfüllen zwei Zwecke: sie geben dem Auftraggeber eine Möglichkeit zur Beurteilung, ob die eingeschlagene Richtung den Anforderungen entspricht und sie geben dem Auftragnehmer die Möglichkeit, kostengünstig Anpassungen vorzunehmen, ohne das gesamte Produktdesign ändern zu müssen.

Die agilen Methoden liefern hier einen deutlichen Mehrwert, nämlich indem alle 30 Tage ein funktionierendes und verwendbares Produkt-Inkrement erzeugt und präsentiert wird. Dieses hat natürlich gerade zu Beginn noch nicht annähernd den vollen Funktionsumfang, es gibt aber sehr rasch die Möglichkeit, Rückmeldung zu erhalten und die Vorstellungen des Auftraggebers mit dem Produkt abzugleichen. „Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback“.

Die Kundenzufriedenheit hat zusätzlich den Aspekt, dass auf Veränderungen rasch reagiert wird und damit auf Änderungen im Umfeld Rücksicht genommen werden kann. Wir sind bisher meist davon ausgegangen, dass zu Projektbeginn „alles klar ist, wie das Endprodukt genau aussehen soll“, dem ist jedoch in der Realität nicht so. Auch dies ist ein guter Grund, agile Methoden für änderungsanfällige Projekte einzusetzen und damit in solchen Umfeldern die Kundenzufriedenheit zu steigern.

Was sind motivierte Teams?

Mit Teams und Motivation haben wir uns in PM-103 auseinandergesetzt. Eine der Aufgaben des Projektmanagers ist es, die soziale Kontrolle des Teams durchzuführen und beispielsweise für die notwendigen Hygienefaktoren zu sorgen.

SCRUM geht hier einen völlig anderen Ansatz. Das Team ist selbstorganisierend. Das Team entscheidet selbst, wie es seine Arbeit erledigt. Das Team hat alle benötigten Kompetenzen. Das Team besteht aus Profis, die am Ende eines jeden Sprints ein fertiges Inkrement übergeben, welches potentiell auslieferbar ist. Teams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen.

Das Team plant selbst seine Arbeit: „Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum Teams.“

Das Team trifft sich täglich zum Daily Scrum Meeting. Die Sprint Retrospektive bietet dem Team die Gelegenheit, sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen. In jeder Sprint Retrospektive erarbeitet das Scrum Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Definition of Done.

Dies alles ist ein doch anderer Ansatz, als er aus dem klassischen Projektmanagement her vertraut ist. Dem Team wird sehr viel Eigenverantwortung übertragen, womit die Satisfier (siehe PM-103 Motivation) „die Tätigkeit macht Spaß“ (weil gemeinsam etwas geschaffen wird und zumindest einmal im Monat ein verwertbares Ergebnis vorliegt), „es gibt Achtung und Anerkennung“ (für die geleisteten Ergebnisse nach jedem Sprint) und „Leistungs- und Erfolgsergebnisse“ sowie „Wachstum“ (durch das gemeinsame Lernen) quasi von alleine gegeben sind.

Der Agile Master unterstützt dabei das Team (5):

„Der Scrum Master dient dem Entwicklungsteam auf verschiedene Arten, unter anderem durch: 

• Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit; 
• Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Produkte; 
• Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten; 
• Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen; 
• Coachen des Entwicklungsteams in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird“.

Was bedeute angemessen handeln?

Die angemessene Handlung spiegelt sich am besten im Grundsatz „so wenig wie möglich, so viel wie nötig“ wieder.

„So wenig wie möglich“ heißt nicht, dass Elemente einfach weggelassen werden, sondern genau so viel verwendet und produziert wird, um ein Ergebnis zu erreichen. Ähnlich ist es mit „so viel wie nötig“: es wird genau das produziert, was im Product Backlog festgehalten ist und nicht mehr. Sollen Verbesserungen eingebaut werden, dann landen diese wiederum als Anforderung im Product Backlog.

Das beinhaltet gleichzeitig auch eine Gefahr: es muss doch sehr genau im Product Backlog festgelegt werden, was im Endprodukt enthalten sein soll. Will also beispielsweise ein Kunde eine Dokumentation zu einem bestimmten Thema, dann muss er das auch als Anforderung weitergeben und den Inhalt definieren.

Durch die kurzen Iterationszyklen ist es jedoch wesentlich einfacher, den Gegebenheiten und Veränderungen Rechnung zu tragen und damit kontinuierlich angemessen zu handeln.