Entwickler in Scrum. Eigenverantwortung & Teamplay.

Obwohl das Entwicklungsteam meiner Meinung nach die zentrale Rolle in Scrum darstellt, werden häufig vornehmlich die Rolle des Product Owners und des Scrum Masters thematisiert. Das Team gerät dabei fälschlicherweise in den Hintergrund. Oft erlebt man es in der Praxis, dass ein Scrum Entwicklungsteam innerhalb von Organisationen als klassisches Projektteam angesehen und dementsprechend behandelt wird. Ein Missstand der dazu führt, dass das Team weitaus weniger effizient und effektiv arbeiten kann, als es eigentlich möglich wäre. Ein Grund dafür ist die fehlende Verantwortung, die Entwicklungsteams übernehmen können oder wollen. 

In Podcast-Folge #26 „Das Entwicklungsteam“ spreche ich über den Verantwortungsbereich und die optimale Größe eines Entwicklungsteams und erkläre, wie es durch das Zusammenbringen unterschiedlicher Fähigkeiten und die Übernahme von Verantwortung qualitativ hochwertige Ergebnisse erzielt.

Hintergrund und  Definition: Worauf kommt es bei einem guten Entwicklungsteam an?

Um herauszuarbeiten worauf es ankommt, um mit und in einem Entwicklungsteam erfolgreich zu arbeiten, möchte ich auf vergangene Folgen meines Podcasts verweisen. Aufgrund des hohen Stellenwertes des Entwicklungsteams in Scrum habe ich dort bereits unterschiedliche Aspekte zur Rolle und Verantwortung angerissen:  

In der Folge “Sprint Planning” habe ich das Entwicklungsteam und dessen Verhältnis zum Product Owner im Kontext des Sprint Plannings  thematisiert. Das Verhältnis zwischen PO und Team habe ich dabei als eine Art impliziten “Deal” beschrieben, bei dem beide Parteien ein Ziel festlegen, das im Sprint erreicht werden soll. Für das Team bedeutet das konkret, eigenverantwortlich zu arbeiten und den PO in die Arbeit mit einzubinden. Der PO wiederum lässt dem Team genügend Freiraum bei der Festlegung des Arbeitsumfangs, der Herangehensweise und auch bei der Arbeit selbst.

Darüber hinaus habe ich wichtige Eigenschaften zum Entwicklungsteam in den Folgen “Daily Scrum” und “Task Board” beleuchtet und beschrieben, welche Rolle das Entwicklungsteam bei der Ausgestaltung des Daily Scrums spielt und wie der Einsatz eines Task Boards sowie ein effektives Daily Scrum dem Team helfen, seiner Verantwortung gerecht zu werden. 

In der Folge zur “Überwachung des Sprint-Fortschritts” habe ich insbesondere das Team und den Einsatz von Burn Down Charts als Hilfsmittel, einer eigenverantwortlichen Arbeitsweise gerecht zu werden, beleuchtet. Dabei war es mir wichtig hervorzuheben, dass ein gutes Entwicklungsteam eng zusammenarbeitet und die Arbeit dabei stets unter Kontrolle hat. Daneben ist es in der Lage, aus den Lieferungen einzelner Inkremente schon früh im Sprint sein Risiko aktiv zu managen. In der Folge “Definition of Done” habe ich die Wichtigkeit einer gemeinsamen Definition von “Fertig” verdeutlicht. Ich habe erläutert, dass die Notwendigkeit, ein gemeinsames Verständnis von “Done” zu schaffen, vor allem aus der Tatsache resultiert, dass innerhalb eines Entwicklungsteam unterschiedliche Fähigkeiten aufeinander treffen. Es ist gerade deswegen sinnvoll, diese  durch eine Definition of Done auf einen gemeinsamen Nenner zu bringen. 

Zusammenfassend kann man also behaupten, dass dem Entwicklungsteam in Scrum ein hohes Maß an Verantwortung zukommt, dem es innerhalb der unterschiedlichen Scrum Events sowie durch geeignete Hilfsmittel (wie beispielsweise dem Task Board oder den Burn Down Charts) gerecht werden kann. 

Definition des Entwicklungsteams gemäß Scrum Guide

Neben diesen bereits beleuchteten Funktionen und Aufgaben des Entwicklungsteams möchte ich an dieser Stelle zusätzlich noch die offizielle Definition des Scrum Guides  (Der Scrum GuideTM – Der gültige Leitfaden für Scrum: Die Spielregeln (2017) von Ken Schwaber and Jeff Sutherland) hinzuziehen, um das Bild abzurunden und ein klares Verständnis über das Entwicklungsteam herzustellen:

