5 Irrtümer über die Rolle des Entwicklers in Scrum

Welche Aufgaben haben Entwickler in Scrum-Teams? Es ist entscheidend, diese Frage beantworten zu können, wenn man Scrum einführen möchte – aber genauso, wenn die Anwendung von Scrum im Laufe der Zeit aus dem Blick geraten ist und man die Nutzung des Frameworks wiederbeleben möchte.

In dieser Situation befand sich einer meiner Kunden. Ich war vor Ort und wir haben eine Scrum-Schulung für Entwickler, Produktmanager und Manager durchgeführt. Dabei haben die Teilnehmenden in mehreren Sprints ein Produkt entwickelt. Quasi nebenher haben wir schrittweise die Theorie, Regeln und Empfehlungen hinter Scrum erarbeitet.
Ziel dieses Trainings ist es, dass die Teilnehmenden direkt am nächsten Tag ihre Arbeit in Scrum-Teams aufnehmen und verbessern können. 

Damit das klappt, war also auch hier die Beantwortung der Frage entscheidend: Was ist die Rolle des Entwicklers in Scrum?

Ich war erstaunt, wie viele Irrtümer, Missverständnisse und Mythen über die Verantwortung der Entwickler in Scrum-Teams herrschen, die eine klare Rollenbeschreibung verhindern. Da dies kein Einzelfall ist, stehen die Chancen gut, dass einige der folgenden Missverständnisse vielleicht auch in deinem Unternehmen kursieren. Hier also ein paar Hinweise, die dir dabei helfen, diese Irrtümer aufzuklären und ein solides Grundverständnis für die Entwickler-Rolle in Scrum aufzubauen.

(Wenn du in deinem Unternehmen auch Scrum einführen oder wiederbeleben möchtest, dann könnte das „Applying Professional Scrum“-Training das Richtige für dich sein. Wenn du mehr erfahren willst, dann schreibe mir gerne eine Nachricht, aktuell nehme ich Anfragen für Q3 an.)

Irrtum 1: Die Entwickler in Scrum sind Softwareentwickler.

Dieser erste Irrtum kann das Verständnis der Rolle nicht nur behindern, sondern auch die Zusammensetzung des Teams beeinflussen. Deshalb lass uns ohne Umschweife klarstellen: Wenn wir in Scrum von Entwicklern sprechen, meinen wir nicht ausschließlich Softwareentwickler.

Sondern:

„Developer sind jene Personen im Scrum-Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.“

Scrum Guide 2020

Laut dem Scrum Guide umfasst dies alle produktbezogenen Aktivitäten:

• Zusammenarbeit mit den Stakeholdern,
• Verifikation des Produkts und der Anforderungen,
• Wartung und Betrieb des Produkts,
• Experimente und Forschung für die Weiterentwicklung des Produkts
• und alles, was sonst noch erforderlich sein könnte.

Somit ist ein Scrum-Team kein Team ausschließlich aus Softwareentwicklern. Unternehmen benötigen neben Scrum-Teams auch keine weiteren Teams zur Anforderungserhebung oder zum Testen der Software. Diese übermäßig spezialisierten Teams erhöhen das Risiko, kein funktionierendes Inkrement bis zum Ende des Sprints zu erhalten. Mehr dazu kannst du in meinem Artikel „Risikomanagement in Scrum – Warum jedes Unternehmen einen Scrum Master braucht“ nachlesen.

Dir ist bestimmt nicht entgangen, dass die Übersetzer des Scrum Guides das englische Wort „developer“ für Entwickler nutzen. Dies dient auch dazu, dieses Missverständnis zu verhindern. Die Erkenntnis, dass es sich bei einem Entwickler nicht zwangsläufig um einen Softwareentwickler handeln muss, führt uns direkt zum nächsten Irrtum.

Irrtum 2: Ein Entwickler muss interdisziplinär sein.

Müssen Entwickler, wenn sie nicht nur Software entwickeln, alles beherrschen?

Das Märchen, dass jeder Softwareentwickler ein „Fullstack“-Entwickler oder sogar ein Generalist sein muss, hält sich hartnäckig. Mir scheint fast, dass viele Menschen beim Wort „Entwickler“ nur zwei Extreme kennen: Entweder bedeutet Entwickler ausschließlich Softwareentwickler oder aber Generalist. Beides ist ein Irrtum und das Letztere zudem unrealistisch. Die Entwicklung komplexer Produkte zeichnet sich gerade dadurch aus, dass es ein Team von Experten benötigt, um das Ziel des Produkts zu erreichen.

Betrachten wir noch einmal das Zitat:

„Developer sind jene Personen im Scrum-Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.“

Scrum Guide 2020

Beim Lesen dieses Abschnitts des Scrum Guides solltest du zwei Worte nicht übersehen: „jeden Aspekt“.

Das bedeutet, dass nicht jeder Entwickler jeden Aspekt der Produktentwicklung beherrschen muss, sondern dass das Team als Ganzes jeden Aspekt beherrschen muss.

Irrtum 3: Der Scrum Master entscheidet, wie viel Arbeit im Sprint bearbeitet werden soll.

