Soll das der Product Owner entscheiden, oder die Account Managerin? Oder vielleicht doch eher der Projektmanager? Dieselben Rollenbezeichnungen können je nach Organisation sehr verschieden interpretiert werden. Wenn Sie eine fertige Methodik implementieren (z.B. Scrum), dann sind die Rollen immerhin irgendwo festgeschrieben. Was nicht unbedingt bedeutet, dass alle dasselbe Verständnis dieser Rollen teilen.

Nehmen wir mal an, dass Sie mit dem Status quo nicht ganz zufrieden sind und die Verantwortlichkeiten neu regeln wollen. Wie kann man die Zusammenarbeit im Team und zwischen Teams “designen”? Wie kann man Aufgaben und Verantwortlichkeiten sinnvoll auf die Rollen aufteilen?

Natürlich lässt sich das alles in einem langen Word-Dokument hinschreiben: “Rolle Release-Manager: Die Release-Managerin übernimmt Anforderungen von der Kundenseite und ordnet sie in ein Release ein. Dabei berücksichtigt sie Prioritäten, Risiko … usw. usw.” Wenn man sich dann lange genug in das Dokument vertieft, kann man auch erkennen, ob eine Verantwortlichkeit noch nicht verteilt ist, oder dass der Umgang mit einer bestimmten Art von Anforderungen überhaupt nicht geregelt ist. Als krönenden Abschluss (oder Deckblatt) kann man noch ein Organigramm hinzufügen, so dass jede/r sich in einem Kästchen wiederfindet.

Aber wer liest sowas und wer prüft es sorgfältig auf Plausibilität und Widerspruchsfreiheit? Die Release-Managerin aus dem Beispiel wird schon den sie betreffenden Abschnitt lesen. Aber wie geht man sicher, dass die Dinge nicht (wie so oft) an irgendwelchen Übergabepunkten hängen bleiben, oder “aus Mangel an Zuständigkeit” nicht erledigt werden? Soll sich der Chef / die Chefin darum kümmern, dass die neue Struktur auch funktioniert? Wäre es nicht besser, diejenigen voll einzubeziehen, die die beschriebenen Aufgaben erledigen sollen?

Genau dazu möchte ich Ihnen etwas vorstellen: Eine Methode, um gemeinsam die Zusammenarbeit im Team und in der ganzen Organisation zu planen und anhand von realistischen Aufgaben durchzuspielen.

RRC Cards: Role - Responsibilities - Collaboration

Auf eine einfache Karteikarte (A6) wird oben als Überschrift die Rolle eingetragen. Darunter kommen links die Verantwortlichkeiten und rechts die Rollen, mit denen man zusammenarbeitet:

(Die Software-Entwickler unter Ihnen werden ein ähnliches Konzept vielleicht unter dem Namen CRC Cards kennen – dort entwirft man ein System als Netzwerk von zusammenwirkenden Objekten.) Als Beispiel ist hier die Rolle des “Maintainer of the Week”, also jemand, der sich in einem Team um die anfallenden Wartungsthemen kümmert, z.B. Bugs aus dem Produktivbetrieb beheben und in Form von Hotfixes freischalten:

Wir lassen diese Rolle wöchentlich rotieren, damit alle die nötige Kompetenz behalten und jede/r mal die eher unspektakuläre Aufgabe “Wartung” bekommt. Achten Sie darauf, dass die Verantwortlichkeiten konkret beschrieben werden, vor allem sollte man Verben verwenden. Es reicht also nicht, als Verantwortlichkeit nur “Log files” hinzuschreiben – das ist zu schwammig: Soll der Maintainer dafür sorgen, dass Log files überhaupt erzeugt werden? Dass sie extern archiviert werden? Dass sie im Laufe der Zeit nicht allen Festplattenplatz aufbrauchen?

Wenn man ein paar Rollen zusammen getragen hat, werden auf einem großen Tisch die Karten für verschiedene Rollen arrangiert. Man kann sie nach Teams oder Abteilungen anordnen, oder von links nach rechts in der Reihenfolge der Abarbeitung bestimmter Aufgaben.

