Projektmanagement. Agile Planung in einem mittelständischen Hotel

Inhaltsverzeichnis

I Tabellenverzeichnis

II Abkürzungsverzeichnis

1. Einleitung
1.1 Ausgangssituation undZielsetzung
1.2 Vorgehensweise

2. Projektbericht
2.1 Vorbereitungenfür Projektdurchführung
2.1.1 User Story und Anwendung der Serum-Methode
2.1.2Projektqualität
2.1.3AgilerFestpreis
2.2 Projektierung mittels Serum
2.2.1 ProduktBacklog
2.2.2 Backlog Meeting und Planning Poker
2.2.3 Sprint Planning Meeting
2.2.4 Daily Serum und Sprint Backlog
2.2.5 Sprint Review
2.2.6 Sprint Retrospektive

3. Fazit

III.Literaturverzeichnis

I Tabellenverzeichnis

Tab. 1: Ablaufplan Projektbeginn und ersterSprint

Tab. 2: Product Backlog

Tab. 3: Planning Poker: kritische Items

Tab. 4: Sprint Backlog User Story #1

II Abkürzungsverzeichnis

CFD: Cumulative Flow Diagram

Die folgenden Abkürzungen werden nur in den Tabellen verwendet.

D: Designer, HM: Hotelmanagement; M: Master; PO: Product Owner; P: Programmierer; P1: Pro­grammierer 1; P2: Programmiere^.¹

1. Einleitung

1.1 Ausgangssituation und Zielsetzung

Ein mittelständisches Hotel mit 80 Zimmern hatte eine wachsende Anzahl an negativen Bewertun­gen und einem Rückgang an Buchungen zu verzeichnen. Zur Verbesserung seiner Marktfähigkeit wurden vom Hotelmanagement das Personal und Gäste als Stakeholder befragt. Als besonders gravierend kritisierten die Gäste die langen Wartezeiten beim Check-in und Check-out für Reise­gruppen, obwohl die Rezeption mit zwei bis drei Beschäftigten besetzt war. Einzelreisende, die in die Ankunft einer Reisegruppe gerieten, fühlten sich unnötig aufgehalten. Gegenwärtig werden im Hotel Türschlösser mit Zifferneingabe verwendet. Den Tür-Code erhalten die Gäste von der Re­zeption nach erfolgreichem Einchecken per Hand in den Hotelausweis eingetragen. Das Hotelma­nagement leitete daraus die Idee der Entwicklung einer App für Mobilfunkgeräte als Kundensys­tems zum selbsttätigen Check-in/Check-out durch die Gäste ab. Mit diesem personenkontaktfreien Verfahren wird zusätzlich den Erfahrungen der Corona-Pandemie Rechnung getragen. Diese App soll das bestehende Hotelverwaltungssystem nutzen. Die Verwaltungsprozesse sollen automati­siert, zeitlich entzerrt und die bisher manuellen Tätigkeiten in der Rezeption besonders beim Check-in weitgehend entfallen. Eine Stelle und die zugehörigen Personalkosten sollen eingespart werden.

1.2 Vorgehensweise

Nachdem das Hotel die Leistung ausgeschrieben hatte, wurde von unserem Start-up­Unternehmen in einem Workshop der Projektinhalt geklärt. Serum empfahl sich als agile Manage­mentmethode, da die Vorstellungen des Hotels als Auftraggeber noch nicht ausgereift waren und, wie es sich während der Projektierung zeigen sollte, noch überarbeitet und ausgeweitet wurden. Für die Realisierung wurden ein agiler Festpreis und die Serum-Methodik vereinbart. In den fol­genden Kapiteln werden die Vorarbeiten bis zum Vertragsabschluss für das Projekt aufgezeigt. Die Empfehlungen des Scrum Guide bilden die Grundlage für die Projektierung. Im chronologischen Ablauf werden die Arbeiten von der Vorplanung mit Schwerpunkt auf dem agilen Festpreis als Grundlage für den Vertragsabschluss dargelegt. Es wird aufgezeigt, wie der agile Festpreis die Vorteile der Serum-Methode für die Vertragsgestaltung übernimmt und wie sich beide im Vertrag ergänzen. Die eigentliche Projektierung mittels Serum-Methode, der Workflow vom Product Back­log und Planning Poker über Sprints mit ihren Wechselbeziehungen bis zu abschließenden Pro­jekttests und Auslieferung der Inkremente (Gloger/Margetich 2018, S. 59) wird nachfolgend darge­stellt. Probleme, die während der Arbeit mit den agilen Methoden erkannt wurden und die in der Zusammenarbeit mit dem Auftraggeber, dem eigenen Personal, dem Einsatz von Tools und der Nutzung der Serum-Methodik erkannt wurden, werden abschließend erläutert. Wege und Maß­nahmen zu ihrer Lösung werden aufgezeigt.

2. Projektbericht

2.1 Vorbereitungen fürdie Projektdurchführung

2.1.1 User Story und Anwendung der Serum-Methode

In einem ersten Workshop mit dem Start-up, vertreten durch den künftigen Product Owner, formu­lierte das Hotelmanagement seine Vorstellungen und Funktionswünsche als User Story: „Als Ho­telleitung möchte ich eine mobile App, mittels derer die Hotelgäste einchecken können und aus­checken können, um Personal an der Rezeption zu sparen und für den Gast die Prozesse zu be­schleunigen.“ Da diese User Story sehr komplex ist und zahlreiche nicht eindeutig definierte Fea­tures umfasst, wurde sie vom Product Owner als Epic eingestuft und die Anwendung der agilen Projektmanagement-Methode Serum vorgeschlagen. Der Product Owner erläuterte, dass Serum davon ausgehe, dass im Projektanfang noch nicht alle Features, nicht alle Anforderungen bekannt sind und diese erst in gemeinsamer Arbeit entwickelt und iterativ verfeinert werden (Maximi 2013, S. 16). Permanente Qualitätsprüfung hält das Projekt flexibel und transparent. Auf Fehlentwicklun­gen kann frühzeitig reagiert werden. Zeitaufwand sowie finanzielle Risiken werden minimiert. Der Nutzen der künftigen User steht im Mittelpunkt (Gloger/Margetich 2018, S. 52; 88). Das Serum­Modell basiert auf gegenseitigem Vertrauen und Transparenz.

Gemeinsam wurden für die Epic zwei User Storys als selbstständig verwertbare Projektteile, die Produktinkremente, erarbeitet. In diesen definierte das Hotelmanagement seine Anforderungen an Funktionen und Nutzen in quantitativer oder qualitativer Hinsicht. Die neu formulierten User Storys lauteten: #1: „Als Hotelleitung möchte ich, dass die Hotelgäste über eine App für Mobiltelefone selbstständig einchecken können, um den Personalbedarf und die damit verbundenen Kosten der Rezeption zu halbieren sowie die Wartezeiten für die Gäste zu minimieren. #2: „Als Hotelleitung möchte ich, dass die Gäste per App die während des Aufenthalts gebuchten Zusatzleistungen be­zahlen können, um den Check-out zu beschleunigen.“

2.1.2 Projektqualität

Der Product Owner ist für die inhaltliche Analyse von Projektidee und Aufgabenstellung zuständig. Er verantwortet die zu lösenden Aufgaben gegenüber dem Entwicklungsteam, deren Erfüllung den Nutzen gegenüber dem Auftraggeber. Die Qualität der User Storys wurde durch den Produkt Ow­ner anhand der Invest-Methode² überprüft (Schaaf o.J.). Er klassifizierte Projekt und User Storys als qualitativ durchschnittliche App. Diese kommuniziert mit einer Backend-Lösung, hat mehrere Menüpunkte, eine umfangreiche Konfiguration und verwendet Standardkomponenten (Haalck o.J.).³ Für die Preisbildung schlug der Product Owner einen agilen Festpreis vor.

2.1.3 Agiler Festpreis

Das Vertragskonstrukt des agilen Festpreises kombiniert Elemente aus Dienst-und Werkvertrag (Keller o.J./ Tuholjakovic 2020, S. 72). Angewendet wird der agile Festpreis bei komplexen Projek­ten, wo die Vielzahl der Aufgaben, Ergebnisse und der zu erwartenden Änderungen eine vollstän­dige Planung mit festem Preisgefüge schwer bis unmöglich machen. Bevorzugte Anwendungsge­biete sind große IT-Projekte und Organisationsprojekte. Er vereint die Vorteile des agilen Projekt­managements mittels Serum mit denen eines Festpreises.

Der agile Festpreis ist ein initialer Preis für das Projekt, der im Verlauf der Arbeit angepasst wer­den kann. Die Regelungen dazu umfassen u.a. die Definition der Risk-Shares, d.h. die anteilige Übernahme der Mehrkosten durch Auftraggeber und Auftragnehmer bei höherem Ressourcenbe­darf. Ein Bonus-System, z.B. für vorzeitige Projekterfüllung, kann vereinbart werden. Die Abrech­nung der Leistungen kann aufwandsbezogen für eine abgenommene Teilleistung, eine Sprint oder ein Inkrement, erfolgen (Tuholjakovic 2020, S. 76). Durch dieses Vertragskonstrukt ist es den Be­teiligten möglich, flexibel auf Veränderungen aufgrund neuer Funktionalitäten oder auftretender Probleme zu reagieren, ohne den Vertrag ändern zu müssen. Gleichzeitig werden die Kosten transparent (Riedel o.J.). Ausgangspunkt ist eine „vollständige, aber noch nicht detaillierte Be­schreibung des Vertragsgegenstandes“ (Opelt/Gloger/Pfarl/Mittermayr 2017, S. 43). Die Erarbei­tung eines agilen Festpreises basiert auf der Verringerung der Komplexität des Projektes auf plan- und kalkulierbare Elemente. Im Workshop definierte der Product Owner die Features für die erste User Story in einer noch geringen Detaillierungstiefe.

Wegen der unterschiedlichen Leistungsarten zog er zur Bewertung der Features das vorgesehene Entwicklerteam hinzu. Gemeinsam vergaben sie Story Points. Mit Story Points wird nicht der Auf­wand, sondern die Komplexität bewertet. Als Referenz für einen Story Point wurde ein unkompli­zierte, einfaches Teilaufgabe, das Item #1-7, festgelegt, das auch im späteren Product Backlog (Tab. 3) verwendet wird und das keine Verbindungen zu anderen Teilaufgaben oder zum Hotelsys­tem hat. Der Aufwand dafür wurde mit zwei Arbeitsstunden festgelegt. Je komplizierter ein Feature und die daraus hervorgehenden Items sind, desto mehr Story Points wurden vergeben. Story Points geben ein Abbild der relativen Größe. Nach der Bewertung der Kompliziertheit der Features wurde ein vorläufiger Sprint gebildet. Ein Sprint ist eine Menge von Items, welche die Teammit­glieder innerhalb eines definierten Zeitraumes für realisierbar halten (Schwaber/Southerland 2020, S.8)⁴. Dieser Zeitraum wurde wegen der noch geringen Erfahrungen des Teams mit Serum auf zwei Wochen festgelegt. Story Points dieses Sprints wurden im folgenden Schritt mittels der fest­gelegten Arbeitsstunden mit personellem Aufwand und Kosten von 100 €/Stunde bewertet. Diese Festlegungen zu Story Points und Aufwand wurden als Kalkulationsbasis in den späteren Vertrag übernommen (Mustervertrag: Denovo GmbH, .o. J). Aus dem Aufwand des Sprints wurde der fi­nanzielle und zeitliche Gesamtrahmen von max. vier Wochen für das Projekt abgeleitet. Für die User Story #1 ermittelte der Product Owner einen Preis von ca. 20.000 €, für die User Story #2 wurde der Leistungsumfang auf ca. 12.000 € geschätzt⁵, da hierfür die App in Struktur und Design bereits vorliegt und nur noch die inhaltlichen Features zu berücksichtigen sind. Der Gesamtpreis von ca. 32.000 € wurde dem Hotelmanagement als agiler Festpreis angeboten. Das Hotelma­nagement hatte selbst mittels eines im Internet verfügbaren Kalkulators den Preis der ersten Story auf ca. 20.000 - 30.000 € grob geschätzt (Portal24 GmbH 24, o. J) und nahm das Angebot an. Der Vertrag wurde abgeschlossen.

Während der Gespräche hatte der Product Owner als Alternative zur Vorgehensweise vorgeschla­gen, das Projekt und den agilen Festpreis vertraglich auf eine User Story zu begrenzen. Diese wird als Minimum Viable Product (MVP) definiert. Das ist der Leistungsumfang, den das Projekt min­destens haben muss, um selbstständig verwendbar zu sein. Die User Story wird in mehreren Schritten bis zur Projektierungsreife in einem oder mehreren Sprints kalkuliert. Nach Fertigstellung werden anhand des tatsächlichen Aufwandes die übrigen Scope-Teile bewertet. In dieser Phase kann über Fortsetzung oder Einstellung des Projektes entschieden werden. Vom Hotelmanage­ment wurde die Möglichkeit der Beendigung des Projekts nach dem ersten Sprint in den Vertrag aufgenommen. Generell wies das Hotelmanagement auf die Notwendigkeit schnellstmöglicher Fertigstellung.

2.2 Projektierung mittels Serum

Pandemie bedingt wurden die internen und externen Besprechungen per Videokonferenz durchge­führt. Für die Videokonferenzen wurden Excel-Tabellen statt der sonst für die einzelnen Scrum- Schritte üblichen Karten und Whiteboards verwendet.

