Fehlverhalten von Scrum Entwicklern 🇩🇪

In Kürze: Scrum Entwickler Fehlverhalten

Nachdem wir bereits Fehlverhalten von Scrum Mastern, Interessenvertretern und Product Ownern beschrieben haben, befasst sich dieser Artikel mit Fehlverhalten der Scrum Entwickler, wobei wir alle Scrum Events sowie das Produktbacklog berücksichtigen. Erfahren Sie mehr darüber, worauf Sie achten sollten, wenn Sie Ihre Teamkollegen, die das Produktinkrement erstellen, auf dem Pfad der kontinuierlichen Weiterentwicklung unterstützen wollen.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Die Rolle der Entwickler in Scrum

Laut dem Scrum Guide üben die Entwickler folgende Funktion aus: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint:”

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;
• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

Außerdem genießen die Entwickler völlige Autonomie, was die technische Seite ihrer Arbeit angeht:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

Quelle: Scrum Guide 2020.

(Sehen Sie sich die vollständige Liste des Scrum Guide 2020 über die Entwickler, indem Sie den Scrum Guide Reordered herunterladen..)

Der Begriff „Entwickler“ scheint die Rolle auf technische Personen zu beschränken, z. B. auf Software-Ingenieure. Im Sinne des Scrum Guides ist der Begriff „Developer“ jedoch viel umfassender. Meiner Erfahrung nach können sich sogar Juristen und Marketingfachleute mit dieser Bezeichnung anfreunden, wenn sie vom Scrum Master und dem Product Owner entsprechend unterstützt werden.

Lassen Sie uns also in eine Reihe gängiger Fehlverhalten von Scrum-Entwicklern eintauchen, die Scrum Mastern signalisieren, dass ihre Teammitglieder Unterstützung brauchen.

Fehlverhalten von Scrum Entwicklern nach Scrum-Ereignissen

Die folgenden Auflistungen von Fehlverhalten der Scrum Entwickler beziehen sich auf Scrum-Events sowie das Produktbacklog:

Anti-Muster während des Sprints

Die meisten der folgenden Entwicklungsteam Fehlverhalten resultieren aus einem Mangel an Fokussierung oder Zögern:

