Steffen Ingwersen

Projektleitung @ BP Europa SE

02/2021 - 12/2021

Beratung zu sowie Konzeption und Umsetzung einer Erstunterweisungsplattform auf Basis von Microsoft Azure / Spring / Angular für den Energiekonzern BP

Projektleitung @ Ladage & Oelke GmbH

09/2019 - 01/2021

Beratung zu sowie Konzeption und Umsetzung einer Crowdfunding-Plattform auf Basis von Microsoft Azure / Spring / Angular für den Textileinzelhändler Ladage & Oelke

Projektleitung @ BP Europa SE

03/2019 - 08/2019

Digitalisierung von Sicherheitsunterweisungen für den Energiekonzern BP

Geschäftsführung @ Analogue Approach

seit 2017

Gründung und Etablierung einer Marke für klassische Herrenaccessoires mit Schwerpunkt auf den Vertrieb über das Internet.

Assistenz der Projektleitung @ Harry-Brot GmbH

03/2016 - 03/2017

Einführung von SAP ERP, SAP HCM und SAP Anwendungsmanagement für die Großbäckerei Harry-Brot

Bachelorarbeit @ q.beyond AG / Nordakademie

04/2015 - 02/2016

Forschung im Rahmen einer Bachelorthesis sowie diverser Vorstudien zu hybriden Projektmanagementframeworks

Assistenz der Projektleitung @ q.beyond AG

03/2015 - 08/2015

Einführung eines On-Demand-Services für die Bereitstellung von Serverinfrastrukturen

Projektleitung @ Nordakademie

12/2014 - 02/2015

Entwicklung einer App auf Basis der Unity-Engine zur Abbildung eines virtuellen Rundgangs über den Campus der Hochschule Nordakademie

PMO / Vertretung der Projektleitung @ Gastransport Nord GmbH

10/2013 - 04/2014

Einführung einer Geschäftskommunikationsplattform für den Gasversorger GTG

Das erste simple, als Programming Principles bezeichnete Programmiervorgehen, beschrieb 1951 Alan Turing. Einen Meilenstein setzte 1970 Winston Royce, der in seinem Artikel Managing the Development of Large Software Systems ein sequentielles Vorgehensmodell beschrieb, welches heute als Ursprung des Wasserfallmodells des klassischen Projektmanagements gilt. Häufig wird dabei jedoch nicht berücksichtigt, dass er in seinem Modell auf die Notwendigkeit von Rückschritten in bereits abgeschlossene Phasen hinwies. 1987 wurde vom Project Management Institute (PMI) zum ersten Mal der Project Management Body of Knowledge (PMBOK) vorgestellt. Heute zählt er zusammen mit Projects In Controlled Environments 2 (PRINCE2) und der International Project Management Association Competence Baseline (ICB) zu den drei wesentlichen plangetriebenen Projektmanagementmethoden weltweit. Üblicherweise ist ein plangetriebenes Modell in sechs Phasen unterteilt. Dazu zählt die Planungs-, Definitions-, Entwurfs-, Implementierungs-, Abnahme- und Einführungsphase.

•   Planung
•   Definition
•   Entwurf
•   Implemen-tierung
•   Abnahme
•   Einführung

Die Ursprünge der agilen Projektmanagementansätze gehen auf allgemeine Produktentwicklungsprinzipien zurück. 1986 veröffentlichten Hirotaka Takeuchi und Ikujiro Nonaka einen Artikel mit dem Titel The New New Product Development Game, in dem sie die Aussage treffen, dass eine strikt sequentielle Produktentwicklung nicht mehr den Anforderungen einer schnelllebigen Welt entspricht, und schlagen ein neuartiges Vorgehen mit inkrementell-iterativer Entwicklung vor. Auf derselben Annahme basiert das Produktentwicklungsrahmenwerk Scrum. Der Scrum Development Process wurde von Jeff Sutherland und Ken Schwaber gemeinsam entwickelt und zunächst auf der OOPSLA im Jahre 1995 vorgestellt. Im Anschluss folgten ähnliche Methoden. Darunter eXtreme Programming (XP) von Kent Beck u.a. in 1999 und IT-Kanban von David Anderson in 2007. Die neuen Ansätze vereint, dass in Rahmen festgelegter Zeitfenster, sogenannter Iterationen oder Sprints, nur eine bestimmte Menge ausgewählter Anforderungen des Auftraggebers an das Projekt zeitgleich betrachtet und inkrementell umgesetzt wird. Daher wurden sie zunächst als leichtgewichtige Methoden bezeichnet. Der Begriff der agilen Methoden wurde erst 2001 mit der Vereinbarung des agilen Manifests geprägt. Dieses Manifest, welches in einem Expertenkreis aus Vertretern der oben genannten und weiteren leichtgewichtigen Methoden erarbeitet wurde, beschreibt acht Werte und ihre Gewichtung sowie zwölf Prinzipien, die zu einem besseren Weg der Softwareentwicklung führen sollen.

