Scrum-Team versus agiles Team

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Heute möchte ich darüber schreiben, welche Personen oder Rollen eigentlich zu einem Team gehören.

Laut Scrum-Guide besteht ein Scrum-Team aus

• Product Owner
• Scrum Master und
• Developers

Das agile Manifest nennt als ein Prinzip für agile Softwareentwicklung, dass Entwickler und Businessleute täglich zusammenarbeiten.

Diese beiden Punkte sind für mich nicht vereinbar. Ich halte die Team-Definition für einen Fehler im Entwurf von Scrum. Wieso?

In jeder Zusammenarbeit entstehen mal Reibung oder Konflikte. Zur Weiterentwicklung der zusammenarbeitenden Menschen gehört auch, dass sie lernen, mit Reibung und Konflikten umzugehen.

In Scrum ist die Retrospektive das herausragende Event, in dem ein Team seine Zusammenarbeit verbessert. Wenn die Entwickler, getreu dem agilen Manifest, täglich mit den Businessleuten zusammenarbeiten, stellt sich die Frage, in welchem Rahmen die Zusammenarbeit zwischen diesen beiden Gruppen verbessert werden soll. Nicht in der Retrospektive, denn sie ist dem Scrum-Team vorbehalten.

Lässt man die Definition des Scrum-Teams außer Acht und versteht als Team alle Personen, die gemeinsam am Produkt arbeiten, folgt daraus, dass auch Businessmenschen an der Retrospektive teilnehmen.

Vielleicht wird die Gruppe bei diesem Teamverständnis zu groß. Dann spricht aus meiner Sicht nichts dagegen, eine Retro mit dem Scrum-Team zu machen und eine teamübergreifende Retro mit einem größeren Teilnehmerkreis. Interessanterweise gäbe es mit diesem Verständnis kein Single-Team-Scrum.

Was bedeutet das für Entwickler?

Die bedeutendste Konsequenz für manche Entwickler lautet: Sie können sich nicht hinter ihrem Product Owner verstecken. Das Verstecken habe ich insbesondere dann beobachtet, wenn Entwickler den Product Owner als Schnittstelle “nach außen” verstehen. Mit dem hier dargestellten Verständnis gehören die “Außenstehenden” zum Team, in dem die Entwickler arbeiten, dazu; dann gibt es aber auch keine Schnittstellenfunktion, die der Product Owner einnehmen könnte.

Die Konsequenzen sind außerordentlich weitreichend, und ich bin der Überzeugung, dass eine Konsequenz lautet: Die Agilität wird verbessert.

Wer nun einwendet, dass der Scrum Guide sehr deutlich sagt, dass der Scrum Master das Silodenken bekämpfen soll, hat recht. Wörtlich steht dort “Removing barriers between stakeholders and Scrum Teams” Dort steht aber auch, dass die Retrospektive eine Veranstaltung des Scrum-Teams ist. Außenstehende sind nicht dabei. Das nenne ich eine Barriere.

Des Weiteren richtet sich dieser Blog nicht an Scrum Master, sondern an Softwareentwickler. Ohne ihren Beitrag kann Agilität nicht funktionieren, sondern führt zu einer Feature Factory, in der Entwickler nur Tickets abarbeiten, die von außen in ihr Silo geworfen werden.

Und deshalb schlage ich vor, dass Softwareentwickler, die der Feature Factory entkommen wollen, die Businessleute und andere Stakeholder als Teil ihres Teams verstehen und so behandeln.

Tschüss. Stefan

(rme)