• Beitrag veröffentlicht:28. August 2020
  • Beitrag zuletzt geändert am:13. Oktober 2020
  • Beitrags-Kommentare:2 Kommentare

Mein IUBH Projektbericht im Modul „Agiles Projektmanagement“ (DLBDBAPM01) als Hilfestellung für dein IUBH Studium.

Mein IUBH Projektbericht im Modul IUBH Agiles Projektmanagement

Hier stelle ich Dir meinen IUBH Projektbericht im IUBH Modul Agiles Projektmanagement (DLBDBAPM01) vor. Der IUBH Projektbericht stellt eine mögliche Prüfungsform dar und ist somit eine Hausarbeit, welche anhand definierter Vorgaben, im Selbststudium zu erarbeiten ist.

Für die Ausarbeitung des Projektberichtes bist Du selbst verantwortlich und kannst Deine Zeit und Ressourcen nach belieben einplanen. Aber freue Dich nicht zu früh, kopieren oder die Hilfe von Ghostwritern ist natürlich nicht erlaubt. Dies muss Du nämlich vor der Abgabe in einer eidesstattlichen Erklärung bestätigen.


Der IUBH Projektbericht im Modul Agiles Projektmanagement

Der IUBH Projektbericht ist eine schriftliche Ausarbeitung eines Projektes und stellt eine Prüfungsleistung dar. Als Hilfestellung wird im entsprechenden Modul ein Projektleitfaden zur Verfügung gestellt. Die Ausarbeitung findet als Hausarbeit bzw. im Selbststudium statt.

Der IUBH Projektleitfaden zum IUBH Projektbericht enthält im Modul „Agiles Projektmanagement“ Angaben zu:

  • Definition und Zielsetzung
  • Gliederung und Aufbau
  • Themen und Aufgabenstellungen
  • Hinweise zur Bewertung
  • Formale Richtlinien

Es besteht im IUBH Modul Agiles Projektmanagement die Möglichkeit, für den IUBH Projektbericht aus drei Themen zu wählen. Meine Entscheidung fiel auf das Thema „Verkürzung der Release-Zeiten und schnelles Kundenfeedback“.

Die zwei weiteren möglichen Themen sind, „Transformation in eine agile Vertriebs-Organisation“ und „Agile Planung“.

Sehr ungewöhnlich war für mich, dass im Modul Agiles Projektmanagement, keine weiteren Unterlagen wie Skripte, Tutorien oder Musterklausuren angeboten werden! Man muss sich somit alle, für den IUBH Projektbericht nötigen Informationen, selbst erarbeiten.

Glücklicherweise gibt es zum von mir gewählten Thema Schnittpunkte zu zwei anderen Modulen. Die Module „Grundlagen der industriellen Softwaretechnik“ und „Requirement Engineering“ behandeln nämlich auch die Agilen Methoden im Projektmanagement. Somit konnte ich mein bereits erworbenes Wissen gut einbringen und mich schnell, auch ohne IUBH Skript, ins Thema einarbeiten.

Sollten trotzdem Fragen zum Modul und / oder dem IUBH Projektbericht auftreten, steht in der Regel der Tutor hilfreich zu Seite.


Mein persönlicher IUBH Projektbericht zum IUBH Modul Agiles Management.

Um Dir einen Einblick in das IUBH Modul Agiles Projektmanagement zu geben, stelle ich hier meinen IUBH Projektbericht zur Verfügung.

Bitte denke daran, dass dies eine vom mir persönlich erstellte, wissenschaftliche Arbeit ist. Das Kopieren und Vervielfältigen ist nur in Auszügen und unter Verwendung der richtiger Zitierweise gestattet! Aufgrund von eventuellen Problemen mit Urheberrechten, habe ich zudem ein paar Bilder entfernt.

Möchtest Du meinen vollständigen IUBH Projektbericht (inklusiv Gliederung) als PDF Dokument? Wenn Du eingeschriebener IUBH Student bist, kann ich Dir diesen gerne zukommen lassen. Schreibe mir dazu bitte eine E-Mail (von oder mit Deiner IUBH E-Mail Adresse). Achtung, oft landen meine Mails (unberechtigt) im SPAM Ordner, prüft diesen bitte am nächsten Tag!


Mein IUBH Projektbericht

IUBH Modul: Agiles Projektmanagement (DLBDBAPM01)

Thema IUBH Projektbericht: Anpassung der Projekt- und Organisationsstrukturen an die agilen Markt- und Kundenanforderungen bei der Firma Stöffel.

Deckblatt: Erstelle ein perfektes Hausarbeiten Deckblatt


Mein IUBH Projektbericht – die Einleitung

1. Einleitung

1.1 Problemstellung

Die Fa. Stöffel ist ein renommiertes und traditionell ausgerichtetes Unternehmen. Aufgrund der wachsenden Kundenanforderungen und dem erhöhten Konkurrenzdruck gerät das Unternehmen seit zwei Jahren mehr und mehr unter Druck. Die Kunden fordern immer schnellere Produktupdates. Was bei Konkurrenten bereits möglich ist, wird im Hause Stöffel durch die klassischen Projekt- und Organisationsstrukturen behindert und ausgebremst.

Derzeit herrschen bei der Fa. Stöffel klassisch hierarchische Strukturen. Produkte werden nach dem sequenziellen Wasserfallmodell entwickelt. In Kombination können so im jährlichen Rhythmus Produktupdates veröffentlicht werden.