Gemäß Scrum Guide besteht das Entwicklungsteam aus Profis, die am Ende eines Sprints ein fertiges, potentiell auslieferbares Produkt-Inkrement übergeben. Darüber hinaus muss ein fertiges Inkrement im Sprint Review vorhanden sein. In ihrer Arbeit organisieren und managen sich Entwicklungsteams selbst. Darüber hinaus hat die Organisation das Entwicklungsteam dementsprechend befähigt und strukturiert, dieser Verantwortung gerecht werden zu können, um durch die daraus resultierende Synergie die Gesamteffizienz und die Effektivität des Teams zu optimieren. 

Darüber hinaus weisen Entwicklungsteams gemäß Scrum Guide die folgenden Eigenschaften auf:

• Entwicklungsteams sind selbstorganisierend.
  Das Team organisiert sich selbst. Weder der Scrum Master noch der Product Owner oder andere Interessensgruppen schreiben dem Entwicklungsteam vor, wie es aus dem Product Backlog eine potentiell auslieferbare Funktionalität hervorbringen soll.
• Entwicklungsteams sind interdisziplinär tätig. Das komplette Team besitzt alle notwendigen Fähigkeiten, um ein Produkt-Inkrement zu erstellen. 
• Scrum kennt keine weiteren Titel im Entwicklungsteam
  Unabhängig von der Arbeit, die Mitglieder des Entwicklungsteams erledigen, tragen alle lediglich den Titel “Entwickler”.  
• Scrum kennt keine weiteren Unterteilungen
  Unabhängig von bestimmten zu adressierenden Domänen gibt keine weiteren Unterteilungen innerhalb des Entwicklungsteams 
• Die Rechenschaftspflicht obliegt dem gesamten Team
  Auch wenn Mitglieder des Entwicklungsteams spezialisierte Fähigkeiten oder Spezialgebiete haben, obliegt die Rechenschaftspflicht dem Team in seiner Gesamtheit.

Mehr Informationen sowie den exakten Wortlaut und weitere Übersetzungen des Scrum Guides findest Du hier: https://scrumguides.org/download.html

Ein Team mit allen notwendigen Fähigkeiten?

Das Entwicklungsteam stellt eine Einheit dar, die alle notwendigen Fähigkeiten vereint. Was in der Theorie logisch erscheint, wird jedoch in der Praxis häufig nicht umgesetzt. In den meisten Umgebungen besitzen Teams zwar alle notwendigen technischen Fähigkeiten, allerdings fehlt Experten-oder Fachwissen aus denjenigen Abteilungen, für die das Produkt entwickelt werden soll. Dies hat zur Folge, dass die Fachabteilungen (oder stellvertretend der Product Owner) Lösungen spezifizieren, damit diese im Team lediglich umgesetzt werden müssen. Wie in den vorhergehenden Ausführungen beschrieben geht mit der Arbeit des Entwicklungsteams ein hohes Maß an Verantwortung einher. Ein Vorarbeiten und Spezifizieren ist daher nicht sinnvoll und entgegen der eigentlichen Intention von Scrum. Eine solche Arbeitsweise unterscheidet sich nicht von den Arbeitsweisen, die wir durch Scrum ablösen wollen um signifikant bessere Ergebnisse zu erzielen. Darüber hinaus zeigen sich dadurch in relativ kurzer Zeit unterschiedliche negative Effekte:

• Eine vorgeschaltete Spezifizierung und die damit einhergehende isolierte Betrachtung des Produktes führt zu einer Art “Stillen Post” und bewirkt, dass Informationen lediglich von A nach B getragen werden, aber kein richtiger Austausch im Team stattfinden kann. Dies kann die Produktqualität negativ beeinflussen.
• Darüber hinaus stört diese fragmentierte Herangehensweise die Zusammenarbeit mit dem Kunden, da sowohl der Austausch mit ihm als auch die Möglichkeit, auf neue Erkenntnisse einzugehen, erschwert wird. 
• Neben den negativen Auswirkungen auf die Produktqualität und das Kundenverhältnis wirkt sich diese isolierte Herangehensweise negativ auf die Teamdynamik aus. Wenn der Product Owner oder die Fachabteilungen das Produkt spezifizieren und dementsprechend vorarbeiten, bleibt für Entwicklungsteams lediglich die Umsetzung. Da dem Team damit jegliche Freiheit zur Einbringung eigener Ideen verwehrt wird, kann sich dies negativ auf die Teamdynamik und die Motivation auswirken. 