Der Scrum Master „füttert“ die Entwickler im Sprint Planning mit User Stories.

Ich weiß nicht, woher diese Praxis kommt, aber ich treffe sie immer häufiger an. Was meine ich mit „füttern“? Das Sprint-Backlog ist bereits vor dem Sprint-Planning vom Scrum Master mit Einträgen aus dem Product-Backlog bestückt worden.

Dieses Missverständnis verhindert, dass Entwickler Verantwortung für ihre Arbeit übernehmen können und selbst entscheiden, wie viele Einträge im Sprint realistisch umsetzbar sind. Anstatt dass Entwickler mit Arbeit „gefüttert“ werden, sollte die Planung nach dem Scrum Guide in einem Gespräch – dem Sprint-Planning – stattfinden.

„Im Gespräch mit dem Product Owner wählen die Developer Einträge aus dem Product-Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen.“

Scrum Guide 2020

Ein solches Gespräch und die Auswahl können schwierig sein. Das verschweigt der Scrum Guide nicht:

„Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen.“

Scrum Guide 2020

Und deshalb lautet die Empfehlung:

„Je mehr die Developer jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint-Vorhersagen sein.“

Scrum Guide 2020

In diesem Satz sehe ich die Arbeit eines Scrum Masters. Nicht darin, die Entwickler zu „füttern“, sondern ihnen zu helfen, ihre bisherige Leistung, zukünftige Kapazität und Definition of Done transparenter zu machen. Damit wird die Sprint-Vorhersage realistischer und das Gespräch zwischen Product Owner und Entwicklern wird wirksamer und effizienter.

Irrtum 4: Die Anzahl der User-Stories im Sprint ist nicht mehr verhandelbar.

Das Gegenteil ist der Fall.

Wie viele Einträge sich die Entwickler für einen Sprint zumuten, ist eine Vorhersage und keine Garantie.

Sprechen wir von Vorhersagen, dann meinen wir so etwas wie Wettervorhersagen. Wie sich das Wetter im Urlaub entgegen der Vorhersage auch ändern kann, so kann sich auch die Einschätzung ändern, was fertiggestellt werden kann.

Den Product Owner über diese Veränderung zu informieren, ist die Aufgabe der Entwickler.

„Während des Sprints kann der Scope (Inhalt und Umfang) geklärt und mit dem Product Owner neu vereinbart werden, sobald mehr Erkenntnisse vorliegen.“

Scrum Guide 2020

Damit mögliche Abweichungen von der Vorhersage auffallen, treffen sich die Entwickler einmal am Tag für einen kurzen Moment und diskutieren den Fortschritt bei der Erreichung des Ziels für diesen Sprint. Bleiben wir bei dem Beispiel des Wetters in der Urlaubsregion, so entspricht das Daily Scrum im Scrum dem morgendlichen Blick aus dem Fenster im Urlaub. Dort wird entschieden, ob die Wolken am Himmel mit der Vorhersage, der ganze Tag bleibe sonnig, übereinstimmen und ob nicht doch eine Jacke einzupacken ist.

Genug vom Wetter, zurück zum letzten Irrtum:

Irrtum 5: Der Product Owner ist für die Qualität verantwortlich.

Wer die Verantwortung für das Produkt trägt, ist also auch für die Qualität verantwortlich?

Diese Frage lässt sich mit dem Scrum Guide beantworten. Die Qualität des Produkts ist in der Definition of Done festgehalten. Die Definition of Done wird vom Unternehmen vorgegeben. „Wenn sie kein Organisationsstandard ist, muss das Scrum-Team eine für das Produkt geeignete Definition of Done erstellen.“ Das Wort „Scrum-Team“ ist hier entscheidend. Weder der Product Owner noch die Entwickler oder der Scrum Master allein definieren die Qualitätsstandards für das Produkt, sondern sie tun dies gemeinsam.

Somit tragen auch die Entwickler Mitverantwortung für die Qualität. Der Scrum Guide formuliert es noch deutlicher:

„Die Developer müssen sich an die Definition of Done halten.“

Scrum Guide 2020

Dass der Product Owner allein die Qualität des Produkts verantwortet, ist also ein Mythos.

Suchst du nach einem einfachen Weg, dieses Verständnis in deinem Scrum-Team zu etablieren, dann wirf einen Blick auf diesen spannenden Artikel zur Definition of Done von meinem Kollegen Pascal Gugenberger.

Zum Abschluss: Was die Rolle des Entwicklers in Scrum ausmacht

Wenn du das nächste Mal einen Workshop zur Rollenklärung durchführst oder Scrum in einem Team oder Unternehmen einführen möchtest, dann achte darauf:

• Entwickler bedeutet nicht ausschließlich Softwareentwickler.
• Entwickler müssen keine Generalisten sein, aber das Team sollte interdisziplinär sein.
• Entwickler können den Umfang des Sprints mit dem Product Owner neu vereinbaren.
• Entwickler müssen sich an die Definition of Done halten.

Diese Punkte werden dir dabei helfen, Scrum so einzuführen, dass Selbstmanagement von Beginn an gefördert wird.