Um die beiden Projektmanagementansätze zusammenzuführen, wurden im Laufe der vergangenen Jahre mehrere Vorgehen entwickelt, die die Potentiale beider Herangehensweisen optimal zu kombinieren versuchen. Dabei hat sich die Integration agiler Vorgehensweisen in die Implementierungsphase des klassischen Modells bewährt. Hierzu werden agile Instrumente, allen voran das Vorgehen in Iterationen, in die Implementierungsphase übertragen. Das Projektmanagement übernimmt Managementaktivitäten, wie unter anderem die formale Projektfreigabe, das Controlling und den formalen Vertragsabschluss. Auf diese Weise wird das agile Team von bürokratischen Aufgaben entlastet.

• Iteration / Sprint

  Die Iteration in eXtreme Programming beziehungsweise der Sprint in Scrum ist der Rahmen agiler Projektdurchführung. Dieser Rahmen hat jeweils einen festgelegten Start- und Endtermin. Alle agilen Praktiken finden innerhalb dieses Zeitfensters statt. In Scrum beginnt ein Sprint mit der Planung im sogenannten Sprint Planning, gefolgt von der Umsetzung der besprochenen Sprintziele mithilfe täglicher Meetings, den sogenannten Daily Scrums und schließt mit der Präsentation der Ergebnisse im sogenannten Sprint Review sowie der Identifikation von Verbesserungspotentialen in der sogenannten Sprint Retrospektive ab.
  
  Die Kernidee der Iteration ist es, durch die Begrenzung der in einem festen Zeitfenster umzusetzenden Kundenanforderungen, in kürzester Zeit dem Kunden einen Teil seines Produkts auszuliefern, der für ihn einen Mehrwert darstellt.
  
  An einer Iteration nimmt das gesamte Projektteam teil. Zur Erreichung der Iterationsziele ist es von höchster Priorität, dass die Leiter der involvierten Fachgewerke, die die Ressourcen für das Projekt bereitstellen, gewährleisten können, dass das Projektteam während einer Iteration aus den gleichen Personen besteht und Mitarbeiter nicht während einer Iteration abgezogen oder umorganisiert werden.
  
  Während einer Iteration sind die Projektmitarbeiter für die Erreichung der vereinbarten Ziele verantwortlich. Der Projektleiter hat hierbei die Aufgabe, für angemessene Rahmenbedingungen zu sorgen. Die Iteration kann mit Beginn der Planungsphase eingesetzt und bei Bedarf unmittelbar nach Ende wiederholt werden. Eine Iteration ist ein fest abgestecktes Zeitfenster. Diese starre Zeitvorgabe trägt entscheidend zum Erfolg der agilen Methoden bei. Die empfohlene Dauer liegt zwischen zwei bis vier Wochen. Die abschließende Einschätzung sollte der jeweilige Projektleiter gemeinsam mit dem technischen Architekten auf Basis der Intensität des Projektes individuell treffen. Ist die Dauer einmal festgelegt, sollte sie für folgende Iterationen des Projekts nicht variiert werden.

• Definition of Done

  Der Begriff des Definition of Done kommt aus dem Scrum-Framework. In dem Definition of Done bestimmt das Projektteam Kriterien, die beschreiben, wann eine Anforderung des Kunden als abgeschlossen gilt. Ein Definition of Done gilt für alle Anforderungen eines Projekts. Daher sollten die Kriterien möglichst allgemeingültig formuliert werden, sodass sie von jeder Anforderung erfüllt werden können.
  
  Das Definition of Done dient zur Herstellung eines gemeinsamen Verständnisses darüber, unter welchen Bedingungen ein Ergebnis als abgeschlossen gilt. Dadurch werden Missverständnisse reduziert und die Qualität gesteigert.
  
  An der Sitzung zum Definition of Donw nehmen die Projektmitarbeiter, der technische Architekt und der Projektleiter teil. Die Mitarbeiter formulieren gemeinsam die Kriterien zur Abnahme und verpflichten sich selbst dazu diese einzuhalten. Die Abnahmespezifikation findet während der Planung der Arbeitspakete für das Projekt, beziehungsweise besser für die Iteration, statt und dauert in der Regel je nach Menge der Ergebnisse etwa zwei bis vier Stunden.