Aus meiner Erfahrung kann ich sagen, dass die besten Teams diejenigen sind, die Personen mit ausgerpägtem fachlich Verständnis nicht vorgeschaltet, sondern mit in das Entwicklungsteam integriert haben. Dies gibt dem Team nämlich die Möglichkeit die Lösungen gemeinsam im Sprint auszugestalten. Die daraus resultierende Teamdynamik, die Kreativität und die Synergien sind jedes Mal aufs Neue beeindruckend. Ich kann jedem nur empfehlen, zu prüfen, ob diese Voraussetzungen im eigenen Team gegeben sind.  

Mein Tipp

Um eure Umgebung zu überprüfen, könnt ihr folgendermaßen vorgehen: Nehmt eine grobe (frühe) Anforderung aus Nutzersicht (User Story) und stellt euch die Frage, welches Wissen und welche Fähigkeiten gebraucht werden, um dieser Anforderung gerecht zu werden. Im nächsten Schritt gleicht ihr das Ergebnis mit der Realität ab und prüft, ob diese Fähigkeiten innerhalb eures teams zu finden sind oder außerhalb (vor-oder nachgelagert). Findet ihr die notwendigen Fähigkeiten außerhalb eures Entwicklungsteams, so stellt das Optimierungspotenzial dar um euer Team auf ein höheren Level zu heben.

Qualität und Risikomanagement: Der Anspruch an das Entwicklungsteam

In Scrum besteht implizit der Anspruch an das Entwicklungsteam, Verantwortung für die Qualität des Produktes und das Management der Risiken zu übernehmen. In der Praxis zeigt sich, dass die meisten Teams dafür jedoch unzureichend aufgestellt sind. Es gibt meiner Meinung nach zwei Hauptgründe, weshalb Teams ihrer Verantwortung hinsichtlich Produktqualität und Risikomanagement nicht gerecht werden können. 

• Teams kennen die gewünschte Qualität nicht
  Das Entwicklungsteam muss den gewünschten Level an Qualität kennen, da dieser erhebliche Auswirkungen auf die Entwicklung des Produktes hat. Beispielsweise ist es für das Team wichtig zu wissen, ob es an einer Luxus-Uhr arbeitet oder an einer funktionalen Uhr im mittleren Preissegment. Der Grund, warum Teams die gewünschte Qualität nicht kennen liegt darin, dass innerhalb der Scrum Events mehr über Features und Termine gesprochen wird als über die notwendige Produktqualität. 
• Teams können den Umfang an Items für den Sprint nicht eigenständig festlegen
  Häufig ist das Problem nicht, dass die gewünschte Qualität dem Team nicht nicht bekannt ist, sondern vielmehr, dass es aufgrund von Lieferdruck den Umfang des Sprints nicht selbst festlegen kann. Die dadurch entstehenden “erzwungenen” Ergebnisse entsprechen am Ende nicht der gewünschte Qualität. Langfristig gesehen verliert man dadurch an allen Fronten: Durch die Fremdbestimmheit enstehen zum einen desillusionierte Teams, die gar keine Chance haben, ernsthaft Verantwortung für Qualität zu übernehmen. Zum anderen wird der Kunde auf lange Sicht ebenfalls nicht mit den Ergebnissen  zufrieden sein, da die Qualität nicht den Erwartungen entspricht und die Risiken nicht zuverlässig genug aufgedeckt werden können.

Mein Tipp

Um hier Abhilfe zu schaffen und den Teams die Verantwortung zu gewähren, die sie verdienen, empfehle ich folgende Vorgehensweisen: 