Die Forderungen der Kunden hingegen sind, denn Entwicklungszyklus von Produktupdates auf einen monatlichen Rhythmus zu reduzieren. Konkurrenten der Fa. Stöffel sind bereits in der Lage diesen Forderungen nachzukommen. Möglich ist dies, da bei der Konkurrenz die Entwicklung der Produkte in iterativen Vorgehensmodellen stattfinden.

Um die Kundenbedürfnisse zu befriedigen und keine Marktanteile zu verlieren, plant die Fa. Stöffel eine Umstrukturierung der Produktentwicklung. Die Geschäftsführung fordert dabei, die Einführung einer iterativen Entwicklung mit allen nötigen Maßnahmen.

1.2 Zielsetzung

Von der Geschäftsführung der Fa. Stöffel wurde als wesentliches Ziel festgelegt, den Kundenanforderungen nach zu kommen und in monatlichen Zyklen neue Produktupdates zu liefern. Dazu soll das bisherige Wasserfallmodell durch ein iteratives Vorgehensmodell ersetzt werden. Hierfür ist ein passendes agiles Modell auszuwählen. Im Kontext dazu sind Projekt- und Organisationsstrukturen sowie die dazugehörigen Rollen und Verantwortlichkeiten anzupassen. Zu beachten ist dabei, dass auch die Meeting-Strukturen und die zu erstellenden Artefakte an das veränderte Vorgehen angeglichen werden.

1.3 Vorgehensweise

Um die gesetzten Ziele zu erreichen, war vor der Projektumsetzung eine detailliere Planung nötig. Diese setzten sich u. a. aus der Vorbereitungsphase und der Projektplanung zusammen. Im Zuge der Projektvorbereitung mussten Stakeholder und Anforderungen definiert, das iterative Vorgehensmodell bestimmt sowie eine Risikoanalyse durchgeführt werden. Die Projektplanung bestand hauptsächlich aus der Terminplanung sowie der Kosten- und Budgetermittlung. Der Kern der Vorbereitung lag auf der Auswahl des zukünftiges iteratives Vorgehensmodells.

Das Ziel der Durchführungsphase bestand darin, den ersten agilen Durchlauf mit Scrum zu bewältigen. Dazu mussten jedoch erst erhebliche Anpassungen an der Organisations- und Projektstruktur vorgenommen werden. Im Zuge der Reorganisation werden einige Führungspositionen wegfallen, was zu Schwierigkeiten im Projektverlauf führen kann. Es ist daher volles Augenmerk auf die Kommunikation mit den betroffenen Mitarbeitern zu legen. Gezielte Schulungen sollen dieses Vorgehen nochmals verstärkt und die Mitarbeiter auf den richtigen Weg bringen. Nach der Implementierung von Scrum im Prozess, ist der erste agile Durchlauf geplant. Um hier reibungslos agieren zu können, soll ein erfahrener externer Berater die ersten Scrum Durchläufe betreuen.


Mein IUBH Projektbericht – der Hauptteil

2. Umsetzung Transformationsprojekt – Agiles Vorgehensmodell

2.1 Planungsphase

Ehe das eigentliche Projekt gestartet werden konnte, mussten diverse Vorbereitungen und Planungen getroffen werden. Wie von der Geschäftsleitung gefordert, gehörte dazu die Termin- und Budgetplanung sowie eine Risikoanalyse. Der wichtigste Bestandteil in dieser Projektplanung war jedoch die Auswahl des passenden iterativen Vorgehensmodells.

2.1.1 Stakeholder definieren

Stakeholder sind Personen oder Personengruppen, die grundsätzlich ein berechtigtes Interesse am Projekt und dem Projektergebnis haben, in irgendeiner Weise vom Projekt und dem Projektergebnis betroffen sind und den Anspruch haben, Einfluss auf das Projekt und das Projektergebnis zu nehmen (Dort 2019). Somit zählen nicht nur die Geschäftsführer, sondern auch Mitarbeiter, Lieferanten und Kunden zu den Stakeholdern. Für das Projekt war es somit wichtig, alle relevanten Beteiligten zu bestimmen und aufzulisten. Dies geschah unter Zuhilfenahme einer Stakeholder-Tabelle. Um die Stakeholder Involvierung besser planen zu können, wurden in dieser Tabelle für jeden Stakeholder u. a. noch Angaben zur Position, seiner Macht, der benötigten Information und der Projektrolle eingetragen.

2.1.2 Anforderungen definieren und dokumentieren

Anhand dem Projektziel, den bestehenden Dokumenten und Prozessen sowie zusammen mit den benannten Stakeholdern konnten die Anforderungen ermittelt werden. Dies geschah unter Zuhilfenahme geeigneter Ermittlungstechniken. So kamen u. a. Befragungs-, Kreativitäts- und Beobachtungstechniken zum Einsatz. Dabei konnten durch die kreative Zusammenarbeit im Team einige Konflikte aus dem Weg geräumt und wichtige innovative Anforderungen ermittelt werden. Die ermittelten Anforderungen an das Transformationsprojekt wurden im Anschluss unter Bestimmung von Zweck und Zielgruppe im entsprechenden Detailgrad und der nötigen Dokumentationsform dokumentiert.

2.1.3 Iteratives Vorgehensmodell bestimmen

Anhand der ermittelten Anforderungen musste nun ein für die Fa. Stöffel geeignetes iteratives Vorgehensmodell bestimmt werden. Die Zielsetzung des Projektes lautet, das bisherige sequentielle Vorgehen durch ein agiles und iteratives Modell zu ersetzten. Dazu konnte unter Zuhilfenahme der ermittelten Anforderungen und den Unternehmenszielen ein passendes Vorgehensmodell ausgewählt werden. Die Kunden haben die beiden Modelle Scrum und Extreme Programming (XP) empfohlen, die Geschäftsführung hat zudem noch des Modell Kanban ins Spiel gebracht.

