Eine Geschichte über 4 Kollegen mit den Namen Jeder, Jemand, Irgendjemand und Niemand:
Es ging darum, eine wichtige Aufgabe in einem Projekt zu erledigen und Jeder war sicher, dass sich Jemand darum kümmert. Irgendjemand hätte es tun können, aber Niemand tat es. Jemand wurde wütend, weil es Jeder's Arbeit war. Jeder dachte, Irgendjemand könnte es machen, aber Niemand wusste, dass Jeder es nicht tun würde. Schließlich beschuldigte Jeder Jemand, weil Niemand tat, was Irgendjemand hätte tun können.

So etwas wollen wir natürlich vermeiden. Deshalb ist in diesem Blog beschrieben, welche Rollen es in einem Software-Projekt gibt, was die Aufgaben der einzelnen Rollen sind und welche Dinge in den Rollen unterlassen werden sollten. Damit in einem Projekt jede Aufgabe ihren Verantwortlichen automatisch findet und nichts auf der Strecke bleibt.

Was gibt es denn alles zu erledigen?

Bevor wir uns an die Zuteilung von Aufgaben zu bestimmten Rollen machen, ist es erstmals wichtig, zu wissen, wie ein Projekt-Prozess denn überhaupt aussieht.

Vor jedem Projekt gibt es Vorbereitungen, um ein gemeinsames Bild des Projekts zu bekommen:

• Projektziele definieren
• Die Projektvision setzen - Was wird das Projekt verändern?
• Anforderungen definieren - Was soll die Software können?
• Visuelles Design der Software (Wireframes, Mockups) - Wie soll die Software aussehen?

Ab Projektstart, wird in 1-4 Wochen Projekt-Phasen, sogenannte Sprints, an der geplanten Software gearbeitet. Sprints kommen aus dem agilen Projekt-Management Framework SCRUM, welches die Grundprozesse für alle unsere Software-Projekte liefert. Vor einem Sprint wird geplant, dann durchgeführt und am Ende die Software begutachtet und abgenommen.

Folgende Aufgaben entstehen in einem Sprint:

• Vorbereiten der Anforderungen für das Sprint-Planning: Beschreiben, was es alles zu tun gibt und Ideen konkretisieren.
• Priorisieren der Anforderungen untereinander - Damit die wichtigsten Anforderungen zuerst erledigt werden
• Sprint-Planning: Planen des nächsten Sprints - Auswählen der Anforderungen, die sich im nächsten Sprint ausgehen
• Abarbeiten der geplanten Aufgaben (Entwicklung und Design)
• Sprint-Review: Ein Meeting, bei dem die Software gemeinsam mit dem Auftraggeber begutachtet und vom Auftraggeber abgenommen wird
• Sprint-Retrospektive: Reflexion des Sprints im Team, um als Team effektiver, besser und effizienter zu werden.

Nachdem die Software fertig ist, kann die Software schlussendlich released und das Projekt abgeschlossen werden. Eine noch genauere Beschreibung des Prozesses findest du in diesem Artikel: https://www.deckweiss.at/post/so-lauft-ein-projekt-bei-deckweiss

Wer übernimmt nun die einzelnen Aufgaben in einem Projekt? Welche Rollen gibt es?

In einem agilen Software-Projekt gibt es grundlegend drei verschiedene Rollen für Projektmitglieder.

Product Owner - Projektleiter

Ein Product Owner kann entweder von Kundenseite oder vom Software-Unternehmen bereitgestellt werden. Er kümmert sich prinzipiell darum, dass zum richtigen Zeitpunkt die momentan wichtigsten Anforderungen am richtigen Platz landen. Er hat sich aus den Angelegenheiten, WIE etwas umgesetzt wird gänzlich rauszuhalten. Das wird den Experten und Expertinnen im Team überlassen.

Er ist sozusagen der Baumeister, der sagt, was alles zu tun ist und in welcher Reihenfolge die Dinge passieren. Er ist jedoch nicht derjenige, der selbst den Hammer in der Hand hat.

DO - Das sind die Aufgaben eines Product Owner:

• Projektziele und Projektvision erarbeiten und kontinuierlich erweitern
• Die Kommunikation zwischen Stakeholdern, Benutzern und dem Projektteam übernehmen
• Anforderungen vor Sprint-Planning vorzubereiten
• Priorisieren der Anforderungen vor Sprint-Planning - Was ist am wichtigsten für den nächsten Sprint, um die Projektziele zu erreichen?
• Verbesserungen und Änderungswünsche beim Sprint-Review identifizieren und festhalten
• Organisieren von Sprint-Planning und Sprint-Review

DO NOT - Das sollte ein Product Owner unterlassen:

