Agiles Projektmanagement bei eggs

Wie arbeiten wir in kleinen und mittelgroßen Projekten?

Total agil - auch in kleineren Projekten

Wir bei eggs unimedia sind komplett agil aufgestellt, das bedeutet unter anderem, dass wir ohne Hierarchien zusammen arbeiten. Die Projektteams werden passend zu den Kundenanforderungen zusammengestellt und organisieren sich selbst. Je nach Umfang des Projektes wenden wir das ein oder andere agile Framework an oder kombinieren die besten Elemente miteinander.

 

Dieser Artikel fokussiert sich auf kleine bis mittlere Projekte, die über einen abgegrenzten Zeitraum laufen. In diesen Projekten arbeiten wir mit einem Team von 2-4 Kolleginnen und Kollegen. Die Rollen und Skillsets setzen sich entsprechend der Kundenanforderungen zusammen. Zumeist besteht ein Projektteam aus einem Tech Lead sowie einer Person für Frontend und/oder Backend-Entwicklung.

Agile Frameworks

Das weithin bekannteste agile Framework ist Scrum. Daneben gibt es noch weitere, wie Kanban oder SAFe, die bei eggs unimedia Anwendung finden. Eine Beschreibung der Frameworks sprengt den Rahmen dieses Artikels

Agiler Anforderungsworkshop

Zu Projektbeginn klären wir mit unseren Kundinnen und Kunden in einem Workshop die Anforderungen. Dabei steht zuerst die Vision im Fokus, also die Fragestellung: Was ist der größte Treiber für dieses Projekt? Dabei klären wir Zielgruppen sowie die Anwenderinnen und Anwender (in AEM Fachsprache Authors). Es wird eine Customer Journey erarbeitet und entsprechende Personas definiert. Zusätzlich zu diesen "weichen" Fakten erarbeiten wir gemeinsam die technischen Anforderungen, klären Schnittstellen und mögliche Risikofaktoren. Im Idealfall werden wir direkt Epics und Stories in Jira erstellen. Diese können direkt oder im Nachgang von der Kundin oder dem Kunden priorisiert werden.

Agiler Preis - T&M

In fast jedem Projekt ist es der Fall, dass die Anforderungen sich im Zeitverlauf ändern. Das ist gerade in der agilen Arbeit "normal" und gewollt. Deshalb ist es aus Sicht des agilen Projektmanagements sehr sinnvoll, einen Vertrag auf T&M Basis zu wählen. Dieses "Abrufkontingent" macht die Projektarbeit sehr flexibel. Zu Beginn wird die generelle Anforderung definiert und von uns geschätzt. Auf dieser Schätzung basiert das vereinbarte Budget. Das Budget ist, anders als bei Festpreisvereinbarungen, nicht fix an die Anforderungen gebunden. Das bedeutet, die Anforderungen können im Laufe des Projekts angepasst, umpriorisiert oder ganz gestrichen werden Es besteht zusätzlich die Möglichkeit gänzlich neue Anforderungen ins Projekt aufzunehmen, wenn diese im Rahmen des Budgets möglich sind. Abgerechnet werden nur Aufwände, die tatsächlich angefallen sind. Haben wir also einmal ein zu hohes Budget angesetzt, ist es kein Nachteil für unsere Kundinnen und Kunden. Ganz im Gegenteil, das zuviel angesetzte Budget wird nicht abgerechnet und steht bereit um weitere Anforderungen umzusetzen, die zuvor gar nicht vereinbart wurden.

 

Mehr dazu können Sie im Blogartikel meines Kollegen Tobias Gollinger erfahren. Link zu Tobis Artikel

Kommunikation ist der Schlüssel zum Erfolg

Aus meiner Sicht ist der Kernpunkt in der agilen Arbeit - unabhängig vom gewählten Framework - die Kommunikation. Sowohl der Austausch innerhalb des Entwicklungsteams als auch der Austausch zwischen Entwicklungsteam und Kundin oder Kunde ist der Schlüssel zum Erfolg eines Projekts. Durch regelmäßige Abstimmungen verstehen alle Seiten was gerade getan wird, was als nächstes zu tun ist, wo es Erfolge und Schwierigkeiten gibt. Fragen aus dem Entwicklungsteam können ohne langwieriges E-Mail-Ping-Pong direkt mit der verantwortlichen Person auf Kundenseite geklärt und wenn möglich direkt am Beispiel angeschaut werden.

 

Daily oder Weekly

Dazu nutzen wir Elemente aus dem Scrum Framework: Wir führen gemeinsam mit unserer Ansprechpartnerin oder unserem Ansprechpartner auf Kundenseite ein Daily "Standup" durch. Das ist ein 15minütiger Termin am Vormittag, wo alle aus dem Team auf den aktuellen Stand gebracht werden und in dem Fragen addressiert werden können. Diese werden von den beteiligten Personen und - wenn erforderlich - unter Einbindung von anderen Stakeholdern im Nachgang geklärt. Je nach Projektdauer und Anforderungen kann statt des täglichen Termins auch ein wöchentlicher Termin sinnvoller sein. Dies entscheiden wir gemeinsam mit der Kundin oder dem Kunden.

 

Review

Zusätzlich zum täglichen Austausch nutzen wir, zumeist in zweiwöchigem Rhythmus, das Review. In diesem Meeting werden fertige Features vorgestellt. Alle Stakeholder sind eingeladen, sie haben direkt die Möglichkeit Feedback dazu zu geben. Bei uns ist es ebenfalls üblich, sofern wir nicht im Scrum Framework arbeiten, im Review halbfertige Features zu zeigen. So kann die Kundin oder der Kunde ein Gefühl dafür bekommen, was bereits umgesetzt ist. Zudem gibt es die Möglichkeit frühzeitig einzugreifen, sollte die Entwicklung in eine falsche Richtung gehen.

 

Retro

Direkt nach dem Review Termin findet innerhalb des Entwicklungsteams eine Retro statt. Das ist ein weiteres Scrum Element. Das Team tauscht sich über den Zeitraum seit dem letzten Review aus: Es wird besprochen, was gut lief, was nicht so gut lief und was im nächsten Zeitraum besser/anders gemacht werden soll. Dabei handelt es sich um eine Betrachtung der technischen Themen, der Organisation, des Kommunikationsflusses. Es werden alle Themen rund um das Projekt ohne Blatt vor dem Mund ausgesprochen. Ziel ist es, die Meinung aller Teammitglieder einzuholen und durch das gemeinsame Festlegen von Verbesserungsmaßnahmen, die Zusammenarbeit zu verbessern, so dass die Kundenanforderungen optimal umgesetzt werden können.

 

Ziel

Unser Projektziel ist es ein Minimum Viable Product (MVP) für unsere Kundin oder unseren Kunden zu entwickeln. Mit dieser einsatzbereiten Version kann gestartet werden. Zumeist ergeben sich direkt beim Einsatz neue Ideen zur Weiterentwicklung oder für ein neues Produkt