Kanban wird oft zur Optimierung des Workflows in der Produktion von Automobilherstellern eingesetzt. Böhm (2019, S.31) schreibt dazu, „Kanban ist ein System zur Steuerung von aufeinander aufbauenden Abläufen in einer Wertschöpfungskette bzw. der Produktentwicklung. Zentral ist dabei die Visualisierung des Arbeitsablaufes“. Für den Bereich der Softwareentwicklung ist Kanban somit nur bedingt anwendbar. Extreme Programming (XP) wird als die extremste Form der agilen Softwareentwicklung bezeichnet. Es ist sehr gut geeignet, wenn der Kunde zu Beginn noch keine klare Definition der fertigen Software hat.

Abbildung 1 (wurde hier entfernt): Agile Scrum. Quelle: https://hangoutagile.com/agile-scrum

Scrum ist ein bewährtes Modell im Bereich der agilen Softwareentwicklung. „Das Herz von Scrum ist der Sprint, ein Zeitraum [Time Box] von maximal einem Monat, innerhalb dessen ein fertiges [„Done“], nutzbares und potenziell auslieferbares Produktinkrement hergestellt wird.“ (Schwaber/Sutherland 2017, S.9).

Abbildung 2 (wurde hier entfernt): Eignung für Scrum. Quelle: Maximini 2018, S. 31.

Laut den Projektzielen und den daraus ermittelten Anforderungen, soll den Kunden in monatlichen Zyklen Produktupdates in Form von Software geliefert werden. Als passendes Vorgehensmodell hat das Projektteam hierfür Scrum definiert. Dies spiegeln auch die Tabelle (Abbildung 2) und die Aussage von Maximini (2018, S.31) wider, „wenn Sie also Software entwickeln wollen, können Sie sich ruhigen Gewissens für Scrum entscheiden“. Weiter spricht für Scrum die Bewährtheit des Modells. Da agile Methoden den Mitarbeiter bisher unbekannt sind, wurde Scrum der noch agileren Variante Extreme Programming (XP) vorgezogen. Kanban wurde ausgeschlossen, da es vermehrt in Bereichen der Produktion und Produktentwicklung und nicht der Softwareentwicklung eingesetzt wird.

2.1.4 Risikoanalyse erstellen

Ein wichtiger Punkt für die Geschäftsführung war, vor der Projektdurchführung eine Risikoanalyse zu erstellen. In der Risikoanalyse sollten mögliche Risiken dargestellt und daraus resultierende Schäden aufgezeigt werden.

Die Risikoanalyse wurde vom Projektleiter mit einem Kernteam aus Stakeholdern durchgeführt. Da das Thema Risikoanalyse nicht neu im Unternehmen war, wurden vorhanden Vorlagen zur Risikobewertung verwendet. Alle offensichtlichen Risiken konnten mit Hilfe einer Risikomatrix bewertet und anhand von Risikoklassen beurteilt werden. Als Hauptrisiken wurden das Scheitern des Projektes und die Nichtanpassungsfähigkeit der Mitarbeiter definiert.

Risiken eines Projektabbruchs:

Durch den Abbruch bzw. das Scheitern des Projektes müsste die Fa. Stöffel trotzdem die Kosten für bereits aufgewendeten Vorbereitungen tragen. Da im neuen iterativen Vorgehensmodell in monatlichen Zyklen gearbeitet wird, wäre hier das Risiko eines Abbruchs im akzeptablen Rahmen. Es könnte beim Abbruch direkt wieder auf das alte Modell gewechselt werden.

Risiken der Nichtanpassungsfähigkeit von Mitarbeitern:

In einem agilen Vorgehensmodell ist es sehr wichtig, dass alle Teammitglieder und Stakeholder am gleichen Ziel arbeiten und sich gegenseitig unterstützen. Der Scrum Guide verdeutlicht diese Aussage. „Das Scrum-Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Mitglieder von Scrum-Teams respektieren sich gegenseitig als fähige, eigenverantwortliche Individuen“ (Schwaber/Sutherland 2017, S.6). Für die meisten Mitarbeiter der Fa. Stöffel wird das die größte Umstellung im Transformationsprojekt sein. Da im aktuellen Wasserfallmodell bisher jeder Mitarbeiter für sich an definierten Arbeitspaketen gearbeitet hat, wird die agile Einbindung in Teams eine grundlegende Herausforderung für alle Beteiligten.

2.1.5 Terminplanung erstellen

Anhand der bisher gewonnenen Erkenntnisse wurde ein Terminplan für das Transformationsprojekt „Anpassung der Projekt- und Organisationsstrukturen an die agilen Markt- und Kundenanforderungen bei der Firma Stöffel“ erstellt.

IUBH Agiles Projektmanagement, Mein IUBH Projektbericht Terminplan (PSP)

Abbildung 3: Terminplan für das Einführungsprojekt. Quelle: eigene Darstellung

2.1.6 Kosten- und Budgetplanung durchführen

Die Kostenplanung für das Projekt wurde in zwei Bereiche unterteilt, den externe- und den internen Aufwendungen. Zu den externen Kosten zählten maßgeblich die Leistungen für Beratungen sowie die Schulung der Mitarbeiter. Interne Kosten entstanden durch aufgewendete Arbeitszeiten zur Projektdurchführung. Anhand dem tagesgenauen Terminplan ließen sich die Kosten sehr genau abschätzen und das nötige Budget ermitteln.


