Ist es in Ordnung, wenn Scrum Master und Architekt eine Person sind? Ich verstehe klar, warum es eine schlechte Idee ist, Scrum Master- und Product Owner-Rollen zu kombinieren: Interessenkonflikte, SM kümmert sich um die Entwicklung, PO kümmert sich um das Geschäft. Ich bin mir jedoch nicht sicher, was daran falsch sein soll, gleichzeitig Scrum Master und Architekt zu sein.
Ist es in Ordnung, wenn Scrum Master und Architekt eine Person sind?
Vermutlich gilt der Architekt als Mitglied des Entwicklungsteams. Die Rolle des Scrum Masters ist eine eigenständige Rolle mit der Verantwortung, ein Prozessreferent zu sein , während das Entwicklungsteam mit der Implementierung beauftragt ist .
Obwohl es technisch machbar ist, dass eine Person beide Rollen erfüllt, kommt es viel häufiger zu einem Konflikt zwischen der Anforderung, etwas zu liefern, und der Anforderung, einen formellen Prozess zu erleichtern.
Darüber hinaus stellt die Zeit , die für die Wahrnehmung beider Rollen erforderlich ist, ebenfalls einen Interessenkonflikt dar. Wenn Sie zum Beispiel einen Tag Zeit haben, um eine Architekturgeschichte zu implementieren, auf die Ihr Team angewiesen ist, sowie Scrum-Master-Aufgaben wie die Beseitigung von Hindernissen oder eine lange Backlog-Refinement-Sitzung mit dem Product Owner, was priorisieren Sie? Wenn Sie beides nicht tun können, ohne Abstriche zu machen, erfüllen Sie keine Rolle richtig.
Wie bei allen Dingen kann Ihr Kilometerstand variieren. Es wird jedoch nicht viel davon abweichen, wenn Sie Scrum richtig implementieren. Beachten Sie auch, dass Sie, wenn Sie vermeiden möchten, eine zusätzliche Ressource für eine der Rollen zu budgetieren, diese Ressource dennoch in Form von verlorener Teamkapazität bezahlen, da TANSTAAFL .
Ich kann aus einiger Erfahrung sprechen, da ich derzeit sowohl Scrum Master als auch Mitglied des Entwicklungsteams bin (z. B. ein Architekt, der in Scrum-Begriffen „nur“ ein Mitglied des Entwicklungsteams ist) . Obwohl oft verpönt, ist dies möglich und nicht ausdrücklich verboten. Für mich ist dieser Teil im Scrum-Leitfaden am aussagekräftigsten und gewährt uns etwas Freiheit:
Das Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master. Scrum Teams sind selbstorganisierend und funktionsübergreifend. Selbstorganisierende Teams entscheiden, wie sie ihre Arbeit am besten erledigen, anstatt von anderen außerhalb des Teams geleitet zu werden. Funktionsübergreifende Teams verfügen über alle erforderlichen Kompetenzen, um die Arbeit zu erledigen, ohne von anderen abhängig zu sein, die nicht Teil des Teams sind. Das Teammodell in Scrum ist darauf ausgelegt, Flexibilität, Kreativität und Produktivität zu optimieren.
Beachten Sie, dass das gesamte Scrum-Team erwähnt wird, nicht nur das Entwicklungsteam. Dabei kann es zu einer Reihe von Konflikten kommen:
Alles in allem können erfahrene Teams mit einem starken Zusammenhalt diese Verwechslung in den meisten Fällen bewältigen. Andererseits ist es nie die ideale Situation.
Die Rolle des Scrum Masters bietet dem Scrum Team zwei Dinge:
Wenn eine Person diese beiden Dinge bereitstellen kann, kann sie die Rolle des Scrum Masters übernehmen.
Es ist nicht zu sagen, wie lange diese Aktivitäten dauern werden. In einem großen Team, das neu bei Scrum ist, und in einem schwierigen Geschäftsumfeld kann der Scrum Master sehr beschäftigt sein. In einem kleineren Team oder einem sehr erfahrenen Team gibt es für den Scrum Master möglicherweise viel weniger zu tun.
Der Schlüssel liegt darin, den Scrum Master als Dienstleister für das Team zu sehen. Wenn sie diesen Service anbieten können und genug Zeit haben, andere Dinge zu tun, dann ist das in Ordnung.
Ich habe oft mit Teams gearbeitet, in denen die Rolle des Scrum Masters von einem nicht spezialisierten Teammitglied übernommen wurde. Ich habe gesehen, wie Entwickler, Tester und ein Business Analyst die Rolle des Scrum Masters übernommen haben. Ich habe noch nie mit einem Architekten in der Rolle des Scrum Masters gearbeitet, aber ich sehe keinen Grund, warum das nicht funktionieren sollte.
Es ist schwierig, einen Interessenkonflikt zwischen der Rolle des Scrum Masters und einer anderen Rolle im Entwicklungsteam zu erkennen. Ein Scrum Master hat keine Autorität über das Team, also kann er ihm nicht sagen, was er tun soll. Auch in technischen Angelegenheiten hat der Scrum Master nicht das letzte Wort. Das Team als Ganzes trifft technische Entscheidungen im Konsens.
@Barnaby Golden sagt, sie finden es „schwierig, einen Interessenkonflikt zwischen der Rolle des Scrum Masters und einer anderen Rolle im Entwicklungsteam zu erkennen“. Ich kann (und habe) viel sehen!
Stellen Sie sich einen Architekten vor, der in zwei Teams eine Entwicklerrolle hat: Kann jedes Team den Architekten gegenüber seinem Team vollständig rechenschaftspflichtig machen? Ich kann mir ein Szenario vorstellen, in dem in einem Team „dringende ungeplante Arbeiten“ anfallen, der Architekt in diesem Team einspringt und das andere Team auf dem Trockenen bleibt, was zu einem fehlgeschlagenen Sprint für sie führt.
Stellen Sie sich nun ein einzelnes Team vor, in dem der Architekt sowohl eine Entwicklerrolle als auch die SM-Rolle hat: Wie reagiert der Architekt, wenn für das Team eine „dringende ungeplante Arbeit“ anfällt? Springt der Architekt in den vollen SM-Modus, um sicherzustellen, dass die psychologische Sicherheit aufrechterhalten wird, das Entwicklungsteam sich nicht zu sehr verpflichtet, sich vor Einmischung von außen schützt (obligatorische Überstunden usw.)? Oder tauchen sie in den vollständigen Entwicklermodus ein und beginnen, Whiteboard-Sitzungen zu „erleichtern“, Code zu schreiben und zu überprüfen, beim Testen zu helfen, Hindernisse aktiv zu beseitigen usw.?
Ich habe in mehreren Scrum-Teams gearbeitet, die eine Entwickler+SM-Person hatten, und sie kehrten immer in den Entwicklermodus zurück, und das erste, was aus dem Fenster ging, war die psychologische Sicherheit, dh gerade dann, wenn wir am meisten einen SM brauchten.
Theoretisch gibt es natürlich keinen Grund, warum der Architekt nicht weiterhin beide Rollen voll ausfüllen könnte. Aber können Sie sich vorstellen, dass diese Gespräche stattfinden?:
OK, ich bin ein bisschen scherzhaft, aber Sie verstehen, was ich meine. Es kann echte Interessenkonflikte geben und, aus welchen Gründen auch immer, es ist die SM-Rolle, die darunter leidet.
@Barnaby Golden erwähnt Dienstleistungen für das Team, aber nicht die anderen beiden: Dienstleistungen für die PO bzw. für die Organisation. Meiner Erfahrung nach habe ich keinen Developer+SM-Mitarbeiter gesehen, der diese Dienste effektiv bereitgestellt hat – und normalerweise überhaupt nicht –, weil sie sich zu sehr auf ihr eigenes Team konzentrieren. Der Tag hat normalerweise nicht genug Stunden.
Das Fazit für mich ist folgendes: Diejenigen von uns, die in einem Team gearbeitet haben, in dem der SM ein Karriere-SM/Agile-Coach ist, Vollzeit und voll und ganz der SM-Rolle gewidmet ist, kennen den Wert, den eine solche Person in das Team bringt und wenn sie die Wahl hätten, würden sie sich jedes Mal für dieses Szenario entscheiden. Ich denke, wenn jemand denkt, dass ein Developer+SM die SM-Rolle nicht in irgendeiner Weise beeinträchtigt, dann muss er erst noch mit einer wirklich guten SM-Person zusammenarbeiten.
nvoigt
andrii