Tag Archives: review

Warum Scrummaster keine Entwickler und Entwickler keine Scrummaster sind (gleichzeitig)

Im letzten Artikel habe ich darüber philosophiert, warum Unit Tests so unglaublich wichtig sind.

Heute möchte ich erklären, warum meiner Ansicht nach Scrummaster niemals Entwickler und Entwickler niemals Scrummaster sein sollten, gleichzeitig.

Ich bin in der glücklichen Situtation, dass ich schon seit langer Zeit in einem interessanten Projekt in einem agilen Umfeld arbeiten kann. In meinem jetzigen Projekt habe ich eine Doppelrolle inne. Ich bin sowohl Entwickler als auch Scrummaster. Leider ist kein Budget für einen dedizierten Scrummaster vorhanden.

Warum ist das ein Problem?

Jeder Entwickler im Team hat bestimmte Vorstellungen, wie das Projekt zu Laufen hat, wie neue Funktionalität implementiert werden soll und wie generell gearbeitet wird. Ich bin zusätzlich so etwas, wie der Technical Lead des Projektes. Ich kümmere mich um Architektur, Qualität und Kommunikation (immer zusammen mit dem Team natürlich).

Ein Scrummaster hingegen sollte keine eigenen Interessen verfolgen,  sondern das primäre Interesse des Scrummasters sollte sein, das Team in jeder Hinsicht zu unterstützen und generell voranzubringen.

In einer Doppelrolle ist das sehr schwierig bis hin zu unmöglich.

Bestes Beispiel ist die Retrospektive, die nach jedem Sprint durchgeführt wird.

In der Retrospektive reflektiert das Team über den Vergangenen Sprint, über Dinge die gut und Dinge die weniger gut gelaufen sind. Die Retrospektive dient dem Team als Gesprächsplattform, um Themen in ungezwungener Atmosphäre auf den Tisch zu bringen und zu diskutieren.

Idealerweise durchläuft eine Retrospektive die folgenden Phasen:

  1. Begrüssung
  2. Rahmen schaffen
  3. Daten sammeln
  4. Aktionen identifizieren
  5. Verabschiedung

Die einfachste Variante für Punkt 3 (das Herz der Retrospektive) sind beispielsweise folgende Aufgabenstellung:

  • Identifiziere 3 Punkte, die sehr gut gelaufen sind, die wie unbedingt beibehalten sollten
  • Identifiziere 3 Punkte, die verbesserungswürdig sind.

In der letzten Retrospektive bei uns im Team war ich wieder in der schwierigen Situation, sowohl Entwickler als auch Scrummaster zu sein.
Jedes Teammitglied hat einige Punkte auf Post-Its Notes notiert. Von mir kam der Punkt:

Meiner Ansicht nach haben wir zu viele Stories gleichzeitig in Bearbeitung.

Ein Punkt, der mir sehr auf der Seele brennt, und den ich unbedingt ändern möchte. Dieser Punkt ist im Team jedoch nicht auf Gegenliebe gestossen, da hier dieser Eindruck nicht unbedingt vorhanden ist.

Was mache ich jetzt als Scrummaster/Entwickler?

Als Scrummaster würde ich den Punkt zwar aufnehmen, evtl auch darüber diskutieren aber wenn der Konsens im Team klar dahin tendiert, dass dies kein Problem darstellt würden daraus wahrscheinlich keine Aktionspunkte entstehen.

Ich als Entwickler weiß, dass wir zu viele Stories in Bearbeitung haben und weniger Stories viel schneller dazu führen würden, dass Dinge wirklich abgeschlossen, lauffähig und in einem Produktivumgebung landen.

Beharre ich jetzt auf meinem Standpunkt und ignoriere meine Scrummaster-Rolle?

Akzeptiere ich meine Rolle als Scrummaster und schlucke meinen Entwicklerstolz herunter?

Die Doppelrolle als Scrummaster/Entwickler ist mehr als suboptimal. Am besten ist es, einen Scrummaster aus einem der anderen Teams (sofern vorhanden) zu bitten, die Leitung der Retrospektive zu übernehmen. Dann könnte ich meine Rolle als  Scrummaster für die Retrospektive vergessen und mich voll und ganz auf die Entwicklerseite und eine erfolgreiche Retrospektive konzentrieren.

Habt ihr damit Erfahrung?

 


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban