Selbstorganisation und Rollen im Projektteam

Alle beschäftigt, nichts erledigt

Donnerstagvormittag, 10:30 Uhr im Projektmeeting. Zeynep, eure Scrum Masterin, will die Rollen für die Sommer-Aktion klären. Aber nach zehn Minuten Diskussion verschiebt das Team den Punkt auf nächste Woche.

Um 15 Uhr explodiert der Projektkanal. Die Aktion geht morgen früh live. Zwei Kolleg:innen haben unabhängig voneinander verschiedene Banner erstellt. Die Produkttexte für 30 Artikel hat niemand geschrieben, weil alle dachten, jemand anders übernimmt das. Die Teamleitung ist bis Montag auf einer Messe. 40.000 Newsletter-Abonnent:innen bekommen morgen die Aktion zu sehen.

Die Aufgabenverteilung per Kanban-Board und die Kommunikationsstruktur im Team sind die Grundlage für das, was hier gefehlt hat: klare Rollen und Zuständigkeiten, die funktionieren, auch wenn keine Führungskraft jede Einzelentscheidung trifft.

Was genau ist schiefgelaufen?

Drei Ursachen lassen sich aus dem Szenario ableiten:

1. Keine klare Aufgabenzuordnung: Niemand war verbindlich für die Produkttexte verantwortlich. Jede:r ging davon aus, dass jemand anders das übernimmt.
2. Ungeklärte Entscheidungskompetenz: Ohne die Teamleitung wusste niemand, welche Banner-Version gilt. Es gab keine Regel, wer in solchen Fällen entscheidet.
3. Fehlende Eskalationsregel: Als das Problem um 15 Uhr sichtbar wurde, gab es keinen vereinbarten Weg, um schnell Prioritäten zu setzen.

Die Folgen: Doppelarbeit verschwendet Zeit, fehlende Texte verzögern den Launch, widersprüchliche Banner beschädigen das Erscheinungsbild. Alles zusammen kostet Umsatz und Vertrauen.

🎬 Vorstellung: Stell dir vor, du sitzt um 15 Uhr im Projektkanal und liest die Nachrichten. Welche der drei Ursachen hättest du als Erstes angegangen, und was wäre dein erster konkreter Schritt gewesen?

Die RACI-Matrix als Werkzeug

Um Zeyneps Szenario künftig zu verhindern, braucht das Team ein Werkzeug, das Rollen und Aufgaben sichtbar verknüpft. Die RACI-Matrix (Responsible, Accountable, Consulted, Informed) leistet genau das:

• R (Responsible): Wer erledigt die Aufgabe?
• A (Accountable): Wer trägt die Endverantwortung und gibt frei?
• C (Consulted): Wer wird vorher gefragt?
• I (Informed): Wer wird über das Ergebnis informiert?

Entscheidend: Pro Aufgabe gibt es genau eine Person mit dem A. Sonst entsteht wieder die Situation vom Donnerstag, in der niemand die Banner-Entscheidung treffen konnte.

Vier Rollen für die Sommer-Aktion

Für das E-Commerce-Projekt lassen sich mindestens vier Rollen definieren:

1. Artikel priorisieren und die finale Banner-Version freigeben: das ist Aufgabe des Product Owners. Braucht Input vom Content-Team und Freigabe-Feedback von QA.
2. Content-Team: Schreibt Produkttexte, erstellt Banner. Braucht die Artikelliste vom Product Owner und technische Spezifikationen von der Entwicklung.
3. Shop-Seite technisch umsetzen und Inhalte einspielen: das übernimmt die Entwicklung. Braucht fertige Texte und Banner vom Content-Team.
4. Alle Seiten vor dem Launch auf Fehler prüfen: Aufgabe von QA (Qualitätssicherung). Braucht die fertige Seite von der Entwicklung.

Jede Rolle hat eigene Entscheidungen. Die Entwicklung entscheidet etwa über den technischen Ablauf der Veröffentlichung und über Workarounds bei Problemen. Das muss nicht die Teamleitung klären.

🤔 Frage dich: Wie würdest du die RACI-Matrix anpassen, wenn euer Team zusätzlich eine externe Grafikagentur einbindet, die Banner liefert? Welche Rolle bekommt dann das A für die Banner-Freigabe?

Working Agreement: Sechs Regeln für den Ernstfall

Rollen und RACI-Matrix klären das Wer und Was. Ein Working Agreement klärt das Wie: verbindliche Regeln, auf die sich alle Teammitglieder einigen.

Kommunikation:

1. Statusupdates gehen bis 9:30 Uhr in den Projektkanal. Keine "Ich dachte, du machst das"-Situationen.
2. Blocker werden sofort gemeldet, nicht erst im nächsten Meeting.

Entscheidungsfindung: 3. Jede Aufgabe hat genau eine verantwortliche Person (das A aus der RACI-Matrix). 4. Bei Abwesenheit der Teamleitung entscheidet die Person mit dem A für ihren Bereich.

Umgang mit externem Druck: 5. Zusätzliche Anforderungen von aussen laufen über den Product Owner, nicht direkt ins Team. 6. Wird eine Deadline unrealistisch, eskaliert die verantwortliche Person sofort mit konkretem Vorschlag (z.B. Umfang reduzieren statt Qualität senken).

So hätte der Donnerstag laufen können

Hätte Zeyneps Team am Vormittag 20 Minuten in diese Vereinbarungen investiert, wäre der Nachmittag anders gelaufen: Die Produkttexte hätten eine verantwortliche Person gehabt (Regel 3). Die Banner-Entscheidung wäre auch ohne Teamleitung gefallen (Regel 4). Und der Blocker wäre nicht erst um 15 Uhr sichtbar geworden (Regel 2).

Selbstorganisation heisst nicht, dass niemand steuert. Es heisst, dass das Team vorher festlegt, wer was entscheidet, damit es im Ernstfall nicht auf eine einzelne Person angewiesen ist.

🧑‍🏫 Erkläre es im Kopf: Stell dir vor, du erklärst einer neuen Kollegin in drei Sätzen, warum ein Working Agreement nicht einfach "nette Regeln" sind, sondern das Team vor genau solchen Donnerstagen schützt. Wie formulierst du das?