Rollen, Aufgaben, Entscheidungen, Ergebnisse

In den letzten Wochen habe ich mit meinen Coachees immer mal wieder darüber gesprochen, warum es im Projekt "knirscht". Und auch wenn die individuellen Situationen und Herausforderungen natürlich unterschiedlich sind, so kristallisierte sich doch ein bestimmtes Muster heraus: Innerhalb des jeweiligen Teams gab es kein gemeinsames Verständnis über Rollen, Aufgaben, Entscheidungen und (Arbeits-)Ergebnisse. Daher möchte ich in diesem Beitrag den Zusammenhang erläutern und konkrete Hilfestellungen geben.

Lass uns mal mit einigen Beispielen beginnen, um die Problematik darzustellen. Ich bin sicher, du hast ähnliche Varianten ebenfalls erlebt.

Im ersten Beispiel gab es einen wochenlangen Streit zwischen Fachbereich und IT. Es gab ein agiles Umsetzungsteam und die Rollen Product Owner, Scrum Master und Entwicklungsteam waren besetzt. Die IT forderte, dass die Rollen "Technischer Architekt" und "IT Product Owner" mit Kollegen aus der IT besetzt werden müssten. Der Fachbereich argumentierte, dass es diese Rollen laut Scrum gar nicht gäbe. Die Situation war über Wochen festgefahren.

Im zweiten Beispiel gab es einen monatelangen Konflikt zwischen Projektleiter und Product Owner. Im Kern ging es um die Frage, wer den Kontakt mit dem Kunden in welcher Form pflegen durfte. Der Projektleiter beanspruchte den ausschließlichen Kundenkontakt für sich mit dem Argument, dass es sich um vertragliche Absprachen handele. Der Product Owner argumentierte, er müsse die Arbeitsweise und Probleme der Anwender besser verstehen, um geeignete Lösungen entwickeln zu können. Gelöst wurde dieser Konflikt erst, als der Product Owner das Unternehmen verließ.

Im dritten Beispiel gab es einen Konflikt zwischen disziplinarischer Führungskraft und Product Owner über die Frage, wer ein Mitglied des Entwicklungsteams "fit for the job" machen sollte. Die Führungskraft argumentierte, dass es im Interesse des PO läge, ein performantes Team zu haben und er außerdem näher am Geschehen sei. Der PO erläuterte den Standpunkt, dass die Aufgaben eines PO und eines Entwicklers höchst unterschiedlich seien und er sich schlicht nicht in der Lage fühlte, "einem Entwickler das entwickeln" beizubringen.

Diese Beispiele zeigen im Kern, dass es immer um die Frage geht "wer macht was warum" und unterschiedliche Annahmen oder Sichtweisen hierzu. Dabei könnte alles ganz einfach sein... Man müsste nur ein paar Dinge aufschreiben. Und es hilft, einige Zusammenhänge zu kennen und auch zu visualisieren. Konkret geht es mir um die Punkte Menschen – Rollen – Aufgaben & Entscheidungen - (Arbeits-)Ergebnisse.

Am Ende des Tages geht es üblicherweise darum, irgendwelche Ergebnisse herzustellen. Das kann funktionsfähiger Code sein, es können automatisierte Tests sein, es kann ein Testkonzept sein, die Beschreibung der Anwendungsarchitektur, ein Projektplan, eine Workshopplanung oder auch schlicht das Protokoll des Lenkungskreises. Irgendein Ergebnis, irgendein Arbeitsergebnis gibt es immer.

Vor den Ergebnissen liegt die Arbeit. Meistens fallen die Ergebnisse nicht vom Himmel, sondern sind das Ergebnis von Arbeit (oder Aufgaben) und Entscheidungen. Es muss entschieden werden, welche Elemente der Diskussion im Lenkungskreis in das Protokoll aufgenommen werden sollen. Das Protokoll muss geschrieben und ggf. gereviewed werden. Es muss entschieden werden, dass das Protokoll an die Teilnehmer versendet werden kann.