• Kein Work-in-Progress-Limit: Es gibt kein Limit für Work-in-Progress. (Der Zweck des Sprints ist es, ein oder mehrere potenziell lieferbare Produkt-Inkremente zu erstellen, welche den Kunden und damit dem Unternehmen einen Mehrwert bietet. Dieses Ziel erfordert fokussierte Arbeit, um zu gewährleisten, dass die für das Erreichen des Sprint-Ziels als notwendig erachtete Arbeit geleistet wird. Die Flow-Theorie legt nahe, dass sich die Produktivität eines Teams mit einem Work-in-Progress (WiP)-Limit verbessert. Das WiP-Limit definiert die maximale Anzahl von Aufgaben, an denen ein Team gleichzeitig arbeiten kann. Das Überschreiten dieser WiP-Grenze führt zur Bildung zusätzlicher Warteschlangen, die folglich den Gesamtdurchsatz des Teams reduzieren. Die Zyklusdauer, d. h. der Zeitraum zwischen dem Start und dem Ende der Arbeit an einer Aufgabe, verlängert sich in Folge und die Produktivität sinkt.)
• Rosinenpicken: Die Entwickler suchen sich nur die Rosinen unter den Arbeitsaufgaben heraus. (Dieser Effekt überlagert sich oft mit dem fehlenden WiP-Limit-Problem. Menschen werden durch kurzfristige Befriedigung motiviert. Es fühlt sich einfach gut an, ein weiteres Puzzle vom Sprint-Board zu lösen. Im Vergleich zu diesem Dopamin-Fix ist es weniger befriedigend im Code Review zu prüfen, wie ein anderes Teammitglied ein anderes Problem gelöst hat. Daher bemerkt man relativ oft, dass sich z. B. Tickets in der Code-Review-Spalte unbearbeitet ansammeln. Dies ist auch ein Zeichen dafür, dass sich die Entwickler noch nicht vollständig selbst organisiert. Achten Sie auch auf die Daily Scrums, ob sich dort dieses Problem manifestiert, und sprechen Sie das Thema während der Sprint-Retrospektive an).
• Sprint-Board nicht auf dem letzten Stand: Die Entwickler aktualisiert die Tickets auf dem Sprint-Board nicht rechtzeitig, um den aktuellen Stand der Arbeiten widerzuspiegeln. (Das Sprint-Board, unabhängig davon, ob es sich um ein physisches oder digitales Board handelt, ist nicht nur für die Koordinierung der Arbeit der Entwickler von entscheidender Bedeutung. Es ist auch ein integraler Bestandteil der Kommunikation des Scrum-Teams mit seinen Stakeholdern. Ein Board, das nicht auf dem neuesten Stand ist, beeinträchtigt das Vertrauen der Stakeholder in das Scrum-Team. Eine Verschlechterung des Vertrauens kann dann zu Gegenmaßnahmen aufseiten der Stakeholder führen. Das (Management-) Pendel könnte in der Folge zu traditionellen Methoden wie PRINCE2 zurückschwingen.
• Nebenjobs: Die Entwickler arbeitet an Themen, die auf dem Sprint-Board nicht sichtbar sind. (Während Vergeßlichkeit ggf. noch entschuldbar ist, ist das Umleiten von Entwicklungskapazitäten unter Umgehung des Produkt Owners, der für die Rentabilität der Investition in die Arbeit der Entwickler verantwortlich ist, nicht akzeptabel. Dieses Verhalten signalisiert auch einen erheblichen Konflikt innerhalb des „Teams“. Angesichts dieser Demonstration von Misstrauen — warum haben die Entwickler dieses scheinbar wichtige Thema nicht während der Sprintplanung oder davor angesprochen — sind die Entwickler wahrscheinlich ohnehin eher eine Gruppe als ein Team).
• Goldene Türklinken: Das Entwicklungsteam erhöht den Arbeitsumfang des Sprints, indem es unnötige Arbeit zu den Product-Backlog-Einträgen des Sprint-Backlogs hinzufügt. (Dieser Effekt wird oft als Scope-Stretching oder Vergoldung bezeichnet. Das Entwicklungsteam ignoriert die ursprüngliche Vereinbarung mit dem Product Owner über den Umfang der Arbeiten. Aus welchem Grund auch immer erweitert das Team die Aufgabe ohne vorherige Rücksprache mit dem Product Owner. Diese Ignoranz kann zu einer fragwürdigen Allokation der verfügbaren Kapazitäten führen. Es gibt jedoch eine einfache Lösung: Die Entwickler und der Product Owner müssen öfter miteinander sprechen, um ein gemeinsames Verständnis von der Produktvision bis hinunter zum einzelnen Product Backlog-Eintrag zu schaffen und so das Vertrauensniveau zu verbessern. Wenn der Product Owner bisher noch nicht mit dem Entwicklungsteam zusammen sitzt, dann wäre jetzt der richtige Zeitpunkt, um es sich noch einmal zu überlegen. Alternativ kann ein verteiltes Scrum-Team auch mehr Zeit in die synchrone und asynchrone Kommunikation investieren, um die Zusammenarbeit und Abstimmung untereinander zu verbessern.)
• Ignorieren der Definition of Done: Die Entwickler senken die Produktqualität unter das in der Definition of Done definierte Niveau, um einen Termin einzuhalten bzw. das Sprintziel zu erreichen. (Die Definition of Done spielt im Scrum-Rahmenwerk eine entscheidende Rolle: Sie stellt den Qualitätsstandard dar, der allen signalisiert, was die Entwickler erreichen müssen, um ein potenziell veröffentlichungsfähiges Inkrement zu erstellen. Mit „releasefähig“ meinen wir, dass wir das Inkrement ohne rechtliche, finanzielle oder ethische Konsequenzen in die Hände unserer Kunden und Benutzer geben können. Wenn wir dieses Qualitätsniveau verwässern, um eine — ggf. willkürliche gesetzte — Frist einzuhalten, die dem Team auferlegt wurde, dann setzen wir den Erfolg des Teams aufs Spiel, da dieses Verhalten zu unerledigter Arbeit und technischen Schulden führt. Beide Konsequenzen der Vernachlässigung des Qualitätsstandards beeinträchtigen die Fähigkeit des Scrum-Teams, in einer späteren Phase innovativ zu sein. Bitte beachten Sie, dass es keine geschäftliche Agilität ohne technische Exzellenz gibt. Letztere beginnt damit, dass die Definition of Done jederzeit eingehalten wird.)
• Ignorieren technischer Schulden: Die Entwickler verlangt keine ausreichende Kapazität, um technische Schulden und Fehler während des Sprints zu beseitigen. (Als Faustregel gilt, dass etwa 20 % der Kapazität in jedem Sprint gut eingesetzt ist, um Bugs zu eliminieren und die Codebasis zu überarbeiten. Wenn der Product Owner die Notwendigkeit dieser Arbeit ignoriert und die Entwickler diese Einstellung akzeptieren, wird sich das Scrum-Team über kurz oder lang in einer Abwärtsspirale wiederfinden und sich langsam aber stetig in eine auf den Output fokussierte Feature-Fabrik verwandeln. Seine zukünftige Fähigkeit, neue wertvolle Produkte zu liefern, wird abnehmen, denn technische Exzellenz ist die Voraussetzung für jegliche From von Business-Agilität. Erfahren Sie mehr über technische Schulden und Scrum.)
• Keine Pufferzeiten: Die Entwickler verlangen vom Product Owner keine 20 % Slack Time bzw. ungeplante Kapazität. (Dieses Problem überschneidet sich mit der Sprintplanung, der Erstellung von Sprint-Zielen und der Fähigkeit des Teams, Prognosen zu erstellen und kann nicht früh genug adressiert werden. Wenn die Kapazität eines Teams immer zu 100 % ausgelastet ist, wird seine Leistung sinken. Jeder wird sich auf die Erledigung seiner Aufgaben konzentrieren. Es bleibt weniger Zeit für die Unterstützung der Teamkollegen oder allgemein für die Zusammenarbeit untereinander. Kleinere Probleme werden nicht mehr zeitnah angegangen. Und letztendlich wird die Einstellung „ich bin beschäftigt“ dazu führen, dass nicht mehr alle Teammitglieder verstehen, warum sie das tun, was sie tun.)

Fehlverhalten der Scrum Entwickler bei der Sprintplanung

Die Sprint-Planung von Scrum zielt darauf ab, die Mitglieder des Teams darauf einzustellen, was als Nächstes gebaut werden soll, um den Kunden den größtmöglichen Nutzen zu bieten. Einige gängige Anti-Muster von Scrum Entwicklern in diesem Event sind:

• Kapazität? Die Entwickler überschätzen ihre Kapazität und übernehmen zu viele Aufgaben. (Die Entwickler sollte stattdessen alles in Betracht ziehen, was ihre Leistungsfähigkeit beeinträchtigen könnte. Die Liste dieser Gründe ist lang: Feiertage, neue Teammitglieder und solche, die sich im Urlaub befinden, ausscheidende Teammitglieder, kranke Teammitglieder, Firmen-Overhead, Scrum-Events und Praktiken wie die Verfeinerung des Product Backlogs und andere Meetings, um nur einige zu nennen).
• 100 % Auslastung: Das Entwicklungsteam verlangt vom Product Owner keine 20 % Slack Time. (Wenn die Auslastung eines Teams immer am Anschlag verharrt, wird seine Leistung mit der Zeit abnehmen. Dies wird besonders in einer Organisation mit einem volatilen Tagesgeschäft passieren. Als Folge davon wird sich jeder darauf konzentrieren, seine Aufgaben zu erledigen. Es wird weniger Zeit zur Verfügung stehen, um beispielsweise Teamkollegen zu unterstützen oder Pair Programming durchzuführen. Das Team wird kleinere oder dringende Probleme nicht mehr zeitnah angehen. Einzelne Teammitglieder werden zu Engpässen werden, die den Arbeitsfluss innerhalb des Teams ernsthaft behindern können. Und schließlich wird die „Ich bin beschäftigt“-Haltung die Entstehung eines gemeinsamen Verständnisses über das Warum, Was und Wie unter allen Teammitgliedern verringern. Eine Überlastung wird das einzelne Teammitglied in eine immer weniger kooperative Haltung drängen und den Grad an Selbstorganisation vermindern. Auf der anderen Seite wird Slack Time dem Scrum-Team erlauben, gemeinschaftlich zu handeln und sich auf das Ergebnis, das Inkrement und dessen Wert für die Kunden zu konzentrieren.
• Zu detaillierte Planung: Während des Sprint-Planung planen die Entwickler jede einzelne Aufgabe des bevorstehenden Sprints im Voraus. (Man plane nicht zu kleinteilig. Es reicht, wenn etwa ein Viertel der Aufgaben zu Beginn geplant wird, um nicht nur mit dem Sprint zu beginnen, sondern auch den Lernprozess einzuleiten. Das Sprint Backlog ist immer im Entstehen begriffen, und zu viel Planung im Vorfeld könnte zu Verschwendung führen, wenn diese im Laufe des Sprints wieder korrigiert werden muss).
• Zu viele Schätzungen: Die Entwickler schätzt selbst die Teilaufgaben. (Das sieht für mich nach Buchhaltung um der Buchhaltung willen aus. Verschwenden Sie also nicht Ihre Zeit damit. Denken Sie daran: Der Zweck der Schätzung besteht darin, eine abweichende Einschätzung der Entwickler in Bezug auf das Was und Wie der Einträge im Product oder Sprint Backlog zu ermitteln. Mehr erfahren: Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg.)
• Zu wenig Planung: Die Entwickler lassen die Sprint-Planung ganz ausfallen. (Das Überspringen der Planung ist bedauerlich, denn es ist auch eine hervorragende Gelegenheit, darüber zu sprechen, wie das Wissen unter den Entwicklern besser verteilt werden kann, wie die Architektur künftig aussehen soll oder ob die Tools angemessen sind. Das Team könnte zum Beispiel auch darüber nachdenken, wer mit wem für welche Aufgabe zusammenarbeiten wird. Der Planungsteil der Entwickler eignet sich auch hervorragend, um zu überlegen, wie technische Schulden reduziert werden können, siehe oben).
• Teamleiter? Die Entwickler erstellen keinen gemeinsamen Plan, um ihre Prognose zu erfüllen. Stattdessen übernimmt ein „Teamleiter“ die Planungsarbeit und weist ggf. sogar einzelnen Teammitgliedern Aufgaben zu. (Ich weiß, dass älteren Entwicklern die Idee nicht gefällt, aber es gibt keinen „Teamleiter“ in einem Scrum-Team. Erfahren Sie mehr zum Thema: Why Engineers Despise Agile.)

Fehlverhalten der Scrum Entwickler beim Daily Scrum

Das Daily Scrum ist das wichtigste „Inspect & Adapt-Ereignis“ für die Entwickler. Meiner Erfahrung nach kann man kaum erwarten, dass die Entwickler das Sprint-Ziel erreicht, wenn das Daily Scrum nicht funktioniert. Zu bekannten Anti-Mustern der Scrum Entwickler beim Daily Scrum gehören:

• Keine Routine: Das Daily Scrum findet nicht jeden Tag zur gleichen Zeit und am gleichen Ort statt. (Während Routine das Potenzial hat, jede Retrospektive zu ruinieren, ist sie im Kontext des Daily Scrum hilfreich. Betrachten Sie es als einen spontanen Drill: Nicht zu viel Aufwand im Voraus betreiben, nicht lange nachdenken, sondern einfach machen. Das Überspringen von Daily Scrums öffnet dem Verfehlen des Sprint-Ziels Tür und Tor: Wenn Sie ein oder zwei Daily Scrums überspringen, warum nicht gleich jedes zweite Mal?)
• Orientierung verloren: Das Daily Scrum dient einem Zweck, indem es eine einfache Frage beantwortet: Sind wir noch auf dem richtigen Weg, um das Sprint-Ziel zu erreichen? Oder müssen wir den Plan oder das Sprint Backlog oder beides anpassen? Viele Development Teams können diese Frage nicht auf Anhieb beantworten. (In dieser Hinsicht ist die Visualisierung des Fortschritts auf dem Weg zum Sprint-Ziel eine nützliche Übung. Vor einigen Jahren wurde die Verpflichtung des Entwicklungsteams, ein Burndown-Diagramm zu pflegen, aus dem Scrum Guide entfernt. Dies bedeutet jedoch nicht, dass ein Burndown-Diagramm unnütz ist.)
• Statusreport: Das Daily Scrum ist ein Statusreport-Meeting, und die Mitglieder des Entwicklungsteams warten darauf, ihre Fortschritt an den Scrum Master, den Product Owner oder vielleicht sogar an einen Stakeholder zu „berichten“.
• Nur Ticketnummern: Updates sind generisch und haben für andere keinen oder nur geringen Wert. („Gestern habe ich an X-123 gearbeitet. Heute werde ich an X-129 arbeiten.“)
• Planungsmeeting: Das Entwicklungsteam nutzt das Daily Scrum, um neue Anforderungen zu diskutieren, User Stories zu verfeinern oder eine Art (Sprint)-Planning durchzuführen.
• Problemlösungsmeeting: Diskussionen werden angestoßen, um Probleme zu lösen, anstatt diese zu parken, damit sie nach dem Daily Scrum gelöst werden können.
• Übermässiges Feedback: Teammitglieder kritisieren andere Teammitglieder sofort, um eine Diskussion anzufachen, anstatt ihre Einwände nach dem Daily Scrum weiter zu verfolgen.
• Monologe: Die Teammitglieder verletzen die Zeitvorgabe von 15 Minuten und beginnen Monologe. (60 bis 90 Sekunden pro Teammitglied sollten mehr als genug Zeit sein.)
• Statler und Waldorf: Ein paar Teammitglieder kommentieren jedes Problem. (Normalerweise ist das nicht nur Zeitverschwendung, sondern neigt auch dazu, bevormundend und ärgerlich zu sein.)
• Keine Verwendung des Alters von Arbeitsaufgaben (work item age): Ein Entwickler hat Schwierigkeiten, eine Arbeitsaufgabe über mehrere aufeinanderfolgende Tage hinweg zu lösen, und niemand bietet Hilfe an. (Oft ist dieses Ergebnis ein Zeichen dafür, dass entweder die Teammitglieder einander nicht vertrauen oder sich nicht umeinander kümmern. Oder die Arbeitsbelastung der Entwickler ist so hoch, dass sie sich nicht mehr gegenseitig unterstützen können. Ein Hinweis: Natürlich erwähnt der Scrum Guide das „Work Item Age“ nicht. Es hat sich jedoch als nützliche Praxis erwiesen.)
• Null Problemo: Niemand meldet irgendwelche Hindernisse; niemand braucht Hilfe oder Unterstützung von seinen Teamkollegen. (Glückwunsch zu Eurer scheinbar gut geölten Scrum-Maschine! Könnte es jedoch sein, dass sich die Entwickler nicht sicher fühlen, Fragen, Herausforderungen oder Probleme anzusprechen?)

Entwickler Fehlverhalten beim Sprint Review

Sind wir noch auf dem richtigen Weg, das Produktziel zu erreichen? Und wie hat der vorangegangene Sprint zur Mission unseres Scrum-Teams beigetragen? Die Beantwortung dieser Fragen und die Anpassung des Produkt-Backlogs in einer gemeinsamen Anstrengung des Scrum-Teams mit internen und externen Stakeholdern ist der Zweck des Sprint-Reviews. Zu den Fehlverhalten der Scrum Entwickler in diesem Event gehören unter anderem:

• Tod durch PowerPoint: Die Teilnehmer des Sprint Reviews sind durch PowerPoint zu Tode gelangweilt. (Die Grundlage für einen erfolgreichen Sprint Review lautet „show, don’t tell“, oder noch besser: lassen Sie die Beteiligten die Entdeckung selbst vorantreiben. Der Sprint Review ist keine „Demo“, bei der sorgfältig alle Hindernisse umgangen werden, um die Illusion von Fortschritt und Kontrolle zu wahren. Stattdessen ist es eine wichtige Gelegenheit, zu überprüfen, was das Scrum-Team erreicht hat, wertvolles Feedback zu erhalten und das Produkt-Backlog gemeinsam anzupassen. Es geht darum, Transparenz über den Stand des Fortschritts des Teams in Richtung des Produktziels zu schaffen.)
• Immer wieder die selben Gesichter: Es sind immer die gleichen Leute aus dem Entwicklungsteam, die teilnehmen, niemals jedoch alle. (Sofern die Organisation nicht versucht, die Anwendung von Scrum basierend auf LeSS oder Nexus zu skalieren, dann ist dies ein schlechtes Zeichen. Um die Erkennitgewinnung des Scrum Teams zu maximieren, setzt der Sprint Review die Teilnahme aller Scrum Teammitglieder voraus. Die Herausforderung besteht darin, dass man die Teilnahme der Teammitglieder jedoch auch nicht erzwingen kann. Stattdessen sollte man den Sprint Review so interessant machen, dass jeder teilnehmen möchte. Wenn dies nicht geschieht, sollte man sich als Scrum Master als erstes fragen, was man zu dieser Situation beigetragen hat. Es ist ein Glücksfall, dass eine Veranstaltung, die auf dieses Bedürfnis zugeschnitten ist, unmittelbar auf den Sprint Review folgt — die Retrospektive.)
• Nebenjobs: Die Entwickler arbeiteten an Problemen außerhalb des Sprint-Ziels, und der Product Owner erfuhr davon zum ersten Mal während des Sprint Reviews. (Dieses Sprint-Review-Anti-Muster ist wahrlich problematisch. Fokus, Commitment und Offenheit — um nur die offensichtlichsten Scrum-Werte zu nennen, gegen die hier verstoßen wird — sind die ersten Prinzipien für die Zusammenarbeit zwischen den Mitgliedern des Scrum-Teams. Alles, was die Entwickler während des Sprints angehen wollen, muss während der Sprintplanung besprochen werden. Ein besonderer Fall liegt m. E. jedoch vor, wenn der Product Owner in der Regel so sehr auf die Auslieferung neuer Funktionen drängt, dass wenig oder gar keine Zeit für Refactoring oder Bugfixing bleibt, es sei denn, die Entwickler nehmen diese Aufgaben heimlich in Angriff. In dieser Situation hätte ich durchaus Verständnis für diesen Ansatz. Dennoch muss das Scrum-Team dieses Problem beheben. Generell könnte es ein Anfang sein, 20 % der Kapazität des Teams für die vorgenannten Aufgaben zu verwenden.)
• Schummeln: Zunehmend häufiger stellen die Entwickler Arbeiten vor, die noch nicht „done“ sind. (Es gibt einen guten Grund, in manchen Fällen unvollendete Arbeit zu zeigen. Zum Beispiel, um den Stakeholdern Transparenz über wichtige, aber schwierige Aufgaben zu verschaffen. Wenn Sie den Teilnehmern des Sprint Review jedoch regelmäßig über teilweise abgeschlossene Arbeiten berichten, verstoßen Sie gegen das Konzept des „Done“, eines der ersten Prinzipien von Scrum. Ein erfolgreiches Scrum-Team muss die Stakeholdern nicht überreden, dass es sein Gehalt wert ist.)

Fehlverhalten der Scrum Entwickler bei der Sprint-Retrospektive

Welches Ereignis könnte das Empirieprinzip von Scrum besser verkörpern als die Sprint Retrospektive? Ich nehme an, alle sind sich einig, dass selbst die einfachste Retrospektive – wenn sie nur regelmäßig stattfindet – weitaus nützlicher ist, als ab und zu eine ausgefallene zu haben, ganz zu schweigen davon, dass man überhaupt keine Retrospektive hat. Zu den notorischen Anti-Mustern bei Retrospektiven aufseiten der Scrum Entwickler gehören:

• #NixRetro: Es gibt keine Retrospektive, da das Team glaubt, dass es nichts zu verbessern gibt. Meines Erachtens gibt es kein agiles Nirwana, wo alles einfach perfekt ist. Wie so schön gesagt wird: Agilität ist eine Reise und kein Ziel. Es gibt immer etwas zu verbessern.
• Retrospektive als Zeitpuffer: Das Team sagt Retrospektiven ab, wenn mehr Zeit für die Erreichung des Sprint-Ziels benötigt wird. (Die Retrospektive als Zeitreserve für den Sprint ist ein häufiges Zeichen für Cargo-Cult Scrum. Ich glaube, dies ist noch schlimmer als keine Retrospektive zu haben, weil es angeblich nichts zu verbessern gäbe. Letzteres ist nur ein allzu menschlicher Irrtum, der an Hybris grenzt. Die willkürliche Absage einer Retrospektive zur Erreichung eines Sprint-Ziels ist jedoch ein klares Zeichen dafür, dass das Team Grundprinzipien wie Empirie und kontinuierliche Verbesserung nicht versteht. Wenn das Scrum Team wiederholt das Sprint-Ziel nicht erreicht, sollte es überprüfen, was hier vor sich geht. Und welches Scrum-Ereignis ist für diesen Zweck konzipiert?)
• Die Definition of Done wird nicht verbessert: Die Entwickler sprechen sich nicht dafür aus, die Definition von Done regelmäßig zu überprüfen und zu diskutieren, ob sie verbessert werden muss. (Wie das Sprichwort sagt: Stillstand ist Rückschritt. Wenn das Scrum-Team immer besser versteht, wie es die Probleme seiner Kunden lösen kann, sollte dieser Wissenszuwachs in einer regelmäßig angepassten Definition of Done zum Ausdruck kommen. Andernfalls würde das Scrum-Team riskieren, seinen Beitrag zur geschäftlichen Agilität der Organisation langsam, aber sicher zu schmälern.)
• Übermässiges Jammern: Das Scrum Team nutzt die Retrospektive vor allem, um sich über die Situation zu beschweren und nimmt dabei die Rolle des Opfers ein. (Veränderungen erfordert Nachdenken, und gelegentlich ist es eine gute Übung, Dampf abzulassen. Passiv bleiben, sobald man kritische Probleme identifiziert hat, und nicht zu versuchen, diese zu ändern, widerspricht jedoch dem Zweck der Retrospektive.)

Fehlverhalten in Sachen Product Backlog

Scrum ist ein taktisches Framework für die Entwicklung von Produkten, vorausgesetzt, Sie erkennen im Voraus, was es wert ist, entwickelt zu werden. Aber selbst nach einer erfolgreichen Produktentdeckungsphase, neudeutsch: Product Discovery, kann es Ihnen schwer fallen, das Richtige auf die Beine zu stellen, wenn Ihr Product Backlog der Aufgabe nicht gewachsen ist: Garbage in, Garbage out. Einige Beispiele dafür, wie Scrum Entwickler zu mittelmäßigem Teamerfolg beitragen, sind:

• Keine Zeit für Refinement: Das Scrum-Team führt nicht genügend Sitzungen zur Verfeinerung des Product Backlogs durch, was zu einem qualitativ minderwertigen Product Backlog führt. (Der Scrum Guide 2017 empfahl ursprünglich, bis zu 10 % der Zeit des Scrum-Teams auf die Verfeinerung des Product Backlogs zu verwenden. Das ist eine gute geschäftliche Entscheidung: Nichts ist teurer als eine schlecht konzipierte Funktion, die wenig oder gar keinen Wert für die Kunden schafft.)
• Zuviel Refinement: Das Scrum-Team hat zu viele Verfeinerungssitzungen, was zu einem zu detaillierten Product Backlog führt. (Zu viel Verfeinerung ist auch nicht hilfreich. Es gibt einen Zeitpunkt, an dem der Grenzertrag zusätzlicher Verfeinerungsarbeit gleich Null oder wahrscheinlich sogar negativ ist — denken Sie an das Phänomen der Analyse-Paralyse. Die einzige Möglichkeit für ein Scrum-Team zu verstehen, ob die vorherige Validierung der zugrunde liegenden Hypothesen einer neuen Funktionalität korrekt ist, besteht darin, dieses Teil zu bauen und auszuliefern. Es gibt keine Möglichkeit, dies am grünen Tisch herauszufinden, indem man das Thema endlos von allen denkbaren Seiten beleuchtet und diskutiert.)
• Eine Schätzung für jeden Eintrag: Alle Einträge des Product Backlog sind detailliert ausgearbeitet und geschätzt. (Das ist zu viel Vorleistung und birgt das Risiko einer Fehlallokation der Arbeitszeit des Scrum-Teams. Die Verfeinerung der Product Backlog-Einträge ist ein kontinuierlicher Prozess, der nur bis zu dem Punkt fortgesetzt wird, an dem das Scrum-Team diese Einträge in Produkt-Inkremente umwandeln kann.)
• Überdimensioniertes Produktbacklog: Das Team erstellt ein umfangreiches Product Backlog. (Die Erstellung eines „Inventars von Arbeitsaufgaben“ ist ein Fehler. In einer komplexen Umgebung mit vielen Unwägbarkeiten führt diese Vorleistung häufig zu einer Verschwendung in Form von Product Backlog-Elementen, die zwar verfeinert, aber nie veröffentlicht werden, da später wertvollere Elemente identifiziert werden. Die Scrum Entwickler sollten auf diese Herausforderung hinweisen und den Product Owner dabei unterstützen, das Product Backlog übersichtlich und umsetzbar zu halten; ein Inventar von drei bis sechs Sprints ist in der Regel mehr als ausreichend.
• Unterwürfige Entwickler: Die Entwickler befolgen willfährig alle Anweisungen des Product Owners. (Es ist die vornehmste Pflicht eines jeden Teammitglieds, den Product Owner herauszufordern, ob dessen Auswahl von Arbeitsaufgaben die beste Nutzung der Zeit der Entwickler darstellt: Warum sollen wir das tun? Scrum funktioniert nicht, wenn sich nicht jeder an die in das Framework eingebauten Checks & Balances hält. Es ist leicht, sich in „die eigene Lösung“ zu verlieben, anstatt sich um das eigentliche Kundenproblem zu kümmern. Wenn die Entwickler einfach alles machen, was der Product Owner „vorschlägt“, wird der vom Scrum-Team geschaffene Gesamtwert wahrscheinlich unter seinem Potenzial liegen. Deshalb wollen Sie Missionare in Ihrem Team haben, nicht nur Söldner.)

Fazit: Das Fehlverhalten von Scrum-Entwicklern

Angesichts der wesentlichen Rolle, welche die Entwickler erfüllen müssen, um Scrum erfolgreich zu machen, ist es keine Überraschung, dass es viele Anti-Muster von Scrum Entwickler zu beobachten gibt. Die gute Nachricht ist jedoch, dass die Mehrheit davon unter der Kontrolle des Scrum-Teams stehen. Alles, was es braucht, um diese Anti-Muster für das Team in Angriff zu nehmen, ist, sie zu inspizieren und eine Verbesserung der bisherigen Vorgehensweise zu adaptieren. Warum nicht einfach die nächste Retrospektive dafür nutzen?

Welche Anti-Muster von Scrum Entwicklern haben Sie beobachtet? Bitte teilen Sie uns diese in den Kommentaren mit.

Fehlverhalten von Scrum Entwicklern — Empfohlene Lektüre

28 Product Backlog Anti-Patterns

27 Sprint Anti-Patterns Holding Back Scrum Teams

20 Sprint Planning Anti-Patterns

24+2 Daily Scrum Anti-Patterns.

15 Sprint Review Anti-Patterns.

21 Sprint Retrospektive Anti-Patterns

36 Fehlverhalten von Scrum Interessenvertretern.

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.

✋ Nicht versäumen: Lernen Sie mehr über das Scrum Entwickler Fehlverhalten im 11.000-köpfigen „Hands-on Agile Slack Team“

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel Fehlverhalten von Scrum Entwicklern wurde zunächst auf Berlin-Product-People.com veröffentlich. (Noch einer für Dich, Shaun.)