An dieser Stelle möchte ich Dir ein wirklich cooles Buch ans Herzen legen. Motiviert Studiert von Daniel Hunold

Dein Weg zu weniger Stress, mehr Freizeit und besseren Noten. 🎓😀

Daniel gibt Dir in diesem Buch fundierte Tipps an die Hand, wie Du motiviert, effektiv und entspannt lernst. So bleibst Du im Studium gelassen, hast mehr Freizeit und kommst schneller ans Ziel.


2.1.7 Präsentation der Projektvorbereitung an die Geschäftsführung

Die bisherigen Ergebnisse und Erkenntnisse wurden der Geschäftsführung vorgelegt und detailliert erörtert. Nach Abwägung der Risiken und aufgrund der Gefahr, bei nicht Einführung agiler Vorgehensmodelle Kundenaufträge zu verlieren, hat sich die Geschäftsführung einstimmig zur Durchführung des Projektes entschieden. Aufgrund der Dringlichkeit der Projektumsetzung und ausgiebiger Diskussion konnte der Endtermin noch um eine Woche nach vorne verlegt werden. Hier kam der Vorschlag, parallel zur Anpassung der Organisationsstruktur bereits mit der Schulung der Mitarbeiter zu beginnen. Das nötige Budget lag innerhalb des geplanten Rahmens, von der Geschäftsführung gab es dahingehend keine Einwände. Das Projekt konnte pünktlich zum geplanten Starttermin beginnen.

2.2 Durchführungsphase

In der Durchführungsphase wurden zuerst die Organisations- und Projektstrukturen an die neuen Erfordernisse angepasst. Weiter war eine intensive Schulung der Mitarbeiter hinsichtlich der agilen Projektabwicklung nötig. Erst im Anschluss daran, konnte Scrum implementiert und durchlaufen werden.

2.2.1 Anpassung der Organisations- und Projektstruktur an Scrum

Ehe das neue Vorgehensmodell Scrum im Entwicklungsprozess übernommen werden konnte, waren die Organisations- und Projektstrukturen an das neue Vorgehensmodell anzupassen. Da bei einer Umstrukturierung immer auch zwischenmenschliche Konflikte auftreten, lag das Augenmerk hier auf einer gezielten Kommunikation mit den betroffenen Mitarbeitern.

Kern des neue Agilen Vorgehensmodells Scrum ist das Scrum-Team. Es besteht in der Regel aus drei Rollen, dem Scrum Master, dem Product Owner und dem Entwicklungsteam. In Summe sind es ca. fünf bis zehn Teammitglieder. Vgl. Scrum Guide, „Scrum-Teams sind selbstorganisierend und interdisziplinär. Selbstorganisierende Teams entscheiden selbst, wie sie ihre Arbeit am besten erledigen, anstatt dieses durch andere Personen außerhalb des Teams vorgegeben zu bekommen. Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Teams abhängig zu sein“ (Schwaber/Sutherland 2017, S.6). Um diese Anforderungen umzusetzen, mussten die alten Organisations- und Projektstrukturen aufgespalten und angepasst werden.

Die bisherige Projektstruktur bestand aus einem klassischem Wasserfallmodell. Angefangen von der Anforderungsermittlung bis zur abschließenden Systemabnahme wurden dabei alle Aufgaben Schritt für Schritt abgearbeitet. Im neuen iterativen Vorgehensmodell Scrum hingegen, ist das Vorgehen gegenteilig. Hier wird in kurzen und fest definierten Zeiträumen (genannt Sprint) jeweils ein auslieferbares Produkt erzeugt. Mit jedem Sprint wird das Produktergebnis verbessert. Somit können, wie vom Kunden gefordert, in kürzeren Zeitabständen neue Produktupdates ausgeliefert werden. Um in Sprints agieren zu können wurde auch die Organisationsstruktur entsprechend der erforderlichen Rollen (Scrum Master, Product Owner und Entwicklungsteam) angepasst.

Der Scrum Master unterstützt und hilft dem Scrum Team durch sein Expertenwissen im Bereich Scrum, die Scrum Leitlinien zu leben und zu verstehen. Weiter steht er bei allen Fragen und Problemen zu Scrum, dem Team und allen Stakeholdern zur Verfügung. Im derzeitigen Personalstamm der Fa. Stöffel ist keine entsprechende Kompetenz zu Scrum vorhanden. Die Schulung eines Mitarbeiters wäre nicht im zeitlichen Rahmen möglich. Daher fiel die Entscheidung, von extern einen erfahrenen Scrum Master einzustellen. „Suchen Sie jemanden mit Scrum-Erfahrung, der die Rolle des Scrum Masters einnimmt“ (Maximini 2018, S.34), belegt dieses Vorgehen nochmal.