Oft werden Aufgaben und Entscheidungskompetenzen bestimmten Rollen zugeordnet. So könnte beispielsweise die Entscheidung über dokumentationswürdige Inhalte und das Schreiben des Protokolls bei der Rolle PMO liegen, die Aufgabe des Reviews und die Entscheidung über den Versand bei der Rolle Projektleiter.

Solange die Künstliche Intelligenz noch nicht die Weltherrschaft übernommen hat, gibt es nun auch noch Menschen. Echte Menschen müssen arbeiten. Echte Menschen müssen Entscheidungen treffen. Und, sofern es Rollen gibt, übernehmen Menschen bestimmte Rollen. Wichtig: es muss nicht zwingend eine Eins-zu-Eins-Zuordnung geben. Eine Rolle kann von einem oder mehreren Menschen übernommen werden, ein Mensch kann eine oder mehrere Rollen übernehmen.

Soweit, so klar. Die Probleme entstehen immer dann, wenn die Zusammenhänge nicht klar sind bzw. wenn es kein gemeinsames Verständnis gibt. Nehmen wir das erste Beispiel, die Rolle des technischen Architekten. Welche Aufgaben übernimmt er, welche Entscheidungen trifft er? Wenn seine Entscheidungen Auswirkungen auf andere Rollen haben, z.B. auf die Rolle des Entwicklers oder des Product Owners, darf er empfehlen oder entscheiden? Welche Arbeitsergebnisse stellt er her? Wie helfen diese im Gesamtkontext? In dem Moment, wo man dies zumindest stichpunktartig beschreibt, kann auch eine IT gegenüber dem Fachbereich deutlich machen, welchen Mehrwert die Rolle "technischer Architekt" im Gesamtkontext liefert und warum diese mit Kollegen aus der IT besetzt werden sollte.

Oder das zweite Beispiel: Es handelt sich offensichtlich um unterschiedliche Aufgaben, "vertragliche Absprachen" und "Anwenderverständnis". Sofern nicht mehrere Menschen mit dem Kunden sprechen sollen, müssen die Aufgaben so auf Rollen und Menschen verteilt werden, dass sie erledigt werden und Ergebnisse produziert werden. Ob es der PL oder PO tut, ist ja egal – hauptsache, irgendwer übernimmt die Aufgabe.

Es braucht hier erfahrungsgemäß keine Dokumentation in der Größenordnung von tausend Seiten, Stichpunkte und der Austausch mit den beteiligten Personen reichen. Du wirst prompt darüber stolpern, dass manche Aufgaben und Entscheidungen doppelt verortet sind ("nimm du, ich hab ihn sicher") und andere gar nicht. Dann könnt ihr im Team aufräumen. Erfahrungsgemäß bleibt diese Absprache im Projektverlauf auch nicht konstant. Menschen verändern sich, Rollen verändern sich, Aufgaben kommen hinzu oder fallen weg. Das ist vollkommen normal. Insofern lohnt es sich, alle 3-6 Monate einen Blick auf die Vereinbarung zu werfen und zu prüfen, ob es noch passig ist.

Ja, ich weiß, das klingt erstmal nach Aufwand und Overhead. In the long run sparst du damit aber Zeit und Nerven und verhinderst, dass Aufgaben durchs Raster fallen. Zu guter Letzt noch zwei Hinweise, wenn du mehr wissen möchtest: Arbeitsergebnisse sind üblicherweise nicht das Ziel eines Projektes – du willst etwas erreichen. Den Unterschied zwischen Output und Outcome habe ich in einem anderen Beitrag erläutert, den ich verlinke. Für den Zusammenhang zwischen Zielen, Rollen, Prozessen und Interaktionen gibt es auch ein schönes Modell: GRPI. Auch das verlinke ich dir hier.