• Es obligt nicht dem Product Owner zu sagen, WIE etwas gemacht werden soll, sondern nur WAS gemacht werden soll.
• Änderungen mitten im Sprint zu beantragen - Dafür ist Platz beim Sprint-Review und Planning

KNOWLEDGE - Das sollte ein Product Owner im besten Fall mitbringen:

• Erfahrung in der Zusammenarbeit mit Stakeholdern und einem Projektteam
• Verständnis für Agilität in der Software-Entwicklung, um das Projekt langfristig in die richtige Richtung führen zu können.
• Business-orientiertes Denken, um richtig priorisieren zu können

Scrum Master

Der Scrum Master stellt in einem agilen Software-Projekt die Rolle des Team-Coaches dar. Er kümmert sich darum, dass alles so läuft, wie es laufen soll. Er räumt Hindernisse, die das Team hat, aus dem Weg. Tauchen Fragen im Team auf, kümmert sich der Scrum Master um die Klärung.

Der Scrum Master stellt sozusagen den Team-Coach und Beschützer dar. Er kümmert sich um das Wohlbefinden des Teams und die zwischenmenschlichen Angelegenheiten.

DO - Das sind die Aufgaben eines Scrum Masters:

• Kümmert sich um die Kommunikation zwischen Product Owner und dem Projektteam
• Greift ein, wenn Probleme zwischen Team und Product Owner auftreten
• Achtet darauf, das Team vor äußeren Einflüssen während des Sprints zu schützen, damit diese die Anforderungen schnellstmöglich abarbeiten können. Bei Änderungswünschen während dem Sprint sollte der Scrum-Master daher durchgreifen und diese auf das Sprint-Review und Planning verschieben.
• Coacht das Team, um den Plan einzuhalten und noch besser zu werden
• Führt das Team zur Selbstständigkeit, sodass jedes Teammitglied selbst die kleinen Entscheidungen treffen kann.

DO NOT - Das sollte ein Scrum Master unterlassen:

• Sich um die Anforderungen und deren Priorisierung zu kümmern
• Änderungen im Plan mitten in einem Sprint zu akzeptieren

KNOWLEDGE - Das sollte ein Scrum Master im besten Fall mitbringen:

• Gutes Basiswissen über das Scrum-Framework
• Erfahrung im Leiten und Motivieren von Teams
• Mediationsfähigkeit
• Spricht gerne mit Menschen und ist gerne die Kommunikationsschnittstelle

Entwickler/Designer

Entwickler und Designer sind schlussendlich die Personen in einem Projekt, die sich darum kümmern, dass die Anforderungen abgearbeitet werden. Sie reflektieren nach einem Sprint den Prozess und geben alles, um als Team effizienter zu werden.

Stakeholder

Alle Personen, die am Projekterfolg interessiert sind, aber nicht aktiv am Projekt mitarbeiten, sind Stakeholder. Sie haben zumeist eine gute Sicht auf den Markt und auf die relevanten Dinge im Projekt. Sie können durch ihre Entscheidungen den Projektverlauf wesentlich beeinflussen und deshalb ist es wichtig, sie auch aktiv als eigene Rolle im Projekt zu sehen.

Sozusagen sind Stakeholder die Bauherren eines Hauses. Sie wollen im Haus wohnen und das Haus benutzen. Sie wissen, was relevant ist und geben Bescheid, wenn sie Änderungswünsche haben.

DO - Das sind die Aufgaben eines Stakeholders:

• Beim Erstellen der Projektvision mitzuwirken
• Bei wichtigen Sprint-Reviews mitzuwirken
• Bei wichtigen Sprint-Plannings teilzunehmen
• Die momentane Marktsituation mit dem Product Owner regelmäßig besprechen

DO NOT - Das sollte ein Stakeholder nicht machen:

• Die Priorisierung des Product Owners zu überstimmen
• Änderungen mitten in einem Sprint zu verlangen - Dafür sind Sprint-Planning und Sprint-Review

Jeder sollte seine Rolle leben

Jedes Projekt ist ganz unterschiedlich aufgebaut. Deshalb ergeben sich auch immer wieder andere Rollenaufteilungen.

Wichtig dabei ist, dass sich jeder in einem Projekt mit der Rolle identifizieren kann, versteht welche Aufgaben er/sie in dieser Rolle hat und folglich auch die Rolle auslebt.

Wenn alle Mitglieder gerne in der Rolle sind, in der sie sich befinden, dann hat jeder die Motivation, das beste in dieser Rolle zu geben.

Dann können am Ende des Projektes alle gemeinsam auf ein Projekt zurückblicken, das Spaß gemacht hat und die Ergebnisse erzielt hat, die gewollt waren.