Agiles Projektmanagement bei eggs

Wie arbeiten wir in kleineren und mittelgroßen Projekten?

Total agil - auch in kleineren Projekten

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

 

Dieser Artikel fokussiert sich auf kleinere bis mittelgroße 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 Anforderungen zusammen. Zumeist besteht ein Projektteam aus einem Tech Lead sowie jeweils einer Person für Frontend und Backend-Entwicklung.

Agile Frameworks

Bei eggs unimedia arbeiten wir mit verschiedenen agilen Frameworks. Wir hören dabei zuallererst auf die Wünsche unserer Kundinnen und Kunden. Aktuell im Einsatz sind bei uns Scrum, Kanban und SAFe. Gerade in kleineren Projekten nutzen wir die Kombination aus verschiedenen agilen Elementen. Es wird auf die jeweilige Projektdynamik angepasst und unterliegt einem laufenden Verbesserungsprozess. So finden wir die für das Team optimale Arbeitsweise.

Agiler Anforderungsworkshop

In einem oder mehreren Requirements Workshops klären wir zu Projektbeginn die Anforderungen mit unseren Kundinnen und Kunden. Dabei steht zuerst die Vision im Fokus, also die Fragestellung: Was ist der größte Treiber für dieses Projekt? Wir sprechen über Zielgruppen, kritische Erfolgsfaktoren und darüber, wer die Anwenderinnen und Anwender (in AEM Fachsprache Authors) sein werden. Diese Punkte behalten wir bei der Umsetzung eng im Auge, um den größten Mehrwert aus dem Projekt zu schaffen. Es werden Customer Journeys erarbeitet und entsprechende Personas definiert. Zusätzlich zu diesen "weichen" Faktoren erarbeiten wir gemeinsam die technischen Anforderungen, klären Schnittstellen und mögliche Risikofaktoren. Im Idealfall erstellen wir aus den Anforderungen direkt Epics und Stories in Jira. Diese können sofort oder im Nachgang priorisiert werden.

Jira Board

Agiler Preis - T&M

In fast jedem Projekt kommt es vor, dass sich die Anforderungen im Zeitverlauf ändern. Das ist gerade in der agilen Arbeit "normal" und sogar 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 werden die generellen Anforderungen definiert. Auf dieser Basis wird der Aufwand geschätzt und das Startbudget vereinbart. Das Budget ist, anders als bei Festpreisvereinbarungen, nicht fix an die Anforderungen gebunden. Der Vorteil liegt auf der Hand: Denn zum Zeitpunkt, wo die ersten Anforderungen oder der RFI durch einen Kunden erstellt werden, ist die zum Zuge kommende Technologie häufig noch unbekannt. Die ersten Anforderungen werden also noch "technologieneutral" beschrieben. Die Vorzüge und Handhabung der jeweiligen Technologie kommen erst im Projektverlauf zur Geltung - und dabei entstehen häufig die besten Ideen - und somit auch neue Anforderungen.

Mit T&M können die Anforderungen im Laufe des Projekts unkompliziert angepasst, umpriorisiert oder sogar gestrichen werden. 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. Das zuviel angesetzte Budget wird entweder nicht abgerechnet oder steht für die Umsetzung weiterer Anforderungen bereit.  

 

Mehr dazu können Sie im Blogartikel meines Kollegen Tobias Gollinger erfahren.

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. Das beinhaltet sowohl den Austausch innerhalb des Entwicklungsteams als auch der Austausch zwischen Entwicklungsteam und Kundin oder Kunde. 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. Für eine erfolgreiche Kommunikation haben sich Elemente aus dem Scrum Framework bewährt.

 

Daily oder Weekly

Wir führen gemeinsam mit unserer Ansprechpartnerin oder unserem Ansprechpartner auf Kundenseite ein Daily durch. Das ist ein 15minütiger Termin am Vormittag, wo alle Projektbeteiligten auf den aktuellen Stand gebracht werden und in dem Fragen adressiert werden können. Diese werden von den beteiligten Personen direkt oder im Nachgang geklärt, unter Umständen auch unter Einbindung anderer Stakeholder. Je nach Projektdynamik und Anforderungen kann statt des täglichen Termins ein wöchentlicher Austausch sinnvoller sein. Dies entscheiden wir gemeinsam mit der Kundin oder dem Kunden.

 

Review

Zusätzlich zum täglichen Austausch findet zumeist im zweiwöchigen Rhythmus ein Review statt. In diesem Meeting werden fertige Features und der aktuelle Entwicklunsgstand vorgestellt. Alle Stakeholder sind zu diesem Termin eingeladen. So besteht die Möglichkeit, direkt Feedback zu geben sowie Rückfragen zum Feedback zu klären.  

 

Retro

Direkt nach dem Review Termin findet innerhalb des Entwicklungsteams eine Retro statt. Das ist ein weiteres Scrum Element. Das Team tauscht sich ohne Kundenbeteiligung ü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 und allem anderen, was dem Team auf dem Herzen liegt. Es werden alle Themen rund um das Projekt offen ausgesprochen. Die Retro ist ein sehr wichtiges Element in der Teamarbeit, um die Meinung aller Teammitglieder einzuholen. Das gemeinsame Festlegen von Verbesserungsmaßnahmen fördert die Zusammenarbeit, die Prozesse und somit auch die Qualität.

Retro

Projektziel

In den meisten Projekten ist das erste Projektziel die Umsetzung eines Minimum Viable Products (MVP). Das ist eine voll funktionsfähige Version mit minimaler Ausstattung. Ein MVP bietet die ideale Basis, die entwickelte Anwendung schnell einem Markttest zu unterziehen. So erhalten wir unmittelbar Feedback, das für zukünftige Weiterentwicklungen des Produkts verwendet wird.  

Let's Go Agile

Neugierig geworden? Wir freuen uns auf Ihre Kontaktaufnahme!