Jetzt schreibt man die typischen Aufgaben und Anforderungen auf Karten, etwa “Ein neues Projekt (‘Alpha’) soll gestartet werden”, oder “Die automatischen Tests sind zu langsam”.

Nun nimmt man sich eine Aufgabe vor, und spielt ihre Bearbeitung durch: “Ein Bug im Produktivbetrieb ist aufgetreten, irgendwer hat gemeldet, dass der Checkout mit PayPal nicht mehr funktioniert!” Ein Mitspieler nimmt sich eine Rollen-Karte und fängt an, die Aufgabe zu bearbeiten: “Als Maintainer of the Week sehe ich das Problem in Jira und übernehme es sofort. Ich hole mir also einen Tester und wir versuchen gemeinsam, das Problem zu reproduzieren” Jemand anderes spielt die Rolle des Testers: “Soll ich als Tester jetzt wirklich alles stehen und liegen lassen, nur weil der ‘Maintainer of the Week’ das will? Und was machen wir, wenn das Problem nach 18 Uhr auftritt?” Man kann so etwas gleich klären oder einfach eine neue Aufgabenkarte “Bug im Produktivbetrieb zwischen 18 Uhr und 9 Uhr” schreiben. Jedenfalls haben sich jetzt alle in die vorgegebene Situation hineinversetzt und sind auf einem guten Weg, die Abarbeitung des ursprünglichen Szenarios zu beschreiben.

Diese Art der Simulation unterstützt nicht nur die Konsistenzprüfung der geplanten Organisation. Alle Teilnehmer erarbeiten sich ein gemeinsames Verständnis der Abläufe und können damit gewissermaßen eine Draufsicht auf ihre Zusammenarbeit entwickeln. Das gesamte “Design” ist greifbar und lässt sich kritisieren, ohne sich auf Personen zu beziehen (“Der Herr Müller braucht immer so lange, bis er die einfachsten Dinge genehmigt hat”). Alles, was man an Problemen schon in der Simulation erkennt, muss man später nicht mühsam reparieren, wenn die Rollen und Prozesse schon verteilt und eingefahren sind.

Der Low-Tech-Ansatz mit RRC Cards hat wesentliche Vorteile im Vergleich zu Softwarelösungen (etwa Visio): Das Design wirkt nicht so endgültig, neue Rollen und Aufgaben können jederzeit ergänzt werden. RRC Cards sind sehr flexibel, man kann leicht etwas ändern, eine Karte komplett zerreißen, oder auch ein Bild darauf malen. Alles, was dem gemeinsamen Verständnis der Abläufe und Rollen dient, ist erlaubt. Das “User Interface” eines Stapels Karteikarten ist so einfach, dass die Mechanik in den Hintergrund tritt und sich alle auf den eigentlichen Inhalt konzentrieren können. In der Zeit, die man zum grafischen Aufpolieren eines Organigramms brauchen würde, hat man schon ein paar weitere Abläufe durchgespielt.

Hier noch einige Tipps:

• Wenn die Karte links zu voll wird, ist das ein Zeichen, dass die Rolle zu viele Verantwortlichkeiten übernehmen muss. Kann man diese Karte vielleicht auf zwei neue Rollen aufteilen?
• Rollen, die viel zusammenarbeiten, kann man in einer Region des Tisches dicht beieinander arrangieren. Gibt es Abteilungsgrenzen, die mitten durch diesen Cluster verlaufen? Sitzen die Personen in verschiedenen Räumen, vielleicht sogar getrennten Gebäuden? Dort ist mit Zeitverlusten durch Übergaben und unterschiedliche Prioritäten zu rechnen.
• Irgendwann müssen die Rollen bestimmten Personen zugeordnet werden. In der Simulation kann man das schon mal ausprobieren, indem die Person ihre Initialen auf die Karte schreibt und fortan nur noch “ihre” Rollen spielt.

Matthias Berth