1. Das Team frühzeitig in den Ausblick vom Product Backlog einbindenUm Risiken möglichst früh zu erkennen und zu vermeiden, dass alternativlose Zwänge entstehen, benötigt das Team einen Ausblick über das Product Backlog. Dadurch kann der Product Owner gemeinsam mit dem Team festlegen, wie Items gesplittet oder Priorisiert werden können. Die Perspektive des Entwicklungsteams ist dafür essentiell, denn nur sie verfügen über die notwendige Kompetenz und damit auch das Einschätzungsvermögen. Darüber hinaus kann das Einbeziehen des Entwicklungsteams ein Anreiz setzen, mit dem Kunden in Kontakt zu treten. Durch die Expertise des Teams können fundierte Empfehlungen ausgesprochen, oder im Falle von Problemen, nützliche Alternativen gefunden werden.
2. Das Sprint Review ausbauen
   Ein weiterer, möglicher Ansatzpunkt, dem Team die notwendige Verantwortung zu übergeben, ist das Sprint Review. Es gilt, sich in diesem Rahmen das Produktverständnis vom Team zurückspiegeln zu lassen um es in das Große und Ganze einzuordnen. Das Team soll Aufschluss darüber geben, welche Learnings aus dem letzten Inkrement mitgenommen und welche Schlüsse für die Zukunft daraus gezogen werden können. Darüber hinaus kann das Entwicklungsteam seiner Verantwortung hinsichtlich der Produktqualität besser nachkommen, wenn die Auseinandersetzung damit  im Sprint Review forciert wird. Anstatt lediglich fertige Inkremente zu präsentieren, sollte darüber hinaus ein aktiver und regelmäßiger Austausch über die Qualität (z.B. Wartbarkeit, Performance) stattfinden.
3. Im Sprint Planning auf die unabhängige Auswahl des Sprintumfangs achten
   Der Scrum Master sollte im Sprint Planning sicherstellen, dass das Entwicklungsteam in der Lage ist, Verantwortung zu übernehmen. Er muss dafür sicherstellen, dass das Team unabhängig agieren kann bei der Auswahl des Sprint-Umfangs.

Die Optimale Team-Größe

Für die erfolgreiche Arbeit mit Scrum ist die Größe des Entwicklungsteams entscheidend. Das Team sollte weder zu groß noch zu klein sein. Laut Scrum Guide liegt die optimale Teamgröße zwischen drei und neun Personen. 

• Drei Personen als Minimum:
  Warum ein Team aus mindestens drei Personen bestehen sollte, lässt sich leicht verdeutlichen: Mit nur einer Person geraten wir schnell ins Stocken. Wir haben keine Person, die uns hilft, den Stein wieder ins Rollen zu bringen. In einer größeren Gruppe kann man sich in solchen Situationen durch das Einbringen unterschiedlicher Perspektiven aushelfen. Genau aus diesem Grund greift man in der Entwicklung auch gern auf Pair Programming zurück. Wenn das Entwicklungsteam in Scrum wirklich als Team agiert, sollte es ein Leichtes sein, durch einen Gedankenaustausch den Stein wieder ins Rollen zu bringen.
• Neun Personen als Maximum:
  Bei besonders großen Gruppen sehen sich sich mit der Problematik konfrontiert, dass sehr leicht der Überblick verloren geht und einzelnen Personen und deren Sichtweise sehr schlecht wahrgenommen werden. Dies kann zur Folge haben, dass sich Teammitglieder hinter der Größe der Gruppe verstecken. Darüber hinaus resultiert aus einer zu großen Gruppe häufig, dass einzelne Verantwortungsbereiche festgelegt werden, um die Übersicht zu wahren. Es bilden sich Gruppierungen heraus, die sich häufig entsprechend ihrer Bereich zusammenfinden. Eine solche Abgrenzung führt zu einer isolierten Betrachtung einzelner Aufgabenbereiche und steht der ursprünglichen Intention von Scrum völlig entgegen.

Ich empfehle daher, in solchen Situation ein Splitting der einzelnen Teams vorzunehmen, um den Teamgedanken und die Dynamik dahinter zu wahren.

Zusammenfassung

Das Entwicklungsteam und dessen eigenverantwortliche Arbeitsweise wurde in vielen Folgen von “Scrum meistern” anhand von unterschiedlichen Kontexten beleuchtet. Um das Bild abzurunden, wurden zusätzlich in dieser Folge die Scrum Guide Definition sowie die optimale Teamgröße thematisiert. Darüber hinaus wurde verdeutlicht, wie wichtig es ist, alle unterschiedliche Fähigkeiten im Entwicklungsteam zu vereinen anstelle diese vorgelagert oder nachgelagert zu platzieren. Es liegt ebenfalls in der Verantwortung des Entwicklungsteams, die Produktqualität zu wahren und ein adäquates Risikomanagement zu betreiben. Hierfür muss das Team unabhängig aufgestellt sein. 

Ich hoffe, ich konnte mit meinen Tipps neue Impulse liefern, wie ein Entwicklungsteam optimaler aufgestellt werden kann. Hast du Fragen oder Anmerkungen? Ich freue mich über Feedback.