Fehlverhalten von Scrum Entwicklungsteams

Scrum Anti-Patterns Guide — Berlin Product People

In Kürze: Scrum Entwicklungsteam Fehlverhalten

Nachdem bereits Anti-Muster von Scrum Mastern und Product Ownern beschrieben wurde, sind der Gegenstand dieses Artikels Entwicklungsteam Fehlverhalten, wobei wir alle Scrum Events sowie das Product Backlog-Artefakt berücksichtigen. Erfahren Sie mehr darüber, worauf Sie achten müssen, wenn Sie Ihre Teamkollegen auf dem Pfad der kontinuierlichen Weiterentwicklung unterstützen wollen.

Scrum Entwicklungsteam Fehlverhalten — Berlin Product People GmbH

Möchten Sie neue Artikel künftig in Ihrem Posteingang vorfinden? Sie können sich hier für unseren Newsletters ‘Food for Agile Thought’ anmelden und sich 26,000 anderen Abonnenten anschließen.

📅 Nehmen Sie am 25. Hands-on Agile-Meetup am 20. August 2020 teil, um virtuelles Ecocycle Planning mit Qiqochat und Mural zu erkunden.

Die Rolle des Entwicklungsteams in Scrum

Gemäß dem Scrum-Guide besteht das Entwicklungsteam aus “professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work.”

Entwicklungsteams sind daher für die in Scrum integrierten Checks & Balances unerlässlich, da das Entwicklungsteam die alleinige Kontrolle über das Sprint Backlog hat und über die Definition von “Done” wacht. Im Allgemeinen sollten Entwicklungsteams die folgenden Eigenschaften aufweisen, um erfolgreich zu sein:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Quelle: Scrum Guide 2017.

(Sehen Sie sich die vollständige Liste des Scrum Guide 2017 über das Entwicklungsteam an, indem Sie den Scrum Guide Reordered herunterladen..)

Während diese Orientierung laut Scrum-Guide einfach klingt, verwirrt es in der Praxis einige Leute, dass die Rolle “Entwicklungsteam” einer Gruppe von Personen zugewiesen wird, wodurch ein Subteam innerhalb des größeren Scrum-Teams entsteht, während die Rollen des Scrum-Masters und des Product Owners an Einzelpersonen vergeben werden. Noch verwirrender könnte die Situation sein, wenn der Scrum Master oder der Product Owner auch aktiv an der Erstellung des Produktinkrements beteiligt sind, was dazu führt, dass das Entwicklungsteam mit dem Scrum Team identisch ist. Schließlich scheint der Begriff Entwicklungsteam die Rolle auf technische Personen, z. B. Software-Ingenieure, zu beschränken.

Meiner Erfahrung nach können sich bei entsprechender Unterstützung durch den Scrum Master jedoch auch Juristen und Marketingexperten mit der Bezeichnung “Entwickler” anfreunden, wenn sie Scrum für ihre Zwecke einsetzen. Tauchen wir also in eine Reihe gängiger Entwicklungsteam Fehlverhalten ein, die signalisieren, dass Ihr Team Unterstützung braucht.

Cannot see the form?
Please click here

Entwicklungsteam Anti-Muster nach Scrum-Ereignissen

Die folgenden Listen von Entwicklungsteam Fehlverhalten beziehen sich auf vier Scrum-Ereignisse und den Sprint selbst:

Fehlverhalten des Entwicklungsteams bei der Sprintplanung

  • Kapazität? Das Entwicklungsteam überschätzt seine Kapazität und übernimmt zu viele Aufgaben. (Das Entwicklungsteam sollte stattdessen alles in Betracht ziehen, was seine 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).
  • Ignorieren technischer Schulden: Das Entwicklungsteam verlangt keine ausreichende Kapazität, um technische Schulden und Programmfehler während des Sprints zu beseitigen. (Als Faustregel gilt, dass etwa 20 % der Ressourcen bei jedem Sprint gut eingesetzt sind, um Bugs zu eliminieren und die Codebasis zu überarbeiten. Wenn der Product Owner die Notwendigkeit dieser Arbeit ignoriert und das Entwicklungsteam diese Einstellung akzeptiert, 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. Erfahren Sie mehr über technische Schulden und Scrum.)
  • 100 % Auslastung: Das Entwicklungsteam verlangt vom Product Owner keine 2Slack 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 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.Entwicklungsteam Fehlverhalten durch fehlerhafte Kapazitätsplanung und übermässige Auslastung
  • Zu detaillierte Planung: Während des Sprint Plannings plant das Entwicklungsteam jede einzelne Aufgabe des bevorstehenden Sprints im Voraus. (Man plane nicht zu kleinteilig. Es reicht, wenn 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: Das Entwicklungsteam schätzt die Teilaufgaben. (Das sieht für mich nach Buchhaltung um der Buchhaltung willen aus.)
  • Zu wenig Planung: Das Entwicklungsteam überspringt die Planung gänzlich. (Das Überspringen des Sprint Plannings ist bedauerlich, da es auch eine ausgezeichnete Gelegenheit ist, darüber zu sprechen, wie das Wissen innerhalb des Entwicklungsteams verbreitet werden kann, wohin sich die Architektur entwickelt oder ob die verwendeten Werkzeuge (noch) angemessen sind. Zum Beispiel könnte das Team auch überlegen, wer mit wem bei welcher Aufgabe Pair Programming macht. Der Planungsteil des Entwicklungsteams eignet sich auch gut, um darüber nachzudenken, wie die technische Schulden verringert werden können, siehe oben.)
  • Teamleiter? Das Entwicklungsteam erstellt keinen gemeinsamen Plan, um seine 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).
📅 Professional Scrum Master Training — Training Class Schedule — Berlin Product People GmbH

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 potenziell lieferbares Produkt-Inkrement zu erstellen, das 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 Entwicklungsteam gleichzeitig arbeiten kann. Das Überschreiten dieser WiP-Grenze führt zur Bildung zusätzlicher Warteschlangen, die folglich den Gesamtdurchsatz des Entwicklungsteams reduzieren. Die Zyklusdauer, d. h. der Zeitraum zwischen dem Start und dem Ende der Arbeit an einem Tickets, verlängert sich in Folge und die Produktivität sinkt.)
  • Rosinenpicken: Das Entwicklungsteam sucht 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 oft, dass sich z. B. Tickets in der Code-Review-Spalte unbearbeitet ansammeln. Dies ist auch ein Zeichen dafür, dass sich das Entwicklungsteam 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 nichht auf dem letzten Stand: Das Entwicklungsteam 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 des Entwicklungsteams 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: Das Entwicklungsteam arbeitet an Themen, die auf dem Sprint-Board nicht sichtbar sind. (Während Schlamperei 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 des Entwicklungsteams 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 — ist das Entwicklungsteam wahrscheinlich ohnehin eher eine Gruppe als ein Team).
  • Goldene Türklinken: Das Entwicklungsteam erhöht den Umfang 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.)Entwicklungsteam Fehlverhalten — Gold-Plating — Berlin Product People GmbH

Fehlverhalten beim Daily Scrum

Das Daily Scrum ist das wichtigste “Inspect & Adapt-Ereignis” für das Entwicklungsteam. Meiner Erfahrung nach kann man nicht erwarten, dass das Entwicklungsteam das Sprint-Ziel erreicht, wenn das Daily Scrum nicht funktioniert. Zu den Entwicklungsteam Anti-Mustern 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?)
  • 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.”)
  • 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.
  • Planungsmeeting: Das Entwicklungsteam nutzt das Daily Scrum, um neue Anforderungen zu diskutieren, User Stories zu verfeinern oder eine Art (Sprint)-Planning durchzuführen.
  • 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.)
  • Keine Verwendung des Alters von Arbeitsaufgaben (work item age): Ein Mitglied des Entwicklungsteams 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 des Entwicklungsteams ist so hoch, dass sie sich nicht mehr gegenseitig unterstützen können. Hinweis: Natürlich erwähnt der Scrum Guide nicht das “Work Item Age”. Es hat sich jedoch als nützliche Praxis erwiesen.)
  • Mangelnde Vorbereitung: Teammitglieder sind nicht auf das Daily Scrum vorbereitet. (“Ich habe einige Dinge gemacht, aber ich kann mich nicht erinnern, was. War aber wichtig.”)
  • Übermässiges Feedback: Teammitglieder kritisieren andere Teammitglieder sofort, um eine Diskussion anzufachen, anstatt ihre Einwände nach dem Daily Scrum weiter zu verfolgen.

Entwicklungsteam Fehlverhalten beim Sprint Review

  • Tod durch PowerPoint: Die Teilnehmer werden durch PowerPoint-Präsentationen zu Tode gelangweilt. (Die Grundlage für einen erfolgreichen Sprint Review ist “show, don’t tell” oder noch besser: Lassen Sie die Stakeholder selbst auf Entdeckungsreise gehen.)Entwicklungsteam Fehlverhalten — Vorführen, keine Präsentation zeigen — Berlin Product People GmbH
  • 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.)
  • Schummeln: Das Entwicklungsteam zeigt Dinge, die nicht “Done” sind. (Es gibt gute Gründe, manchmal auch unfertige Arbeiten zu zeigen. Teilweise fertiggestellte Arbeiten als erledigt vorzustellen, verletzt jedoch das Konzept von “Done”, einem der grundlegenden Prinzipien von Scrum.)
  • Es gibt kein Sprint Review: Es gibt keine Sprint-Review, da das Entwicklungsteam das Sprint-Ziel nicht erreicht hat. (Das ist ein Anfängerfehler: Gerade in einer solchen Situation ist ein Sprint-Review notwendig, um Transparenz zu schaffen.)

Fehlverhalten des Entwicklungsteams bei der Sprint-Retrospektive

  • #NixRetro: Es gibt keine Retrospektive, da das Entwicklungsteam 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, kein Ziel, und es gibt immer etwas zu verbessern.)
  • Retrospektive als Zeitpuffer: Das Entwicklungsteam 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?)
  • Übermässiges Jammern: Das Entwicklungsteam 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.)
  • Product Owner non-grata: Der Product Owner ist zur Retrospektive nicht willkommen. (Einige Leute glauben immer noch — aus welchen Gründen auch immer —, dass nur die Mitglieder des Entwicklungsteams und der Scrum Master an der Retrospektive des Teams teilnehmen sollten. Der Scrum Guide bezieht sich jedoch auf das Scrum Team, einschließlich des Product Owners. Und das aus gutem Grund: Das Team gewinnt gemeinsam, und das Team scheitert gemeinsam. Wie soll das ohne den Product Owner funktionieren?)

Fehlverhalten in Sachen Product Backlog

  • Keine Zeit für Refinement: Das Scrum-Team verfügt nicht über genügend Refinement-Sitzungen, was zu einem qualitativ schlechten Backlog führt. (Der Scrum Guide empfiehlt, bis zu 10% der Zeit des Scrum-Teams mit dem Refinement des Product Backlogs zu verbringen. Und dies ist eine gute Geschäftsentscheidung: Nichts ist teurer als eine Funktion, die keinen Wert in den Augen der Kunden hat.)
  • Zuviel Refinement: Das Scrum-Team hat zu viele Refinement-Sitzungen, was zu einem zu detaillierten Product Backlog führt. (Zu viel Refinement ist auch nicht sinnvoll.)
  • Unterwürfiges Entwicklungsteams: Das Entwicklungsteam folgt unterwürfig den Anforderungen des Product Owners. (Den Product Owner zu fragen, ob seine Auswahl an Themen die beste Nutzung der Zeit des Entwicklungsteams ist, ist ein wichtige Verpflichtung jedes Teammitglieds: Warum sollen wir diese Funktion entwickeln?)
Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

Scrum Entwicklungsteam Fehlverhalten — Fazit

Angesichts der wesentlichen Rolle, die das Entwicklungsteam erfüllen muss, um Scrum erfolgreich zu machen, ist es keine Überraschung, dass es viele Entwicklungsteam Fehlverhalten 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 des Entwicklungsteams haben Sie beobachtet? Bitte teilen Sie uns diese in den Kommentaren mit.

✋ Nicht versäumen: Lernen Sie mehr über Entwicklungsteam Fehlverhalten im 7.900-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.

Nicht versäumen: Lernen Sie mehr über die toxische Teamkultur im 7.900-köpfigen

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.

Fehlverhalten des Entwicklungsteams — Empfohlene Lektüre

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

27 Sprint Anti-Patterns Holding Back Scrum Teams

32 Fehlverhalten von Scrum Interessenvertretern.

Tags: Entwicklungsteam, Fehlverhalten, Scrum Anti-Muster

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.