Zum Inhalt

Einführung

Willkommen im agilen Universum

Sie haben sich entschieden die Zertifizierungsprüfung zum Certified Junior Agile Project Manager (IAPM) abzulegen und sich im Selbststudium darauf vorzubereiten? Dann sind Sie hier genau richtig. In diesem Onlinekurs lernen Sie alles, was Sie rund um Scrum wissen müssen, um in Ihrem nächsten Projekt zu glänzen und um die Prüfung zu bestehen. Also fangen wir gleich an!

Themenüberblick

Agiles Projektmanagement ist ein umfangreiches Themengebiet, weswegen wir uns in diesem Kurs lediglich auf das Thema Scrum konzentrieren. Unten sehen Sie die Kapitel dieses Kurses, welche Ihnen im Laufe Ihres Scrum-Projektes immer begegnen werden. Sie können mit den einzelnen Begriffen noch nicht so viel anfangen? Keine Sorge, dafür sind Sie hier. In den folgenden Kapiteln werden Sie alles lernen, was Sie in Ihrem künftigen beruflichen Alltag als Scrum-Team-Mitglied brauchen.

Abb. 0.1: Certified Junior Agile Project Manager (IAPM) -- Kapitelübersicht

Warum agil?

Sie sind noch skeptisch, ob der agile Projektmanagementansatz der Richtige für Sie ist? Werfen wir gemeinsam einen Blick auf mögliche Einsatzgebiete des agilen Projektmanagements.

Abb. 0.2: In welchen Bereichen kann Scrum Anwendung finden?

Falls Ihnen diese Beispiel zu speziell sind, kann Ihnen vielleicht die Stacey-Matrix dabei helfen, zu entscheiden, ob Sie Ihre zukünftigen Projekte agil oder doch lieber traditionell planen sollten. Ist der Auftrag bekannt und Sie wissen auch, wie Sie das Projekt umsetzen sollen? Dann sollten Sie den traditionellen Ansatz wählen. Wie Sie traditionelle Projekte am besten planen, erfahren Sie in unserem Onlinekurs im traditionellen Projektmanagement. Je unbekannter der Kundenwunsch und/ oder die Umsetzung ist, desto sinnvoller ist es, einen agilen Ansatz zu wählen.

Abb. 0.3: Stacey-Matrix: Projekte zwischen simpel und chaotisch

Bevor Sie beginnen...

...möchten wir Sie mit diesem Trainingssystem vertraut machen.

Am linken Rand Ihres Computerbildschirms sehen Sie die Primärstruktur. Hier finden Sie die zuvor gezeigten Themen - betrachten Sie diese als Ihre Hauptfächer. Die Elemente dieser Struktur bauen aufeinander auf, es empfiehlt sich daher, sie in chronologischer Reihenfolge durchzuarbeiten. Wenn Sie sich durch den Onlinekurs arbeiten, während Sie ein mobiles Endgerät nutzen, dann finden Sie die Primärstruktur, wenn Sie auf die drei Striche oben links tippen. Wenn Sie ein bestimmtes Thema auswählen, werden in einem Dropdown-Menü die Unterkapitel angezeigt. Hier finden Sie jeweils zwei Teile: Den Theorieteil und den Übungsteil. Im Theorieteil finden Sie alle theoretischen Inhalte, die für die tägliche Arbeit im Scrum-Projekt sowie für die Prüfung wichtig sind. Ihr neu gewonnenes Wissen können Sie im Übungsteil anwenden und überprüfen. Jede Lerneinheit hat verschiedene Lektionen, die am rechten Rand zu sehen sind. Um die Lektionen in der mobilen Ansicht zu sehen, müssen Sie sich im jeweiligen Kapitel befinden. Sie gelangen auf die Lektionen, indem Sie auf das Symbol mit den drei Strichen und den drei Punkten rechts daneben klicken. Sie können durch die verschiedenen Kapitel und Lektionen navigieren, indem Sie die Begriffe in der Gliederung anklicken oder die Schaltflächen am unteren Rand der Seite benutzen.

Beschreibung der Symbole

Achtung

Seien Sie vorsichtig, hier gibt es einen typischen Stolperstein

Frage

Dinge, die Sie sich fragen sollten

Information

Hier werden Ihnen zusätzliche Erkenntnisse gegeben

Übung

Hier können Sie Ihr Wissen testen

Lösung

Die Lösung zur Aufgabe finden Sie hier