Der Product Owner ist verantwortlich für das Management des Product Backlog und den Wert des Produktes zu maximieren (Schwaber/Sutherland 2017, S.6). Außerdem kennt er als einziger die Kundenanforderungen und -wünsche. Auch wenn der bisherige Produktmanager diese Kompetenzen noch nicht komplett erfüllen kann, wurde entschieden, ihn als zukünftigen Product Owner einzusetzen. Um kein Risiko einzugehen, wird ihm für ca. sechs Monate ein externer Berater mit Erfahrung im Bereich Scrum zur Seite gestellt. So ist neben einer ersten Schulung ein gezieltes On-Job-Training möglich. Ein weiterer Vorteil besteht darin, dass die Kundenkontakte des Produktmanagers weiterhin in der Position als Product Owner bestehen bleiben. Für die Kunden ändert sich somit der vertraute Ansprechpartner nicht.

Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges [„Done“] Inkrement übergeben, welches potenziell auslieferbar ist. Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen (Schwaber/Sutherland 2017, S.6). Somit sind im neuen Scrum Entwicklungsteam kein Projektleiter und auch keine Führungskräfte mehr nötig. Weiter wird auch die Abteilung des Betriebsmanagers im Entwicklungsteam nicht benötigt. Für die neue Organisation bedeutete dies, dass das derzeitige Einliniensystem aufgespalten werden musste. Da nur noch für die Entwicklung essenzielle Funktionen integriert werden, sind die bisherigen Projektleiter, Lead Entwickler, Testmanager, Betriebsmanager und Betriebs Engineers im Scrum Team nicht mehr nötig. Ihnen wurden vorerst andere Aufgaben im Unternehmen übertragen. Der Entwickler, der Systemarchitekt, der Konfiguration Expert und der Dokumentation Expert konnten jedoch direkt ins neue Scrum Entwicklungsteam integriert werden. Von den bisherigen zwei Testern wird aufgrund der geringeren Arbeitslast nur einer ins Entwicklungsteam übernommen. Der zweite Tester übernimmt zukünftig andere Aufgaben im Unternehmen.

In Summe konnte der Personalstamm des bisherigen Projektteams von gesamt 13 Mitarbeitern auf sieben Mitarbeiter im neuen Scrum Team reduziert werden, was somit den Vorgaben von Scrum entspricht. Mit den nicht mehr benötigen Mitarbeitern wird die Fa. Stöffel, außerhalb dieses Projektes, über deren künftige Aufgaben bzw. den weiteren Verbleib im Unternehmen sprechen. Dies war eine der größten Schwierigkeiten im Verlauf des Transformationsprojektes, da die Umstellung für die beteiligten Mitarbeiter mit großen Sorgen verbunden war. Entgegenwirkend konnte die Geschäftsführung, zusammen mit der Projektleitung, durch ausgiebige und gezielte Kommunikation mit allen Beteiligten die Situation vor der Eskalation bewahren. So wurde u. a. dargelegt, dass ohne diese Umstellung eventuell die Kunden abspringen werden, was dann wiederum die Existenz der Fa. Stöffel gefährdet hätte. Durch Klarheit und Transparenz konnte das Vertrauen der Mitarbeiter gewonnen und die Projekt- und Organisationsstrukturen entsprechend angepasst werden.

2.2.2 Anpassung der Meeting Strukturen und Artefakte an Scrum

Scrum besteht aus nur drei Artefakten, dem Produkt Backlog, dem Sprint Backlog und dem Inkrement. Schwaber und Sutherland (2017, S.15f.) beschreiben diese Artefakte wie folgt. „Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich. Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu können. Das Entwicklungsteam passt das Sprint Backlog während des Sprints an; das Sprint Backlog entwickelt sich so während des Sprints. Diese Entwicklung erfolgt, während das Entwicklungsteam den Plan abarbeitet und mehr über die noch benötigten Schritte zur Erreichung des Sprint-Ziels. Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product-Backlog-Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement fertig [„Done“] sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen.“

Um die Anforderungen der neuen Artefakte zu erfüllen, konvertierte man bestehende Dokumente und Prozesse in die neuen Artefakte. In das neue Product Backlog wurden u. a. die Inhalte der Lasten- und Pflichtenhefte, sämtliche Anforderungskataloge und offene To-Do Listen integriert. Nach der Übertragung musste alle Product Backlog Einträge noch detailliert und priorisiert werden. Mit Hilfe des fertigen Product Backlog erstellte das Team das neue Sprint Backlog. Dazu wurde, anhand der Dauer des ersten Sprint Durchlaufes, ein ausreichend großes Arbeitspaket bestehend aus Produkt Backlog Einträgen ermittelt und in das Sprint Backlog übertragen. Das neu erstellte Sprint Backlog dient innerhalb des ersten Sprints um ein fertiges Inkrement zu entwickeln.

Das iterative Vorgehensmodell Scrum basiert außerdem auf festgelegten Ereignisstrukturen auch Meetings genannt. Bestehenden Strukturen mussten somit im Zuge des Transformationsprojektes angepasst werden. Als Ereignisse sind in Scrum (neben dem Sprint) noch das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive definiert. Zusammengefasst handelt es sich hier, mit Ausnahme des Sprints, um zeitlich festgelegte und definierte Besprechungen. Parallel zu den Artefakten passte das Projektteam auch die bestehenden Besprechungen der Fa. Stöffel an das neue Vorgehensmodell an. Unter Mitwirken des externen Beraters konnte ein genauer Meeting-Ablauf für den ersten Scrum Durchlauf erstellt werden. Das täglich stattfindende Daily Scrum gilt dabei von allen Ereignissen laut Gloger und Margetich (2018, S.71) fast als das Symbol der agilen Kultur. Anstatt in gewohnter Weise im Besprechungsraum, treffen sich die Teammitglieder am Taskboard, einer Pinnwand mitten im Raum, an dem die einzelnen Arbeitspakete in Tasks heruntergebrochen visualisiert werden.

IUBH Agiles Projektmanagement, Mein IUBH Projektbericht - Ablaufplan Scrum

Abbildung 4: Go-Live – Erster Scrum Durchlauf bei Fa. Stöffel. Quelle: eigene Darstellung

2.2.3 Schulung der Mitarbeiter

