Scrum Master oder Architekt?
Häufig beobachte ich in meinen Projekten, dass der Scrum Master auch gleichzeitig der Architekt der Softwarelösung ist. Auch ich selbst habe Projekte schon häufig in dieser Doppelrolle geleitet. Dies ist zunächst nahe liegend, da der Architekt sich meist verantwortlich für die Softwarelösung zeichnet. Dies kann funktionieren, erfordert aber sehr viel Disziplin und ein hohes Vertrauen im Team. Außerdem sollte die entsprechende Person viel Erfahrung – in beiden Rollen gesammelt haben, um Konflikte in der Ausübung beider Rollen zu vermeiden. Hohe Kritikfähigkeit und ein starkes Rückrat in Situationen, in denen das Projekt in Schieflage gerät sind erforderlich. Außerdem sollte sie klar den anderen Teammitgliedern kommunizieren, in welcher Rolle er sich aktuell befindet und Entscheidungen trifft.
Es birgt aber auch sehr viele Gefahren und Nachteile, die nicht auf den ersten Blick zu erkennen sind. Zunächst ist offensichtlich, dass der Scrum-Master in seiner Rolle als Architekt in Konflikt mit sich selbst kommt, da er unterschiedliche Interesse in seinen Rollen verfolgt, die zum Teil auch konträr zueinander stehen. Zum Beispiel hat der Scrum Master seinen Blick auf die Effektivität von Meetings und Abläufen, wohingegen ein Architekt eher den Blick auf eine modulare und zukunftsfähig Architektur hat. Dies kann in Planungsmeetings beispielsweise zu starken Konflikten für eine Person führen. Ein nicht ganz so offensichtlicher Punkt ist, dass der Scrum Master in der Rolle des Architekten stark gefordert ist bei der Umsetzung im Team und eine „führende“ Rolle einnimmt. In einem autonomen, selbstverantwortlich arbeitenden Team ist dies aber nicht vorteilhaft, da es die Eigenverantwortung und die Entfaltung der jeweiligen anderen Teammitglieder hemmt. Darum ist es empfehlenswert die Rollen auf mehrere Personen zu verteilen und dem Architekten eine gleichwertige Rolle gegenüber allen anderen Teammitglieder zukommen zu lassen.
Die Rollenverteilung in Scrum lässt sich schließlich gut mit der Gewaltenteilung im Rechtsstaat vergleichen. Wenn die Macht nicht gut verteilt ist, gerät das Konstrukt aus dem Gleichgewicht.[Heise]
Nun kann man sagen, dass ein Scrum Team keinen Architekten benötigt, da das gesamte Team die Architekturverantwortung übernehmen muss. Dies ist zum einen Korrekt, birgt aber auch das Problem der Weitsicht. Ein Scrum Team tendiert dazu sich auf den aktuellen Sprint zu konzentrieren – das ist auch wichtig – aber unter Umständen verliert es mögliche Visionen aus dem Blick, die gewisse Architekturentscheidungen beeinflussen. Darum bin ich der Meinung, dass die Rolle des Architekten in Scrum Teams wichtig ist, sie sollte aber keine „führende“ Rolle übernehmen.
Ein guter Architekt
- teilt seine Gedanken mit dem Team,
- diktiert keine Architektur sondern empfiehlt sie und lässt sie von seinen Teammitgliedern bewerten und verbessern,
- arbeitet mit an der Implementierung der Lösung.
Ob eine Zusammenlegung der Rollen Scrum Master und Architekt gelingt liegt also nicht zuletzt im Charakter der ausübenden Person.
Folgend noch ein paar Tips, falls es zu einer Doppelrolle kommt:
- Eigenes Timeboxing der Rollen betreiben und niemals mehrere Rollen zur selben Zeit einnehmen.
- Die Retrospektive mit dem Team nutzen, um die Doppelrolle kontinuierlich zu beurteilen, und Feedback einzufordern.
- In Gesprächen klarstellen, welche Rolle gerade eingenommen wird und alle Projektbeteiligten aktiv darauf hinweisen, eine bestimmte Rolle einzufordern.
Quellenangabe
/Heise/ abgerufen am 29.05.2016