Zu guter Letzt: Auch wenn es sich um einen Onlinekurs handelt, ist es manchmal keine schlechte Idee, sich Notizen zu machen.

Story: Ein Betriebsausflug

Beginnen wir nun mit einer Einführung in die Thematik.

„Weißt du", sagte Viktoria Reichmann, setzte ihre Espressotasse ab und schaute ihrem Kollegen Heinz Anger in die Augen, „früher haben wir bei der Softwareentwicklung in Sachen Projektmanagement alles Mögliche ausprobiert, ob Wasserfallmodell, V-Modell, egal was, in Sachen Zielerreichung hat es wenig gebracht. Die Zeitvorgaben haben wir selten eingehalten und wenn, dann ging das sehr oft auf Kosten der Qualität. Von den Budgets, die uns regelmäßig aus den Rudern gelaufen sind, wollen wir nicht reden." Ihr Blick ging über den großen Platz vor der Arena, er war in das warme, orangefarbene Licht der untergehenden Sonne getaucht. Sie genoss dieses Panorama. „Bei einem monumentalen Bauprojekt wie diesem hier lässt sich fast alles sauber kalkulieren, ob technische Sachverhalte, Logistik oder der Einsatz von Mitarbeitern und Ressourcen. Mit ein wenig Geschick konnten die Projektmanager der Antike sogar die Zeitabläufe auf der Baustelle festlegen und die erforderlichen Gelder kalkulieren. Das funktionierte bei solchen Projekten sehr gut und so klappt das bei unseren Investitionsprojekten auch heute noch. Geschickte Projektmanager vorausgesetzt." Viktoria zwinkerte mit den Augen und lächelte verschmitzt.

„Bei unseren Softwareentwicklungsprojekten sind wir aber leider regelmäßig gescheitert. In Sachen Projetmanagement mussten wir alles auf den Kopf stellen, die Projektarbeit mussten wir deshalb neu denken." „Du machst mich richtig neugierig! Erzähle mir, was ihr da so innovativ gedacht und anders gemacht habt", gab Heinz zurück. Er beugte sich nach vorne, um einen besseren Blick auf Veronas großartiges Amphitheater aus der Römerzeit zu werfen. „Als Projektmanager haben wir uns daran gewöhnen müssen, dass die Projekte der Softwareentwicklung leider nicht immer in der geforderten Klarheit skizziert werden können." Viktoria erklärte weiter, „Die Zukunft ist eine Ansammlung von schwierigen Herausforderungen und guten Gelegenheiten, unvorhersehbaren Risiken und großartigen Chancen. Heute wird von der sogenannten VUCA-Welt gesprochen. Wobei VUCA ein Akronym ist, das für die englischen Begriffe volatility - Unbeständigkeit, uncertainty - Unsicherheit, complexity - Komplexität und ambiguity - Mehrdeutigkeit steht und offenbar ist unsere Welt so. Die Anforderungen, die aus der Projektumwelt kommen, ändern sich rasch und so ist es auch mit den Anforderungen unserer Kunden. Dies alles gilt es beim „Neudenk" des Projektmanagements zu berücksichtigen."

Heinz warf ein: „Beim traditionellen Projektmanagement denken wir die Arbeit vom zu erbringenden, vom zukünftigen Ergebnis aus. Unter Beachtung der Stakeholder und des Projektumfelds schreiben wir so gut es geht auf, was wir erreicht haben wollen. Wir legen also das Leistungsziel fest und erstellen eine Spezifikation. Im Phasen- und Ablaufplan legen wir den Weg fest, der uns zum Ziel bringen soll. Wir kalkulieren die erforderlichen Mitarbeiter, die notwendigen Mittel, also Kapazitäts- und Ressourcenpläne sowie die zu erwartenden Kosten mittels Kostenplan. Manchmal versuchen wir sogar die notwendigen Geldmittel aufzutreiben, welche wir dann im Budgetplan darstellen. Wir sichern unsere Pläne mittels Risikobeurteilungen ab und ehrlich gesagt, kann ich daran nichts Falsches erkennen." Viktoria schüttelte kaum merklich den Kopf: „Es ist nicht falsch. Es funktioniert halt leider nicht bei unseren Projekten. Vielleicht weil es wie ein Korsett einschnürt, weil es einfach zu starr ist und die Bewegungsfreiheit einschränkt, wer weiß?" Sie zucke mit den Schultern.