Ehe das neue Vorgehensmodell Scrum im Entwicklungsprozess übernommen werden konnte, mussten alle beteiligten Mitarbeiter gezielt geschult werden. Der Projektleiter vermittelte dabei Anpassungen zur Organisations- und Projektstruktur. Hingegen führte ein externer Scrum Berater (aufgrund der Wichtigkeit) die Schulungen zu Scrum sowie den neuen Artefakten und Meeting Regeln durch. Dieser betreute im Anschluss auch die Einführung von Scrum im Prozess und stand den Mitarbeitern dabei unterstützend zur Seite. So sollte ein reibungsloser Übergang vom sequenziellen zum iterativen Abarbeiten der Aufgaben sichergestellt werden.

Zu Beginn bekamen alle internen Stakeholder eine Schulung zum Thema Scrum. Hierbei legten die Geschäftsführer viel Wert darauf, den Mitarbeitern die Theorie und die Werte von Scrum näherzubringen. Im Anschluss daran, gab es für definierte Mitarbeiter noch rollenbezogen Schulungen. Im Speziellen für die künftigen Product Owner und Scrum Teams. Sehr wichtig war es bei den Schulungen, den Mitarbeitern die Prinzipien agiler Softwareentwicklung zu vermitteln, denn ohne deren Verständnis ist ein iteratives Vorgehen nicht umzusetzen. Im Manifest für agile Softwareentwicklung (Beck et al. 2001) heißt es dazu u. a., „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten“ sowie „die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams“.

2.2.4 Go-Live – Erster Scrum Durchlauf

Nachdem alle Vorbereitungen erfolgreich abgeschlossen waren, einigte sich das Projektteam noch auf ein geeignetes Entwicklungsprodukt für den ersten agilen Durchlauf. Die Entscheidung fiel auf ein eher einfaches Produktupdate. Dies kommt dem neuen Entwicklungsteam entgegen, da dies sich neben der Entwicklung auch auf den neuen Scrum-Prozess konzentrieren muss.

Im Anschluss hat die Projektleitung den ersten Scrum Durchlauf angestoßen. Für den ersten Sprint-Zeitraum hat man zwei Wochen angesetzt. Eine weitere Sprinteinheit von zwei Wochen soll daran folgen. Unterstützend wird der externe Berater das Scrum-Team dabei in den nächsten Wochen begleiten. Die erste Sprinteinheit startete mit einem vier stündigen Sprint Planning. Das Scrum Team erarbeitete anhand dem Product Backlog, die für die Sprinteinheit gesetzten Ziele. Dabei kam es zu ersten Meinungsverschiedenheiten innerhalb des Teams. Der Product Owner war bestrebt möglichst viele Aufgaben aus dem Product Backlog in das Sprint Backlog zu packen. Die Entwickler, welche aus praktischer Erfahrung die Aufwände besser abschätzen können, hatten hier andere Vorstellungen. Durch gezielte Kommunikation konnte der erfahrene Berater das Team auf einen gemeinsamen Weg bringen. Ein für alle akzeptabler Kompromiss als Ziel für das Sprint Backlog wurde festlegen.

In den folgenden zwei Wochen, während dem Sprint, leistete das Entwicklungsteam die Entwicklungsarbeit. Hierbei versammelte sich das Scrum Team täglich um acht Uhr zum Daily Scrum Meeting. Das Team plante darin gemeinsam die Arbeit für den Tag und überprüfte ob die Arbeitslast noch zu den Aufgaben aus dem Product Backlog passt. Während dem Sprint bestand die Aufgabe des Scrum Masters die Scrum Richtlinien zu überprüfen und wenn nötig beratend zur Seite zu stehen. Nach Ablauf der zwei Wochen bzw. zum Ende der Sprint-Einheit folge das Sprint Review. Im Sprint Review wurde das entwickelte Produkt vom Entwicklungsteam den relevanten Stakeholdern vorgeführt. Das Produkt wurde überprüft und alle Abweichungen im Product Backlog angepasst. Das neue Product Backlog diente wiederum als Vorlage für die nächste Sprinteinheit.

Die Sprint Retrospektive ist das abschießende Meeting eines Scrum Durchlaufes. Das Scrum-Team überprüfte dabei selbstkritisch das Vorgehen und die Ergebnisse der letzten Sprints. Um dem iterativen Gedanken zu folgen, ist in der Sprint Retrospektive eine grundlegende Reflexion und Selbsteinschätzung der Ergebnisse äußerst wichtig. Aufgrund des relativ einfach gewählten Produktes, gab es im ersten Scrum Durchlauf keine Probleme hinsichtlich der Entwicklungsarbeit. Für den neuen Product Owner war es jedoch nicht immer einfach sich mit den neuen Artefakten Product Backlog und Sprint Backlog zurecht zu finden. Nach dem ersten Durchlauf folgte in gleicher Weise direkt der Zweite. Das Team handelte Sprint Planning, Sprint, Sprint Review und Sprint Retrospektive in gleicher Art und Weise ab. Aufgrund der immer besser werdenden Kommunikation innerhalb des Teams, konnten negative Erfahrungen aus dem ersten Durchlauf bereits minimiert und verbessert werden. Mit Hilfe von Scrum lieferte das Scrum-Team nach vier Wochen und zwei Sprints ein für den Kunden zufriedenstellendes Produkt-Update aus.

2.2.5 Projektabschluss

