Du möchtest Scrum in deinem Team wiederbeleben, wo es etwas aus dem Blick geraten ist?
In dieser Situation befindet sich einer meiner Kunden und hat mich um Hilfe gebeten. Ich war vor Ort und wir haben eine Schulung in Scrum für Entwickler, Produktmanager und Manager durchgeführt. In mehreren Sprints haben Teilnehmer ein Produkt entwickelt. Gleichzeit haben wir so schrittweise die Theorie, Regeln und Empfehlungen hinter Scrum erarbeitet. Ziel des Trainings ist es, dass die Teilnehmenden direkt am Tag nach dem Training ihre Arbeit in Scrum Teams aufnehmen können.
Damit das klappt, ist die Beantwortung dieser Frage entscheidend:
Welche Aufgaben haben Entwickler in Scrum Teams?
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 dieser Missverständnisse vielleicht auch in deinem Unternehmen kursieren.
(Wenn du in deinem Unternehmen auch Scrum einführen oder wiederbeleben möchtest, dann könnte das „Applying Professional Scrum“-Training auch für dich das Richtige sein. Wenn du mehr erfahren willst, dann schreibe mir gerne eine Nachricht, aktuell nehme ich Anfragen für Q3 an.)
Nun zu den Irrtümern:
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.“
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.“
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.“
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.“
Und deshalb empfiehlt der Guide:
„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.“
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.“
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.“
Suchst du nach einem einfachen Weg, dieses Verständnis in deinem Scrum Team zu etablieren, dann wirf einen Blick auf diesen Artikel: „Wie Scrum Teams beginnen, die Definition of Done erfolgreich zu verwenden – Eine Anleitung in 3 Schritten für Scrum Master.“
Dass der Product Owner allein die Qualität des Produkts verantwortet, ist also ein Mythos.
Zum Abschluss
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.
Die Vermeidung dieser Irrtümer hilft dir, Scrum so einzuführen, dass Selbstmanagement von Beginn an gefördert wird.