„Heinz, ich will dir mal in ein paar knappen Worten die wesentlichen Unterschiede zu deinem traditionellen Projektmanagementkonzept aufzeigen. Damit sage ich nicht, dass dein bisheriger Ansatz falsch war, ich sage nur, dass es der Ergänzung um einen neuen Ansatz bedarf. Eine Herangehensweise, die uns beim Lösen unserer Herausforderungen hilft. Neu sind nun bei unseren Softwarentwicklungsprojekten, vier einfache Punkte:

  1. Der Mensch und seine Interaktionen sind wichtiger als Prozesse und Werkzeuge.

  2. Das funktionierende Produkt ist wichtiger als die umfassende Dokumentation.

  3. Die Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlungen.

  4. Das Eingehen auf Veränderungen ist wichtiger als das Festhalten an einem Plan."

„Das nenne ich einen Paradigmenwechsel! Jetzt verstehe ich, dass euch das hilft ein enges Korsett abzulegen und in der Bearbeitung eurer Projekte beweglicher zu werden", warf Heinz anerkennend ein. „Genau, und das ist auch der Grund, weshalb wir den neuen Handlungsrahmen agiles, also bewegliches Projektmanagement nennen."

„Du brauchst also keinen fein ausgearbeiteten Plan, um das Projekt zu realisieren?" fragte Heinz nach. „Genau, so ist das. Doch lass uns erst noch einmal festhalten, wann es sinnvoll ist, agiles Projektmanagement zu nutzen. Wir setzen es dann ein, wenn wir einen Auftraggeber, den sogenannten Product Owner, haben, der uns erklärt, dass er eine vage Vorstellung vom zukünftigen Produkt oder Service hat, das nennen wir Product Goal, aber nicht genau sagen kann, wie das, was er sich wünscht, konkret aussehen soll. Es kommt erschwerend hinzu, dass wir im Team nicht genau wissen, wie wir dieses Product Goal erreichen können. Die Erstellung eines kompletten Projektplanes ist uns deshalb überhaupt nicht möglich." Heinz schüttelte ablehnend mit dem Kopf: „So ganz planlos? Das hat doch mit Projektmanagement nichts zu tun, das erzeugt doch nur Chaos und führt zu Anarchie!" Heinz bemühte sich, nicht emotional zu werden. „Nicht so schnell, mein Lieber. Agiles Projektmanagement ist sehr strukturiert und folgt klaren Regeln", beruhigte ihn Viktoria. „Okay, dann lass mal hören."

„Gemeinsam können wir im Team die Projekt- und Leistungsmerkmale festlegen. Das sind die Aktivitäten im Product Backlog oder im Sprint Backlog. Die Aktivitäten werden wörtlich Tasks, User Stories und Epics genannt. Wir können Chancen und Risiken, wie auch Hindernisse, die sogenannten Impediments erspüren, Aktivitäten priorisieren, schrittweise umsetzen und ausführen. Im agilen Projektmanagement setzen wir uns feste Zeitrahmen, welche Time Boxes genannt werden, mit einer Dauer von z. B. zwei Wochen. Innerhalb der Time Box findet die eigentliche Projektarbeit, die Bearbeitung von Items der Backlogs, im sogenannten Sprint statt. Der Auftraggeber kann zeitnah Änderungs- und Korrekturwünsche einfließen lassen und das Projekt beenden, wenn das Produkt oder der Service den gewünschten Status erreicht und in erforderlicher Qualität erbracht hat. Am Ende des Sprints muss ein vorzeigbares und abnahmefähiges Ergebnis vorliegen. Dieses Ergebnis wird Increment genannt." Heinz nickte leicht: „Im Sprint nehmt ihr Geschwindigkeit auf, arbeitet vermutlich zügig und konsequent, und alles Hinderliche, also beispielsweise ein zu enges strategisches Korsett oder eine zu detaillierte Planung, lasst ihr entfallen. Habe ich das richtig verstanden?" „Genau, und während der Projektbearbeitung halten wir, das heißt der Scrum Master - quasi in der Funktion eines Agile Coaches - und das Team die Augen offen, um jede sich bietende Chance zur Beschleunigung oder Leistungsverbesserung zu erkennen und beim Schopf zu greifen. Die Zwischenergebnisse werden jeden Tag im Team vorgestellt und besprochen. Dieses Meeting nennt man Daily Scrum. Auf alle Fälle werden mit dem Product Owner und gegebenenfalls mit weiteren Stakeholdern im Rahmen eines Reviews am Ende des Sprints - in der Sprint Review - die erreichten Ergebnisse besprochen und vom Product Owner die Freigabe des nächsten Sprints eingeholt." Heinz versuchte es in seine Worte zu fassen: „Das bedeutet also, das ursprüngliche Product Goal kann in Iterationen, in aufeinanderfolgenden Sprints, umgesetzt werden und damit erreichen wir das Leistungsziel." Viktoria bestätigt dies und ergänzte: „In unserer Sprache ist das Leistungsziel die Summe der Increments. Am Ende eines Sprints wird das, jeweils zuvor festgelegte, Sprint Goal inklusive der Akzeptanzkriterien erreicht. Wenn kein Technical Debt mehr vorliegt, alle Backlogs abgearbeitet sind und der Product Release veröffentlicht ist, ist das Projekt beendet."

Heinz dachte kurz nach. „Neben einer stark ausgeprägten Kommunikationsfähigkeit sind vom Scrum Master und von den Entwicklern auch eine sehr flexible Einstellung zu den Ergebnissen ihrer Arbeit gefordert." „Das ist richtig", bestätigte Viktoria. „Dies, und die Fähigkeit das Projekt unter unscharfen Randbedingungen zu organisieren!" „Um die Anforderung zu meistern und das Gewicht zu stemmen, kann ich mir vorstellen, dass der Scrum Master und sein Team experimentierfreudig sein müssen, um sich schnell auf neue Erkenntnisse und Gegebenheiten einstellen zu können", merkte Heinz an. „Habe ich das richtig verstanden? Ihr könnt zwar nicht genau vorhersagen, wie viel Geld oder Zeit ihr mit dem agilen Projekt benötigen werdet, aber ihr liefert in kurzen Intervallen Ergebnisse, welche mit dem Product Owner abgestimmt sind und von ihm modifiziert, bzw. freigegeben werden können?" Viktoria nickte bestätigend. „Also ihr habt ein Projekt, dessen Leistungsanforderungen und Randbedingungen so vage sind, dass die Erstellung einer Spezifikation schwierig oder sogar unmöglich wird. Weil es aber ohne die Spezifikation keine Grundlage für eine saubere Projektplanung gibt, bringen der Scrum Master und sein Team ihre Fachkenntnisse und kommunikativen Stärken ins Spiel. Sie binden den Product Owner eng in das Projekt ein und zeigen auf, was sie in einem Sprint tun und welches Ergebnis sie erreichen wollen", fasste Heinz zusammen. „Genau, und dem Projektziel nähern wir uns mit den erreichten Ergebnissen der Sprints an, wobei du schon richtig erkannt hast, dass die Anzahl der erforderlichen Sprints, zur Erreichung des Projektziels zu Projektbeginn nicht bekannt sind. Die Kommunikation zwischen den Beteiligten, die Überprüfungen und Freigaben, sind allerdings klar geregelt", ergänzte Viktoria. „So ist inzwischen agiles Projektmanagement in der Softwareentwicklung, aber auch in allen anderen Projekten der VUCA-Welt zu einem entscheidenden Erfolgsfaktor geworden."

Heinz nickte zustimmend. „Das ist tatsächlich ein ganz anderes Projektmanagement, als das mir bekannte, herkömmliche oder traditionelle Projektmanagement. Ich wünsche mir bei Gelegenheit in einem agilen Projekt mitarbeiten und die Techniken und Werkzeuge anwenden zu können." Viktoria freute sich über Heinz Angers Begeisterung. Vom Nachbartisch kam Kerstin Weidner herüber: „So, nun habt ihr genug Facharbeit geleistet, die Rechnung des Cafés wurde schon von Dr. Riemer beglichen. Jetzt können wir in die Arena gehen und Bizets Carmen genießen. Unsere lieben Kollegen stehen schon an." Kerstin zeigte zu ihren Kollegen, die dort schon am Eingang standen.

Ihnen hat die Geschichte gefallen?

Am Ende dieses Kurses finden Sie eine weitere Geschichte, die Ihnen die Thematik und das Gelernte näher bringt. Diese Geschichte zeigt Ihnen, wie Scrum in der Praxis - wenn auch sehr vereinfacht - umgesetzt werden kann. Wir empfehlen Ihnen, die Geschichte erst am Ende zu lesen oder wenn Sie schon wissen, was Scrum bedeutet und wenn Sie schon mit den Begriffen vertraut sind.

Nun wünschen wir Ihnen gutes Gelingen und viel Spaß beim Lernen!