Der Projektabschluss war der letzte Meilenstein im Transformationsprojekt bei der Fa. Stöffel. Unter Abwägung der Chancen und Risiken wurde das Transformationsprojekt mit hohen Erwartungen von der Geschäftsführung in Leben gerufen. Trotz einer sehr intensiven Vorbereitung ist die Projektleitung bei der Durchführung immer wieder auf kleinere Probleme gestoßen. Die Mitarbeiter betrachteten anfänglich vor allem die Anpassung der Organisationsstruktur sehr kritisch. Gezielte interne Kommunikation konnte hier jedoch schnelle Abhilfe schaffen. Positiv aufgenommen wurde hingegen die kontinuierliche Betreuung des Projektes durch den externen Berater sowie die Neueinstellung eines erfahrenen Scrum Masters. Beide halfen durch ihre Erfahrung die Mitarbeiter zu sensibilisieren, was maßgeblich zum erfolgreichen Projektabschluss beigetragen hatte. So konnte die Fa. Stöffel im Zeitraum von sieben Wochen ein neues Vorgehensmodell einführen und ist jetzt wieder auf Augenhöhe mit den Wettbewerbern.

Im ersten der beiden Sprinteinheiten sind auch wieder kleinere Konflikte im Bereich der Kommunikation aufgetreten. Durch ein gezieltes Sprint Review nach dem ersten Sprint konnte dies im zweiten Durchlauf verhindert werden. Nach zwei erfolgreichen Sprints übergab das Scrum-Team ein fertiges Produkt-Update an den Kunden.

Nach dem erfolgreichen Durchlauf von Scrum und dem Projektabschluss liegt es nun in den Händen der Geschäftsführung, das weitere Vorgehen zu bestimmen. Von Seiten der Projektleitung und auch dem gesamten Scrum Team wird die Empfehlung ausgesprochen, Scrum im Unternehmen zu Skalieren und über weitere Entwicklungsteams auszurollen.


Mein IUBH Projektbericht – der Schluss

3. Projektergebnis und Zielerreichung

Als maßgeblicher Faktor für die erfolgreiche Durchführung eines Projektes ist die Zielerreichung zu nennen. Hierbei gleicht man die Projektzielt mit den Projektergebnissen ab. Da Hauptziel dieses Projektes war es, den Kundenanforderungen der Fa. Stöffel nach zu kommen und in monatlichen Zyklen neue Produktupdates zu liefern. Hierfür wurde ein Terminplan erstellt und ein Projektbudget ermittelt, auch diese Parameter zählen in die Zielerreichung mit ein.

Nach einer detaillierten Projektvorbereitung, konnte der erste Scrum Durchlauf unter Einhaltung der gesetzten Termine pünktlich starten. Auch das angestrebte Endziel wurde, durch die enge Zusammenarbeit aller Beteiligten, auf den Punkt erreicht. Nach zwei Scrum Durchläufen, konnte das geplante Produktupdate nach Kundenvorgaben entwickelt und übergeben werden. Das Projektbudget hingegen wurde um ca. 15% übertroffen, da die Kosten für Schulungen und den neuen Scrum Master höher als geplant ausgefallen sind.

Der neu eingestellt Scrum-Master kam seinen Aufgaben hervorragend nach, und schaffte es immer wieder das Scrum-Team zu motivieren und bei Fragen zum Ablauf unterstützend zu agieren. Auch der Produktmanager konnte sich gut in seine Rolle als Product Owner integrieren. Wobei er hinsichtlich der Arbeit mit den neuen Artefakten, wie u. a. dem Product Backlog, tatkräftige Unterstützung vom externen Berater bekam. Das Entwicklungsteam benötigte fast zwei Wochen, bis sich die neuen Abläufe eingespielt hatten. Auch hier unterstützen der Scrum Master und der externen Berater in weiten Bereichen, so dass das Team schon im zweiten Scrum Durchlauf selbstständig agieren konnte.

Wichtig ist jetzt, dass das agile Vorgehen weiteres Vertrauen bei den Mitarbeitern findet. Auch ist in nächster Zeit darauf zu achten, dass die Meetings strikt eingehalten sowie die Artefakte nach Vorgabe erstellt und bearbeitet werden. Hier steht für weitere vier Monate der externe Berater zur Seite. In diesem Zeitraum hat die weitere Sensibilisierung der Mitarbeiter höchste Priorität.

Zurückblickend war das Projekt ein großer Erfolg für die Fa. Stöffel, da nun den Kundenanforderungen von monatlichen Produktupdates nachkommen werden kann. Für die Fa. Stöffel ist das nicht nur ein wichtiger Schritt zur Kundenbindung, sondern auch zur Akquise neuer Aufträge. Ohne die Umstellung wären womöglich Kunden abgesprungen, was die Existenz des Unternehmens bedroht hätte. Abschließend empfiehlt das Projektteam der Geschäftsführung, das agile Vorgehensmodell Scrum über weitere Entwicklungsteams zu skalieren. Hierbei können die bereits gewonnenen Erfahrungen hilfreich verwendet werden, so dass das Ausrollen schneller und kostengünstiger von Statten gehen kann.

