Vorteile und praktische Aspekte der Arbeit ohne Produktmanager

Jedes digitale Produkt oder Projekt benötigt eine*n Manager*in, welche*r für den Fortschritt und die Überwachung verantwortlich ist. Das wird oft gar nicht hinterfragt. Doch wäre es nicht vorteilhafter, wenn keine einzelne Person für den Erfolg des Projekts verantwortlich wäre? Mit einem agilen Projektmanagement ist das möglich, aber wie funktioniert das in der Praxis, welche Vorteile hat ein solcher Ansatz und wie ermöglicht man eine reibungslose Zusammenarbeit ohne Projektmanager*in?
Bevor wir uns näher mit dem Thema der Arbeit ohne Manager*in beschäftigen, wollen wir einen kurzen Blick auf die wichtigsten Unterschiede zwischen dem klassischen Managementansatz mit Projektmanagern und modernen Ansätzen, bei denen die Verantwortlichkeiten im Team verteilt sind, werfen.
Die Rolle des Projektmanagers umfasst die „klassischen” Management-Verantwortlichkeiten – einschließlich Projektplanung und -ziele, Erstellung des Projektzeitplans, Zuweisung von Aufgaben, Ressourcenmanagement sowie Motivation und Leistungsmanagement der Teammitglieder.
Die Alternative ist ein agiles Projektmanagement-Framework wie Scrum. In agilen Projekten ohne Projektmanager*in gibt es die folgenden Schlüsselrollen:
- Entwicklungsteam, das Personen mit allen notwendigen Fachkenntnissen und Erfahrungen umfasst: Frontend- und Backend-Entwickler, Qualitätssicherungsspezialisten, Produktstrategen, Business-Analysten, DevOps-Ingenieure, Produktdesigner usw.
- Scrum-Master: eine Person, die Experte im Scrum-Prozess ist und das Team dabei unterstützt, den Prozess möglichst effektiv zu nutzen.
- Product Owner: ein Vertreter oder Stakeholder des Kunden oder der Abteilung, für die das digitale Produkt oder die Software erstellt wird.
Dies ist nur ein grundlegendes Framework. Sie können die Rollen und Verantwortlichkeiten je nach individuellen geschäftlichen Anforderungen anpassen, wenn Sie diese modernen Managementmethoden für sich übernehmen. In unserem Fall haben wir einige zusätzliche Rollen eingeführt, wie z. B. Tech-Lead und Delivery Lead, deren Zuständigkeiten und Verantwortlichkeiten in unseren Service-Standards beschrieben sind.
Unabhängig von der Anzahl oder Art der Rollen ist der Schlüssel für ein erfolgreiches und effizientes Arbeiten ein selbstorganisiertes Team, in dem alle aktiv zusammenwirken und gemeinsam für das Projekt verantwortlich sind. Wie funktioniert das in der Praxis, welche Vorteile hat ein solcher Ansatz und wie ermöglicht man reibungslose Zusammenarbeit ohne Projektmanager*in? Lassen Sie uns einige Beispiele ansehen, in denen man denken könnte, dass ein*e Projektmanager*in unverzichtbar ist.
Projektvision
Eine Vision ist ein Muss – und das unabhängig von der Methode, mit der Sie arbeiten. Sie bietet Ihnen eine klare und übergreifende Richtlinie für das, worauf Sie hinarbeiten. Traditionell wäre der Projektmanager stark daran beteiligt, die Vision zu erstellen und sicherzustellen, dass sie dem Projektteam vermittelt wird. Normalerweise bleibt die Vision während des gesamten Projekts unverändert festgelegt.
In Scrum wird die Vision mit dem gesamten Team, einschließlich des Product Owners, festgelegt. Dies kann im Rahmen eines Product-Discovery-Workshops geschehen, um vor dem ersten Sprint den Entwicklungsprozess zu starten. Dabei sind sowohl das Entwicklungsteam, der Scrum-Master als Moderator als auch die Stakeholder des Kunden beteiligt. Workshops steigern nicht nur das Engagement und die Verpflichtung des gesamten Teams, sondern übertragen auch die Gesamtverantwortung für die Vision an den Product Owner. Damit wird es gleichzeitig einfacher, die Vision bei Bedarf zu ändern. Wenn sich Umstände und Prioritäten verändern und Auswirkungen auf das haben, woran das Team arbeitet, erfährt der Product Owner als Vertreter*in des Kunden als Erste*r davon und ist dafür verantwortlich, die neuen Gegebenheiten in den Prozess zu integrieren.
Planung und Zeitmanagement
Eine gute Planung und gutes Zeitmanagement sind immer entscheidend. Normalerweise verwendet der Projektmanager einen detaillierten Projektplan – eine Roadmap, die in einzelne Aufgaben und Aktivitäten aufgeschlüsselt ist und die Abhängigkeiten zwischen ihnen zeigt. Dabei geschieht es allerdings schnell, dass die Roadmap als unumstößliche Vorgabe wahrgenommen wird, die bis ins kleinste Detail befolgt werden muss. In Wirklichkeit ist es zwar wichtig zu wissen, wo man hin möchte, aber der Weg dorthin kann sich während des Projekts ändern. Ein agiles Team ist bereit, gegebenenfalls die Richtung zu ändern.
In Scrum nimmt das gesamte Team am Prozess der Sprint-Planung teil. Es übernimmt gemeinsam die Verantwortung für die Ausrichtung des Projekts und schafft so eine viel anpassungsfähigere Arbeitsumgebung. Das Team plant Aufgaben nur für einen kurzen Zeitraum (ein Sprint dauert normalerweise ein oder zwei Wochen) und konzentriert sich in der Regel nur auf die Entwicklung einer einzigen Funktion, die im Sprint-Ziel definiert ist. Dadurch fokussiert sich das Team auf ein einziges Lieferziel.
Wenn der Sprint abgeschlossen ist, kann das Team seine Arbeit während eines Sprint-Review reflektieren und in einem Sprint-Retrospektiv-Meeting auf das zurückblicken, was im entsprechenden Zeitraum erreicht wurde. So kann das Team zusammenfassen, was während des Sprints geschehen ist und den Kurs des Projekts ändern, falls der ursprüngliche Ansatz nicht erfolgreich war. Die Erkenntnisse aus dem Sprint fließen als praktisch umsetzbare Maßnahmen in die Planung des nächsten Sprints ein.
Auf diese Weise wird die Build-Measure-Learn-Schleife in der Praxis verwendet – Scrum-Teams wiederholen Fehler selten. Zur Unterstützung dieser Prozesse können Softwaretools (zum Beispiel Trello, Jira oder Asana) eingesetzt werden, die für den hohen Grad an Informationstransparenz sorgen, der für solche Methoden benötigt wird. Somit ist kein*e Projektmanager*in erforderlich, der/die den Projektzeitplan im Auge behält.
Arbeitszuweisung
Wie wird die Arbeit verteilt, sobald eine Liste der anstehenden Aufgaben vorliegt? Im klassischen Management betrachtet ein*e Projektmanager*in die Aufgaben und Zeitpläne im Projektplan und weist sie den Teammitgliedern entsprechend ihrer Rollen und Spezialgebiete zu. Meist spiegelt dies eine starre Teamstruktur mit klar definierten Verantwortlichkeiten und Zuständigkeiten wider. Das kann dazu führen, dass der Fokus der einzelnen Personen ausschließlich auf den zugewiesenen Aufgaben liegt und die Teamarbeit reduziert wird.
Ein agiles, managerfreies Entwicklungsteam, das von einem Scrum-Master unterstützt wird, ist in der Regel kleiner (üblicherweise maximal 8 oder 9 Personen). Es bietet flexiblere Fähigkeiten, wobei die spezifischen Rollen und Verantwortlichkeiten der Personen von einem Sprint zum nächsten variieren können, je nachdem, was das Produkt und der Entwicklungsprozess erfordern. Auch hier erweist sich Scrum als nützlich: Die täglichen Scrum-Meetings sind kurze, tägliche Besprechungen des Teams, um die Ereignisse des Vortages zu besprechen, den aktuellen Tag zu planen oder um Hilfe oder Erklärungen zu bitten. Jedes Teammitglied hat die Möglichkeit, seine Meinung zu äußern, Unterstützung zu suchen oder auf ein Problem hinzuweisen.
Auf diese Weise wird die Verantwortung für Erfolge (und Fehlschläge!) im gesamten Team geteilt und liegt nicht allein beim Projektmanager. Jedes Teammitglied lernt durch sein eigenes Beispiel besser aus den Erfahrungen des Prozesses.
Kommunikation
Gute Kommunikation ist unerlässlich, wenn wir möchten, dass unsere Projekte erfolgreich sind. Traditionell fungiert ein*e Projektmanager*in als eine Art Hüter*in von Projekt- und Produktinformationen. Wenn ein Stakeholder ein Fortschritts-Update wünscht, wendet er sich nicht an das Projektteam, sondern an den Projektmanager. Ebenso ist es der Projektmanager, der für die Kommunikation einer Änderung der Prioritäten verantwortlich ist und den Projektplan aktualisiert und kommuniziert.
Die wichtigste Grundlage für agile Methoden ist Transparenz. Alle am Projekt beteiligten Personen haben Zugang zu allen Projektunterlagen und Informationen. Mit dem System der Sprints und den dazugehörigen Review- und Planungstreffen kann der Kunde die Projektergebnisse sehen und verfolgen, wie sie entstehen und sich entwickeln. Alle sind auf dem gleichen Stand und niemandem werden Informationen vorenthalten.
Natürlich ist auch bei agiler Arbeit eine schlechte Kommunikation möglich. Aber Technologie hilft: Die Verwendung eines Messaging-Systems (wie Slack) sowie einer geeigneten Videokonferenz-App und einer App für die Onlinezusammenarbeit bedeutet, dass alle Beteiligten regelmäßig an den Sprint-Meetings teilnehmen können – egal ob sie im Büro sind oder nicht.
In unserem Fall ist ein Ansatz der radikalen Transparenz entscheidend für effiziente Kommunikation. Gatekeeper in Form von Managern gibt es nun nicht mehr, da die Informationen und das Wissen öffentlich für alle zugänglich sind, anstatt nur in privaten Nachrichten geteilt zu werden. Auf diese Weise haben wir alle schneller Zugang zu allen Informationen und lernen schneller. Dieser Ansatz fördert den Austausch von Wissen und die Problemlösung: wenn eine Person eine Frage öffentlich
stellt, können alle antworten und nicht nur die Person, die ursprünglich gefragt wurde.
Leistungsmanagement
Zu guter Letzt möchten wir uns ansehen, wie das Leistungsmanagement durchgeführt wird. In einem traditionellen Team-Set-up ist der Manager für die Leistung des Teams und der einzelnen Mitarbeitenden verantwortlich. Zu seinen Aufgaben gehört es, Ziele zu setzen, zu überwachen, ob sie erreicht werden, Feedback zu geben und gute Ergebnisse zu belohnen.
In einem agilen Entwicklungsteam organisieren die Teammitglieder sich stärker selbst, sind für ihre eigene Leistung verantwortlich und es wird von ihnen erwartet, Unterstützung zu suchen (und anzubieten), wenn es nötig ist. Das Leistungsmanagement ist nun eher eine gemeinschaftliche Aufgabe. Dies zeigt sich in der Retrospektive, die nach jedem Sprint stattfindet. Der Zweck der Retrospektive besteht darin, den Prozess zu analysieren; es geht weniger um die Frage „Was haben wir erreicht?” als um die Frage „Wie haben wir es erreicht?”. Retrospektiven-Meetings können auch genutzt werden, um längere Zeiträume und wichtige Meilensteine zusammenzufassen. Mit dieser Methode wird der Prozess regelmäßig überprüft und verbessert – was für bessere Projektergebnisse sorgt.
Der Faktor Kultur
Wir wollen ehrlich sein: Es gab Zeiten, in denen auch wir Projektmanager*innen hatten. Doch als wir begannen, Scrum als agiles Projektmanagement-Framework zu verwenden, erkannten wir schnell, dass selbstorganisierte Teams besser an die aktuellen Herausforderungen angepasst sind. Sie können flexibler und effizienter arbeiten, ohne sich geografisch am selben Ort zu befinden oder von einer einzelnen Person geleitet zu werden.
Das soll nicht heißen, dass Projektmanager*innen in einem erfahrenen und gut organisierten Unternehmen nicht nützlich sein können: Sie können mehrere hilfreiche und effiziente Rollen übernehmen, etwa indem sie als zentraler Ansprechpartner für die Teamkommunikation dienen und Verantwortung für etwaige Probleme während des Projekts übernehmen. Aber aus unserer Erfahrung und Perspektive ist diese Vorgehensweise mit einem hohen Risiko verbunden, da zu viel von einer einzigen Person abhängt. Sie können sich vorstellen, was mit Ihrem Softwareentwicklungsprojekt passiert, wenn der Projektmanager – der Hüter aller Kenntnisse und Entscheidungsbefugnisse – plötzlich krank ist oder das Unternehmen verlässt. Deshalb haben wir unsere eigenen Service-Standards entwickelt, die klare Verantwortlichkeiten verteilen und Zuständigkeiten festlegen, um die Qualität des Arbeitsablaufs im Team sicherzustellen.
Zusammenfassung
Der Wechsel von einem klassischen Managementsystem zu einem agilen Managementsystem verändert die Unternehmenskultur und Mentalität fundamental. Dies geschieht nicht über Nacht und erfordert Anstrengungen von allen Teammitgliedern. Selbst wenn Sie in Ihrer Organisation nicht zu 100 % agil arbeiten können, lohnt es sich, genauer unter die Lupe zu nehmen, wie Ihr Team funktioniert. Selbst kleine Elemente wie eine größere Transparenz oder die Verteilung von Verantwortlichkeiten unter den Teammitgliedern können bereits eine größere Effektivität erzielen und die Zusammenarbeit im Team verbessern.

Autor
Tadeusz Rolski
Customer Success Lead bei Boldare
Tadeusz Rolski ist Customer Success Lead bei Boldare und hat 10 Jahre Erfahrung darin, Unternehmen in der digitalen Welt zu beraten und bei der Erreichung ihrer Geschäftsziele zu unterstützen. Er begann seine Laufbahn als Projektmanager, nahm jedoch im Laufe seiner Karriere viele andere kundenorientierte Rollen ein und erreichte schließlich die aktuelle Position, in der er sein Talent am besten einsetzen kann. Dank seiner Erfahrungen in verschiedenen Rollen wurde er mit einem breiten Spektrum an Kundenperspektiven und -bedürfnissen vertraut und gewann die Überzeugung, dass Vertrauen und Engagement die Schlüssel zu einer erfolgreichen Zusammenarbeit sind.
www.boldare.com
https://www.linkedin.com/in/tadeusz-rolski/
https://twitter.com/Boldarecom