.st0{fill:#FFFFFF;}

Scrum Guide

Die Rolle Entwickler in Scrum

 August 31, 2016

von  Sebastian Schneider

Das agile Framework Scrum kennt drei Rollen. Eine der Rollen sind die Entwickler. Sie setzen die Product Backlog Items aus dem Product Backlog während eines Sprints in ein Inkrement umsetzt, das am im Sprint Review vorgestellt wird.

Definition

Bevor wir mit der Betrachtung beginnen, werfen wir einen Blick in den Scrum Guide. Dort finden wir natürlich alle nötigen Informationen, die wir wissen müssen. Gerade bei einer Scrum Einführung ist es wichtig, das Scrum Team richtig aufzusetzen. Das Scrum Team besteht weiter noch aus den Rollen des Scrum Master und des Product Owner - beide betrachten wir hier nicht weiter.

Der Scrum Guide

Die Entwickler in Scrum sind Personen, die am Ende jedes Sprints ein nutzbares Produktinkrement liefern. Dafür haben die Entwickler spezifische Fähigkeiten, die zum einen breit gefächert sein können und zum anderen auch unterschiedlich verteilt. Die Entwickler in Scrum haben klare Verantwortlichkeiten:

  • Erstellung eines Plans für den Sprint, des Sprint Backlogs;
  • die Qualität durch die Einhaltung einer Definition von "Done" zu gewährleisten;
  • die tägliche Anpassung ihres Plans an das Sprint-Ziel und,
  • sich gegenseitig als Fachleute zur Verantwortung zu ziehen.

Die Organisation

Entwickler in Scrum werden von der Organisation strukturiert und befähigt, ihre eigene Arbeit zu organisieren und zu verwalten. Die daraus resultierende Synergie optimiert die Gesamteffizienz und -effektivität des Entwicklungsteams.

Scrum kennt keine Unterteams oder Subteams im Scrumteam, unabhängig von den Bereichen, die behandelt werden müssen, wie Business Analyse, Architektur oder Test. Natürlich verfügen die meisten Personen als Entwickler über Stärken und Schwächen sowie Vorlieben, die Verantwortung liegt beim den Entwicklern als Ganzes.

Entwickler bedeutet nicht Software

Wenn du Entwickler hörst, dann denkst du bestimmt auch schnell an den "Software Entwickler", nicht wahr? Das wird zwar häufig angebracht, muss aber nicht sein. Unter der Rolle der Entwickler verstehen wir jeden, der ein Produkt, eine Dienstleistung oder sonstiges entwickelt.

Eigenschaften des Entwicklungsteams

Größe

Über die wirklich gute und richtige Größe wird gerne gestritten. Über die Jahre hat sich einiges im Scrum Guide geändert. Im Scrum Guide 2017 gab es zum Beispiel diese Aussage:

SCRUM GUIDE

scrumguides.org

Die optimale Größe des Entwicklungsteams ist klein genug, um wendig zu bleiben, und groß genug, um im Rahmen eines Sprints bedeutende Arbeit zu leisten. Weniger als drei Mitglieder des Entwicklungsteams verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen. Kleinere Entwicklungsteams können während des Sprints auf Qualifikationsdefizite stoßen, so dass das Entwicklungsteam nicht in der Lage ist, einen potenziell auslieferbares Produktinkrement zu erreichen. Mehr als neun Mitglieder zu haben, erfordert zu viel Koordination. Große Entwicklungsteams erzeugen zu viel Komplexität, als dass ein empirischer Prozess nützlich sein könnte. Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlog aus.

Eine gute Größe für dein Scrum Team

In der Praxis findet sich meistens eine gute Größe bei einer Gruppe von 3-12 Menschen. Es wird in der Regel nur durch die Kommunikationsgrenzen zwischen den Menschen begrenzt und komplizierter gemacht. Auch Diskussionen ist nun ein Product Owner dabei oder nicht, ebenso wie der Scrum Master, können aus meiner Sicht nur Richtwerte sein.

Selbstverwaltend / Selbstorganisierend

In einem Scrumteam gibt es keinen Projektleiter. Das Team kümmert sich selbst um den Prozess und auch um die anfallenden Arbeiten. Das ist grundsätzlich gar nicht leicht, denn es setzt eine hohe Eigenverantwortung voraus. Auch die letzten Diskussionen im Scrum über die Selbstorganisation und Selbstverwaltung haben noch etwas geschärft, aber je nachdem wie du es bisher in deinem Scrum Team interpretiert hast, ändert sich vielleicht dabei gar nicht viel.

Vollzeit

Die Mitglieder arbeiten Vollzeit zusammen in dem Scrum Team. Aus der Erfahrung kann ich sagen, dass die Mitglieder des Scrum Teams und gerade die Entwickler in Scrum mit ungefähr 80% der Zeit ganz gut funktionieren, darunter wird es schnell problematisch, da die Möglichkeiten für die Zusammenarbeit weniger werden. Ebenso kann eine doppelte Existenz in zwei Teams immer zu viel mehr Terminen als tatsächlicher Arbeit im Nachgang führen.

Multidisziplinär

Mit dem Begriff multidisziplinär meinen wir, dass das Team alle Fähigkeiten besitzt, das gewünschte Produkt zu entwickeln. Das gilt für das Team, es muss also nicht jeder alles können. Oft wird auch interdisziplinäre Teams oder cross-funktionale Teams gesagt - letztendlich führt es immer wieder auf das Gleiche.

Die Aufgaben

In Scrum haben die Entwickler klare Aufgaben, die sie verantworten. Diese Aufgaben sind wichtig und können zum Beispiel in Retrospektiven auch regelmäßig überprüft werden. Die folgenden Punkte erweitern die Aussagen auf der Definition aus dem Scrum Guide oben noch etwas.

Gewissenhafte Arbeit leisten

Der Scrum Wert des Commitments drückt es ganz gut aus: das Team verpflichtet sich, Arbeit zu liefern, die es zusagt. Ich betrachte immer im Sinne des gesunden Menschenverstands. Niemand hakt irgendwem die Hand hab, wenn eine Schätzung nicht stimmt. Kritisch ist es aber, wenn wir keine gewissenhaft und disziplinierte Arbeit als Scrum Team liefern.

Refinementarbeit

Gemeinsam mit dem Product Owner arbeitet das Team daran, dass das Verständnis über den Inhalt des Product Backlogs klarer wird. Dazu gehören unterschiedliche Aufgaben.

Sprint Ziel

Das Scrum Entwickler und der Product Owner sollen gemeinsam ein Ziel festlegen, unter dem der Sprint steht. Das ist herausfordernd und viele Teams haben keine oder nur sehr abstrakte Ziele für den Sprint. Ein Sprint Ziel sollte immer den Sprint zusammenfassen und ein übergreifendes Ziel geben. Ziele wie "alle User Stories zu erledigen" sind nicht hilfreich, da es mögliche Änderungen komplett ignoriert.

Vom Was zum Wie

Die Entwickler in Scrum sind dafür verantwortlich, dass die Product Backlog Items (das "was") in konkrete Funktionalität umgesetzt wird (das "wie").

Daily Scrum durchführen

Das Daily Scrum ist das Event, in dem die Entwickler sich organisieren, den Tag planen und sich oft an typischen 3 Fragen orientiert. Diese Fragen können sein:

  • Was habe ich gestern für das Sprint Ziel getan?
  • Was werde ich heute für das Sprint Ziel tun?
  • Wo sehe ich das Sprint Ziel gefährdet?

Im Scrum Guide findet sich der Hinweis, dass es nicht zwingend diese Fragen sein müssen. 

Visualisierung der Arbeit

Mit einer Fortschrittsmessung überprüft das Team selbst, wie es um den Fortschritt der Arbeit steht. Dabei werden häufig Burndown und ähnliches verwendet. Wichtig ist dabei, dass dieses nicht durch eine andere Rolle geschieht (Scrum Masters oder Product Owners), sondern durch die Entwickler selbst. Der, der die Arbeit erledigt, der sollte sie auch messen.

Vorstellen der Arbeit

Spätestens im Sprint Review wird die getane Arbeit vorgestellt. Auch hier gilt wieder, dass die Rolle, die diese Arbeit verrichtet, sie auch vorstellt. Dabei wollen wir auch hier möglichst nah an dem bleiben, was wirklich die Realität ist. Das hilft uns für die so wichtige Transparenz. Sprich das Team zeigt, was es tatsächlich getan hat und nicht etwa nur eine Präsentation. Dabei sollten auch die Stakeholder, Product Owner und Kunden direkt mit eingebunden werden. Sollte es hier (noch) nicht so sein, nutzen Sie das Event der Retrospektive, um sich zu verbessern.

Retrospektive

Ein wichtiger Aspekt ist die Teilnahme an der Retrospektive. Es hilft somit den Blick der Entwicklung mit in den Fokus der Retrospektive und damit der Verbesserung zu bekommen. Ein wichtiger Teil, wenn wir auf den gesamten Wertstrom der Entwicklung schauen.

Herausforderungen für Entwicklungsteams

Auch wenn der Scrum Guide nur wenige Seiten besitzt und sich auf das Nötigste fokussiert, so haben wir doch einige Herausforderungen bei dem Aufbau und der Implementierung von agilen Teams zu bestehen.

Befähigung des Teams

Wer selbstorganisierte Entwicklungsteam möchte, der muss diese wollen und ebenso auch befähigen. Selbstorganisation ist nur ein Wort, aber in der Umsetzung nicht trivial. Zum einen musst es das Team wollen, zum anderen auch die Erlaubnis dazu besitzen.

Zusammenstellung des Teams

Entwicklungsteams benötigen einen Rahmen, in dem sie sich entfalten können. Das beginnt meistens mit selbstorganisierten Teamfindungsworkshops. Dabei stellen sich die Teammitglieder gemeinsam ihr Teams und etablieren ihre Arbeitsweise.

Kultur und Struktur

Viele Organisationen haben keine oder kaum passende Strukturen, um das Scrum Entwicklungsteam zu etablieren. Starten meistens trotzdem mit Scrum und das führt meistens zu einer Veränderung des Verhaltens, aber nicht der grundlegenden Kultur. Diese reine Veränderung des Verhaltens ins nicht nachhaltig.

Das Verhalten von Menschen können wir nicht einfach ändern. Schaffen wir es aber die Struktur eines Unternehmens zu ändern, dann hast du auch die Möglichkeit, dass sich eine andere Kultur einstellt.

typische Probleme

  • Trennung von z.B. Planung und Ausführung durch tayloristische Strukturen.
  • Weiterhin Projekte statt Produkte
  • Projektleiter die eine Produkstruktur torpedieren

Arbeit von der Seite

Je nach Reife der Organisation kann es vorkommen, das Teams nicht nur Arbeit über das Backlog bekommen, sondern auch von anderer Stelle. Das ist häufig dann noch so, wenn die Organisation sich von der Kultur (also der Struktur) noch nicht so verändert hat, dass das gemeinsame Verständnis etabliert ist.

Sebastian Schneider

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Hole dir auch den kostenlosen Online Scrum Kurs

    >