I. Literaturverzeichnis

  • Beck, K. et al. (2001): Manifest für Agile Softwareentwicklung. (URL: http://agilemanifesto.org/iso/de/principles.html [letzter Zugriff: 29.06.2020]).
  • Böhm, J. (2019): Erfolgsfaktor Agilität. Springer Vieweg, Wiesbaden.
  • Dort, S. (2019): Die Stakeholderanalyse. (URL: https://www.agile-master.de/stakeholderanalyse-projektmanagement [letzter Zugriff: 18.06.2020]).
  • Gloger, B./Margetich, J. (2018): Das Scrum-Prinzip: Agile Organisationen aufbauen und gestalten. 2. Auflage, Schäffer-Poeschel, Stuttgart.
  • Maximini, D. (2018): Scrum – Einführung in der Unternehmenspraxis. 2. Auflage, Springer Gabler, Berlin.
  • Schwaber, K./Sutherland, J. (2017): Der Scrum Guide™. (URL: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf [letzter Zugriff: 29.06.2020]).

Wie wurde mein IUBH Projektbericht im Modul Agiles Projektmanagement bewertet.

Nach einer sehr langen Wartezeit von über sechs Wochen, wurde die Note zu meinem IUBH Projektbericht veröffentlicht. Diese Wartezeit ist im IUBH Fernstudium bei Hausarbeiten leider normal.

Da die Notenvergabe immer genau 30 Tage nach Monatsende (in dem Du eingereicht hast) erfolgt, kann es sogar sein, dass es über 10 Wochen dauert, bis die Note kommt. Wenn du z.B. am 1. Juni einreichst, bekommst Du die Note der Hausarbeit genau 30 Tage nach dem 30. Juni.

Für mich hat sich das Warten auf die Note wirklich gelohnt, denn mein IUBH Projektbericht „Agiles Projektmanagement“ wurde mit der Note 1,3 bzw. 92% bewertet.

IUBH Fernstudium, meine Note im IUBH Modul Agiles Projektmanagment

Hierzu die Bewertungskriterien im Detail:

  • Transfer (15%): 90%
  • Dokumentation (10%): 90%
  • Ressourcen (10%): 90%
  • Prozess (25%): 90%
  • Kreativität (15%): 100%
  • Qualität (25%): 90%
  • Summe (100%): 92%

Hast Du Fragen zu meinem IUBH Projektbericht? Schreib es mir doch bitte kurz in einem Kommentar.


Mein Fazit zum IUBH Projektbericht im Modul IUBH Agiles Projektmanagement

In Summe hatte ich für die Ausarbeitung des IUBH Projektberichtes gute zwei Wochen benötigt. Dies entspricht in etwa 40% der von der IUBH veranschlagten Zeit (anhand der 5 ETCS Punkte für das Modul Agiles Projektmanagement). Da ich bereits ein gewisses Vorwissen im Bereich Agile Methoden hatte und zudem recht fix im Schreiben von Texten bin, konnte ich dieses Modul schneller als geplant abschließen.

Trotz der fehlenden Lehrmaterialen hat es mir Spaß gemacht, mich in dieses komplexe Thema einzuarbeiten. Ein reines Auswendiglernen wie z.B. in BWL ist hingegen nicht so mein Ding. Hier ist wohl jeder ein individueller Lerntyp und hat seine Vorlieben und Abneigungen.

Das war nun mein Blog Artikel zum IUBH Projektbericht im Modul Agiles Projektmanagement. Bis zum Bachelor Titel ist es für mich noch ein weiter Weg, ich bin gespannt was noch so alles kommt. Ich werde auf diesem Blog auch weiterhin Berichte zu meinem IUBH Fernstudium schreiben und Dir meine künftigen Hausarbeiten zur Verfügung stellen.

Wenn Du noch weitere Fragen zu meinem IUBH Projektbericht oder dem IUBH Fernstudium hast, schreibe mir gerne einem Kommentar oder auch eine persönliche E-Mail.

Konnte ich Dir weiterhelfen? Dann freue ich mich auf Dein:

👍 bei Facebook und/oder auf Twitter.

Du bist noch kein Student und hast Interesse an einem IUBH Fernstudium? Dann habe ich hier noch drei hilfreiche Links für Dich:

Zum Abschluss wünsche ich Dir viel Spaß und Erfolg beim Lernen oder auch, bei der Suche nach einem passenden Studium. Es würde mich sehr freuen, wenn Du ein paar Tipps mitnehmen konntest und demnächst wieder auf meiner Seite vorbei schaust.

Du hast Freunde, denen dieser Beitrag auch gefallen könnte? Dann teile diesen bitte auf Twitter, Facebook, usw. 🙏

Auch über einen Kommentar von Dir würde ich mich sehr freuen.

Vielen Dank und herzliche Grüße aus Shanghai

Dein IUBH Fernstudent Michael


P.S. Du bist selbst Student und hast Interesse Deinen eigenen Erfahrungsbericht oder deine Hausarbeiten online zu stellen? Dann wäre es super, wenn Du Dich persönlich bei mir meldest.


Zusätzlich zum IUBH Projektbericht könnte Dich auch folgendes interessieren:

Alle meine IUBH Hausarbeiten als Hilfe für Dich!

Das perfekte IUBH Hausarbeiten Deckblatt!

Meine Erfahrungen im IUBH Fernstudium

Der maximale Rabatt für das IUBH Fernstudium.

Dieser Beitrag hat 2 Kommentare

  1. Jan

    Lieber Michael,

    vielen Dank für deinen ausführlichen Beitrag auf deiner Website zum Projektbericht und speziell im Modul Agiles Projektmanagement.
    Diese Auflistung hilft wirklich enorm, da die Infos im Kurs leider sehr kurz gehalten sind.
    Diese ganzen Informationen werden mir bei der Erstellung enorm weiterhelfen können!

    1. Michael

      Lieber Jan,

      es freut mich, dass ich Dir weiterhelfen konnte und wünsche Dir viel Erfolg bei der Erstellung Deines IUBH Projektberichtes.

      Lass mich doch bitte wissen, wie dein Ergebnis bewertet wurde.

      Herzliche Grüße
      Michael

Schreibe einen Kommentar