Und was machen bestimmte Rollen nicht?
Diese Fragen zu beantworten, scheint im ersten Moment trivial. Erste Reaktinen können sein "Ich weiß doch, was ein Entwickler macht!" und "Klar, der Produktmanager ist fürs Produkt zuständig".
Doch welche Aufgaben haben die einzelnen Teamrollen tatsächlich? Wie sehen die Rollinhaber sich und ihren Job? Gibt es Missverständnisse? Gibt es Wünsche/Anforderungen an Rollen, die noch nicht erfüllt sind?
Um das heraus zu finden, habe ich eine einfache, aber wirkungsvolle Methode gewählt, die ich hier kurz vorstellen möchte.
Rahmen
Ein 1 bis 1 1/2 stündiges Meeting, am besten in einem Raum ohne Tische aber mit viel freien Wänden. Teilnehmen sollte das ganze Team, bei Bedarf können auch wichtige Schnittstellenpartner dazu kommen. Wichtig ist, dass nur über Rollen diskutiert wird, die auch anwesend sind.
Vorbereitung
Der Terminverantwortliche muss sich in der Vorbereitung klar machen, wie die Teamrollen im Projekt bzw. Unternehmen tatsächlich definiert sind und welche Erwartungen an die Rollen gestellt werden, um potentielle Diskussionen während des Termins abfangen zu können. Außerdem helfen diese Informationen bei der Nachbetrachtung der Ergebnisse.
Für den Termin braucht man außerdem je ein Flipchart pro Rolle, die im Raum an die Wände gehängt werden.
Durchführung
Ziel des Termins ist, am Ende Einsicht und Verständnis für alle Teamrollen zu haben und dadurch Missverständnisse oder Aufgabenkonflikte zu identifizieren.
Im ersten Schritt schreiben alle Anwesenden (auch der Moderator, insofern er zum Team gehört) ihr Verständnis jeder Rolle inkl. der eigenen auf Post Its. Diese werden anschließend vor allen vorgestellt und zu der jeweiligen Rolle gehängt.
Nachdem alle Meinungen zu den Rollen eingeholt wurden, bekommt jedes Teammitglied Zeit, um sich mit den Aussagen zu seiner Rolle auseinander zu setzen.
Am besten sortiert jeder für sich nach "Richtig", "Falsch bzw. habe ich noch etwas zu ergänzen" und "Kann ich nicht einordnen/habe ich Fragen dazu".
Ist diese Sortierung erfolgt, geht das ganze Team gemeinsam nochmal alle Rollen durch, wobei diesmal der Rolleninhaber selbst sein Verständnis schildert, Missverständnisse klärt und so ein klares Rollenbild für seine Kollegen zeichnet.
Dieses Rollenverständnis hält man am besten fest, in dem jeder sein Verständnis der Rolle in max. 3 Sätzen zu Papier bringt (A4-Blatt) und man diese Rollen im Teambüro aufhängt.
Ergebnis
Warum sehe ich diese Methode als so wertvoll an? Als Teamverantwortlicher bin ich daran interessiert, Entwicklungspotentiale meines Teams zu erkennen und mein Team zu fordern und zu fördern. An Hand der Rollenbeschreibungen sehe ich, wo Personen aus dem Team blinde Flecken oder Defizite haben, wo sie ihre Rolle zu weit oder zu eng fassen. Mit diesen Ergebnissen kann ich weiter arbeiten und mittelfristig Entwicklung anstoßen bzw. Veränderung treiben.
Der unmittelbare Vorteil für das Team ist, explizit zu hören und auszusprechen, wer für was zuständig ist und an wen sie sich bei Bedarf wenden können. Das Transparentmachen der Rollenverständnisse ermöglicht desweiteren, regelmäßig damit zu arbeiten, d.h. man muss auch regelmäßig überprüfen, ob die Rollen noch so sind, wie zum Zeitpunkt X definiert. Vor allem, wenn neue Kollegen ins Team kommen, lohnt sich diese Methode als Unterstützung der Storming- und Norming-Phasen.
Viel Spaß beim Umsetzen
Attachments:
Comments:
|
Bin nicht mehr fertig geworden, Rest folgt morgen! --> Done 
Posted by bbucksch at 02. Mär 2012 14:57
|
|
Sorry, aber wenn das der Inhalt einer Spring Retrospective sein soll, wurde Scrum nicht richtig verstanden. Ich würde sogar sagen, daß das ganze Thema nichts mit Scrum zu tun hat. Ansonsten entdecke ich Brainwriting, das ich auch gerne in der Spring Retrospective einsetze.
Posted by rainwebs at 06. Mär 2012 21:07
|
|
Ich bin kein Scrum Experte, aber wenn ich in einer Retrospektive den vergangenen Sprint reflektiere und feststelle, was lieft gut, was kann verbessert werden, kann das doch ebenfalls Rollen im team beinhalten oder? Sprich die Rolle des Product Owners wurde nicht optimal ausgefüllt oder der Scrummaster hat seine Rolle sehr gut ausgefüllt. Kann nicht auch ein Admin Teil eines Scrumteams sein? Der hat ja ebenfalls bestimmte Tätigkeiten und die Abgrenzung zu Entwicklern kann doch etwas unscharf gewesen sein im letzten Sprint? Also versucht das Team genauer die Abgrenzung der Tätigkeiten des Administrator und der Entwickler zu definieren. Oder hab ich einen Denkfehler dabei?
Posted by fogbird at 06. Mär 2012 22:35
|
|
Ich finde die Übung sehr gut, weil es in Teams sehr oft genau an diesem gegenseitigem Verständnis mangelt. Die Verknüpfung mit Scrum finde ich aber unglücklich, weil Scrum von einem klaren Rollenverständnis und einer hohen Transparenz im ganzen Team ausgeht. Insofern ist die Übung prädestiniert bei missglückten Scrum Implementierungen
Posted by bschloss at 07. Mär 2012 20:41
|
|
Dann würde ich lieber eine Scrum Schulung empfehlen, weil es dann nicht nur am Rollenverständnis mangelt. Den Scrum Master sollte man dann auch gleich auswechseln, weil es seine Aufgabe ist, es gar nicht erst zu solch einer Situation kommen zu lassen.
Posted by rainwebs at 07. Mär 2012 23:07
|
|
Ich kenne mich mit Scrum auch nicht aus, aber diese Übung finde ich auch sehr wichtig. Und darum geht es in dem Artikel – nicht darum, ob das jetzt Scrum ist oder nicht ... Diese Diskussion geht am Thema vorbei, zumal Barbara ja den Scrum-Master nur als ein Beispiel anführt. Möglicherweise kann man das ja umformulieren ... dafür gibt es den Bearbeiten-Knopf
Posted by mraitner at 08. Mär 2012 08:24
|
|
Ich war lange nicht hier, habe darum die Diskussion auch nicht mitbekommen - Danke Bernhard, dass du mich darauf aufmerksam gemacht hast! Vielleicht habe ich nicht deutlich genug gemacht, was Gründe waren, diese Übung in einer Retrospektive zu machen:
Es ging nicht grundsätzlich um die Definition von Aufgaben/Rollen in Scrum, sondern eben um eine Auffrischung und eben das sehe ich als meine Aufgabe als ScrumMaster. Generell glaube ich, dass die Übung helfen kann, was ja auch einige Kommentatoren so sehen.
Posted by bbucksch at 15. Mär 2012 13:26
|
|
Barbara Bucksch: Du bist nicht täglich hier?!
Posted by mraitner at 15. Mär 2012 15:45
|
|
Nein, in der Tat nicht! Ich bewundere euch alle für euer Zeitmanagement, weil ihr ja sowohl hier als auch auf euren Blogs und in Twitter aktiv seid, das schaffe ich nicht
Posted by bbucksch at 15. Mär 2012 16:09
|
|
Ziel verstanden. Das Vorgehen scheint suboptimal für mich, weil ja der Scrum-Kontext als Beispiel genannt wurde: Was heißt neu formiertes Team? Scrum-Unerfahrende sind hinzugekommen? Wenn ja, fehlt die Scrum-Schulung. Wenn nein, fehlt mir das direkte Zugehen auf einzelne Team-Mitglieder mit gezieltem Coaching, so daß sowohl die eigene Rolle des Team-Mitglieds eingehalten wird bzw. das Zusammenspiel mit den anderen Rollen (wobei da nur der PO und SM bleiben). Die Retrospective spiegelt über das Feedback der Team-Mitglieder dem ganzen Team wider, was gut lief und beibehalten werden kann bzw. was verbessert werden kann und von wem in welcher Reihenfolge. Mir scheint aber, daß die dafür zur Verfügung stehende Zeit (z.B. bei 2-Wochen-Sprints) dann nur für die Übung verwendet wurde. Wäre schade, wenn anderes Feedback dann nicht stattgefunden hätte. Grundsätzlich scheint es mir sinnvoll, die Übung auszulagern, wobei ich die Notwendigkeit noch immer nicht erkennen kann im Scrum-Kontext.
Posted by rainwebs at 17. Mär 2012 18:16
|
|
Lasst uns diesen verfluchten SCRUM-Bezug aufgeben. Die Übung ist zweifelsohne mehr als sinnvoll, sie ist nur nicht idealtypisch in Scrum-Projekten. In der schönen heilen Scrum-Welt sollte so ein Anwendungsfall, wie von Barbara beschreiben eigentlich gar nicht vorkommen, ich glaube ihr aber sofort, das es im konkreten Projekt mehr als nötig war. Ich fürchte das missverstandene Scrum-Interpretationen und Einführungen weit häufiger sind, als es den Scrum-Jüngern lieb ist.
Posted by bschloss at 17. Mär 2012 19:34
|
|
Guter Vorschlag! =)
Posted by bbucksch at 20. Mär 2012 08:48
|
.