Nach Auftragserteilung wurde das Scrum Team gemäß Scrum Guide aus Master, Product Owner und Entwicklerteam, bestehend aus Designer und zwei Programmieren, gebildet (Schwaber, K., Sutherland, J. (2020) S.5).⁶ Das Scrum Team arbeitet ohne Hierarchie selbstmanagend, es

wählt, wer die Arbeit erledigt, wie und woran gearbeitet wird.“ (Schwaber/Sutherland 2020, S. 15). Bei Scrum-Teams ist besonders auf die Teamfähigkeit der Mitglieder zu achten. Aufgaben des Serum Master sind Scrum-Schulung, Koordinierung der Arbeiten und Klärung auftretender Prob­leme mit der Geschäftsleitung. Er ist „ergebnisverantwortlich für die Effektivität des Serum Teams“ (Schwaber/Sutherland 2020, S. 7). Als ersten Schritt erstellte der Master einen prinzipiellen Ab­laufplan für den Backlog und einen Sprint von zwei Wochen, der sich in der gesamten Projektie­rung bewährte.

Tab. 1: Ablaufplan Projektbeginn und ersterSprint

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Erstellung

Einen Strukturplan zu erstellen hielt der Product Owner für unnötig, da es seitens des Hotelma­nagement keine unterschiedlichen Zuständigkeiten gibt. Für größere Projekte ist jedoch ein Struk­turplan unumgänglich.

2.2.1 Produkt Backlog

Der Product Backlog wird vom Product Owner als Liste aller anstehenden Aufgaben in detaillierter Form als Items erarbeitet und dieser verantwortet ihn gegenüber dem Hotelmanagement und den Teammitgliedern. Der Product Backlog ist nicht starr, sondern kann bei sich ändernden Anforde­rungen des Hotelmanagements angepasst werden. Zur Sicherung der Transparenz wurden alle Entscheidungen dokumentiert.

Der Product Owner erstellte den Product Backlog für beide die User Storys. Für die User Story #1 konnten die Vorarbeiten zum agilen Festpreis genutzt werden. Im Produkt-Backlog werden für die Items vom Product Owner die jeweiligen Akzeptanzkriterien festgelegt. Diese bestimmen, welche Anforderungen das einzelne Item erfüllen muss und wie diese getestet werden, um den Ansprü­chen des Product Owners an die Funktionalität zu genügen (Scrum Events, 2021). Für die weitere Bearbeitung wurden die Items vom Product Owner mit der MosCoW-Methode⁷ (T2lnformatik (o.J.) priorisiert.

Die Priorisierung soll festlegen, inwieweit die Erfüllung des Items zur Erfüllung der vom Hotelma­nagement formulierten Anforderungen beiträgt. Je detaillierter die Anforderungen sind, desto prä­ziser wird die Schätzung. Sie bestimmen den Rang im Produkt-Backlog. Die MoSCoW-Methode lässt nur vier Priorisierungsstufen von „unbedingt notwendig“ bis „überflüssig“ zu. Der Product Ow­ner stellte fest, dass aufgrund der minimalistischen Ausstattung der App mit Features fast alle Items die höchste Priorisierungsstufe erhalten mussten.

[...]

¹ Zur Vereinfachung der Lesbarkeit wird im gesamten Projektbericht das generische Maskulinum verwendet. Darunter sind alle Geschlechter einbegriffen.

² Die User Story ist independent, negotiable, valuable, estimatable, small, testable.

³ Kriterien für einfache Apps: Wenig Logik, kein Backend-Zugriff, Standardkomponenten und Layout. Kom­plexe Apps: Eigenes Backend notwendig, aufwendige Logik, viele Menüs, zahlreiche Optionen für eigene Konfiguration, Maßnahmen für Sicherheit und Stabilität erforderlich, Designs nach individuellen Wünschen.

⁴ Maximal ein Monat.

⁵ Basis Item #1-7: ein Storypoint = zwei Stunden a 100€. Story #1: 100 Points, User Story #2: 50 Points.

⁶ Empfehlung: Scrum Team: Master, Product Owner, Entwicklungsteam, insgesamt max. zehn Personen.

⁷ MosCow: Priorisierungsverfahren für Reihenfolge von User Storys, Aufgaben, Items: Must have: unbedingt notwen­dig; Should have: nützlich, kann in auch in zweiter Ausbaustufe umgesetzt werden; Could have: für Funktionieren des Projekts nicht zwingend notwendig, kann verschoben werden oder entfallen; Won't have: nicht umzusetzende Anfor­derungen. Abstimmung mit Product Owner oder Auftraggeber notwendig.