Scrum Rollen: ScrumMaster | Robin Hood

Die Aufgaben des ScrumMaster lassen sich in sechs Teilbereiche zerlegen:

  1. Scrum Implementieren
  2. Das Abarbeiten von Impediments und das Treffen von Entscheidungen
  3. Die Arbeit mit dem Team
  4. Die Arbeit mit dem Product Owner
  5. Scrum in die Organisation hineintragen und die Organisation ändern
  6. Die Steigerung der Produktivität des Teams

Jeder Teilbereich ist dabei gleich wichtig. Die Reihenfolge, in der der ScrumMaster die einzelnen Teilgebiete bearbeiten sollte, ist ebenfalls leicht bestimmt: Er arbeitet vom Team aus in
Richtung Organisation: First Things First!

Die Schwierigkeiten, mit denen ein ScrumMaster  zu kämpfen hat, sind gigantisch. Er ist in den meisten Fällen angetreten etwas zu ändern, obwohl er dazu keinerlei Befugnis hat. Selbst in einer Firma, die ScrumMaster einstellt, die sie also in die Position eines ScrumMasters erhebt, die anscheinend die Organisation ändern will, sind die Widerstände, die ein ScrumMaster erfährt, sehr hoch.  Der ScrumMaster erreicht die Veränderungen innerhalb des Teams durch das Vertrauen, das er während seiner Arbeit aufbaut. Sein Status hilft ihm dabei nicht.

Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln

One response to “Scrum Rollen: ScrumMaster | Robin Hood

  1. Sehr wichtig ist, dass er organisatorische Probleme visualisiert. Zusammen mit dem PO kann man in den meisten Fällen auch Kosten herleiten die durch organisatorische Impediments entstehen.

    Während in den USA das “change it or leave it” Mantra etwas präsenter ist, gibt es dies in Deutschland bei SMs aus der Organisation (Festangestellte, evtl. auch noch Linienverantwortung) sehr selten. Scrum verliert dann schnell an Schlagkraft, es tauchen über Monate (Jahre?) die gleichen Impediments in den Retros auf. Folge: Demotivierte Team, zurückgehende Produktivität, teilweise nachlassende Qualität (“wenn das xyz schlecht sein kann, dann ist unsere Qualität auch nicht mehr wichtig”).

    Gerade erst erlebt: Monate lang mit Netzerkinfrastruktur beschäftigt, nett miteinander geredet (SM/Infrastrukturverantwortliche) – wenig bewegt. Jetzt rächt sich dies, da viele Ressourcen durch das “Drumherumbauen” in der Entwicklung gebunden werden und neue Herausforderungen nicht mehr adäquat adressiert werden können. Die Opportunitätskosten sind in diesem konkreten Fall enorm. Fingerpointing auf die Scrum-Teams (“sind die langsam”), obwohl diese das Problem schon sehr lange kommunizieren.

    Kurz: Ein SM brauch Verbündete, das Top-Management muss verstehen, warum eine Veränderung wichtig ist und welche Kosten vermieden werden können bzw. wo die Chancen liegen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s