• Imformativer Arbeitsplatz

  Der informative Arbeitsplatz ist eine der Hauptpraktiken von eXtreme Programming. Hierbei wird das Büro des Entwicklungsteams so gestaltet, dass eine optimale Arbeitsumgebung geschaffen wird. Dazu zählen Sauberkeit und Ordnung sowie die Bereitstellung von Getränken und Snacks. Eine spezielle Anordnung der Arbeitsplätze gewährleistet den Mitarbeitern die Möglichkeit gemeinsam im Team wie auch einzeln mit der benötigten Privatsphäre arbeiten zu können. Ein Aushang mit Informationen zum Projekt bewirkt, dass Informationen schnell kommuniziert werden und Außenstehende in kurzer Zeit das Projektziel verstehen. Dieser Aushang sollte den Projektstatus, den -fortschritt sowie die Anforderungen auf kleinen Kärtchen, sogenannten Story Cards, umfassen.
  
  Der Einsatz des informativen Arbeitsplatzes soll zu mehr Produktivität der Projektmitarbeiter führen. Dies wird insbesondere durch optimierte Kommunikation erreicht. Mithilfe projektinterner Aushänge kann das gesamte Projektteam jederzeit auf dem gleichen Kenntnisstand gehalten werden. Darüber hinaus kann das Instrument durch unternehmensweite Aushänge auf eine zweite Art und Weise genutzt werden, mit dem die gesamte Organisation über aktuell laufende Projekte im Bilde gehalten wird.
  
  Der informative Arbeitsplatz erfordert die Einbeziehung aller Projektmitarbeiter, des technischen Architekten sowie des Projektleiters. Sie generieren ständig neue Inhalte für die projektinternen wie auch unternehmensweiten Aushänge und aktualisieren diese kontinuierlich. Die projektexternen Mitarbeiter des Unternehmens partizipieren passiv, während sie sich regelmäßig über aktuelle Projekte im Unternehmen informieren.
  
  Mit der Anwendung des informativen Arbeitsplatzes kann begonnen werden, sobald das Projektteam konstituiert ist, spätestens aber, wenn die Durchführungsphase des Projekts beginnt. Die projektinternen Aushänge sollten so häufig wie möglich aktualisiert werden. Dies kann zum Beispiel in einem kurzen täglichen Statusmeeting, im Scrum-Framework auch Daily Scrum genannt, passieren. Die unternehmensweiten Aushänge können nach Abschluss einer jeden Iteration aktualisiert werden. Bei klassischen Projekten eignet sich ein Rhythmus von vier Wochen zwischen zwei Aktualisierungen. Der informative Arbeitsplatz bleibt, einmal initiiert, bis zum Projektabschluss bestehen.
  
  Klassischerweise werden die projektinternen Aushänge des informativen Arbeitsplatzes an Whiteboards und Metaplanwände gehängt, die sich in einem zentralen dedizierten Projektbüro befinden. Für dezentrale Teams ist eine digitale Lösung in Jira, OneNote oder einem SharePoint vorzuziehen.

• Burndown-Diagramm

  Das Burndown-Diagramm ist ein Instrument zur Nachverfolgung des Projektfortschritts, welches zuerst im Zusammenhang mit dem Scrum-Framework erwähnt wird. Das Diagramm besteht aus zwei orthogonal angeordneten Achsen. Die horizontale Achse stellt die Zeit in Tagen dar, während die vertikale Achse die Aufwände, der zu den jeweiligen Zeitpunkten noch nicht abgeschlossenen Anforderungen des Projekts visualisiert. Das Burndown-Diagramm zeigt die Produktivität der Projektmitarbeiter sowie die Genauigkeit von Aufwandsschätzungen auf.
  
  Es wird vom Projektleiter erstellt und regelmäßig aktualisiert. Die Projektmitarbeiter verantworten dafür gegenüber dem Projektleiter die rechtzeitige Preisgabe ihres aktuellen Fortschritts. Das erste Burndown-Diagramm kann mit Beginn der ersten Durchführungsphase erstellt werden. Falls im Team tägliche Besprechungen stattfinden, stellen diese eine geeignete Grundlage dar, auf deren Basis das Schaubild aktualisiert werden kann.
  
  Mithilfe des Burndown-Diagramms lässt sich zu jeder Zeit im Projektverlauf ermitteln, wie weit die Projektmitarbeiter vom optimalen Projektfortschritt, der im Diagramm als Diagonale von oben links nach unten rechts dargestellt wird, abgewichen sind. Wird iterativ vorgegangen, kann am Ende einer Iteration ebenfalls abgelesen werden, wie viele Personentage Aufwand durch noch nicht vollständig abgeschlossene Ergebnisse übrig geblieben sind.

• Retrospektive

  Die Sprint Retrospektive ist eine Besprechung des Scrum-Frameworks. Sie findet nach dem Sprint Review und vor der Planungssitzung des nächsten Sprints, dem sogenannten Sprint Planning, statt und dient zur Reflektion der Erfolge und Misserfolge des vergangenen Sprints sowie zur Identifikation von Verbesserungspotentialen für den nächsten.
  
  An der Retrospektive nehmen alle Projektmitarbeiter, der technische Architekt sowie der Projektleiter als gleichberechtigte Teilnehmer teil. Zusätzlich sollte ein projektexterner Moderator eingeladen und mit der Aufgabe der Vorbereitung und Durchführung der Veranstaltung betraut werden. Für jede Retrospektive können etwa 90 Minuten bis zwei Stunden, abhängig von der Größe des Projektteams, veranschlagt werden.
  
  Die Retrospektive kann frei gestaltet werden, solang sie für nachfolgende Projekte beziehungsweise Iterationen verwendbare Ergebnisse erbringt. Um die Heterogenität der Veranstaltung und somit die Motivation und Kreativität der Teilnehmer zu gewährleisten, sollte siw jeweils aus verschiedenen Methoden zur Feedbackaufnahme und Verbesserungsmaßnahmendokumentation bestehen.

• Planungspoker

  Das Planungspoker hilft bei der Aufwandsschätzung einer Anforderung. In dieser Besprechung trifft sich das Entwicklungsteam mit dem Kunden. Jedes Mitglied des Entwicklungsteams bekommt ein Deck Karten. Die Werte repräsentieren dabei den Aufwand in Personentagen. Der Kunde trägt einzeln seine Anforderungen vor. Zunächst kann das Entwicklungsteam Rückfragen zur Klärung stellen. Daraufhin wird mithilfe der Karten der Aufwand geschätzt. Entsteht keine Einigung im Team, muss ein Kompromiss getroffen oder die Schätzung wiederholt werden.
  
  Das Planungspoker findet zu Beginn eines Projekts, idealerweise im Rahmen einer Planungssitzung, statt, wenn die Anforderungen des Kunden zum ersten Mal fixiert wurden. Sofern neue Anforderungen des Kunden eingehen, werden diese mit Beginn einer neuen Iteration geschätzt. Bei plangetriebenen Projekten wird der Aufwand jedes Changes geschätzt, sobald dieser eingeht. Ein festgelegtes Zeitfenster pro Schätzung hat sich bewährt, da es am effektivsten zu brauchbaren Ergebnissen führt. Die Dauer der Schätzung eines Ergebnisses sollte im Voraus auf fünf Minuten begrenzt werden.
  
  Um Planungspoker einsetzen zu können, sollte der technische Architekt die Anforderungen des Kunden im Voraus in Ergebnisse aufbrechen. Wird von den Projektmitarbeitern beim Schätzen der Bedarf festgestellt, die Ergebnisse weiter aufzuteilen, kann dies in Absprache mit dem technischen Architekten geschehen.
  
  Planungspoker kann mit verschiedenen Schätzskalen gespielt werden. Dabei hat sich die Cohn'sche unreine Fibonaccifolge bewährt. Diese berücksichtigt die Abnahme der Schätzgenauigkeit mit zunehmendem Umfang eines Ergebnisses akkurat.