Skip to main content

Agile Verhandlungen – Das Leben ist Verhandlungssache; warum sollte Scrum anders sein? đŸ‡©đŸ‡Ș

May 11, 2023

In KĂŒrze: Das Leben ist Verhandlungssache; warum sollte Scrum anders sein?

Das Leben ist eine Verhandlungssache. Warum sollte Scrum anders sein, zumal es einen egalitĂ€ren Charakter hat? Wie Sie sich vielleicht erinnern, kann niemand in einem Scrum-Team einem anderen vorschreiben, was er zu tun hat, wie er es zu tun hat oder wann er es zu tun hat. Stattdessen erfordert die Lösung der Probleme Ihrer Kunden in einer komplexen Umgebung KommunikationsfĂ€higkeit, EinfĂŒhlungsvermögen, Geduld, Diplomatie und ProfessionalitĂ€t. Lassen Sie uns also einen Blick auf einige typische agile Verhandlungen werfen.

Agile Verhandlungen - Das Leben ist Verhandlungssache; warum sollte Scrum anders sein?

🗞 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 46.000 Abonnenten anschließen.

🎓 đŸ‡©đŸ‡Ș Garantiert: Professional Scrum Product Owner Schulung fĂŒr Fortgeschrittene (PSPO-A) mit PSPO II Zertifikat — 23. und 24. Mai 2023.

📖 Lassen Sie sich benachrichtigen, wenn das Scrum Anti-Patterns Guide Buch verfĂŒgbar ist!

 

 

Download the 60 ChatGPT Prompts for Scrum Masters & Product Owners Guide for Free

Agile Verhandlungen: Die verschiedenen Ebenen

Damit Scrum gut funktioniert, ist es unerlĂ€sslich, dass das Scrum-Team und die Stakeholder kontinuierlich darĂŒber diskutieren, wie sie ihre Ziele, Erwartungen, Praktiken und Prinzipien aufeinander abstimmen können. Diese GesprĂ€che gewĂ€hrleisten, dass das Team im Rahmen der gegebenen EinschrĂ€nkungen einen Mehrwert fĂŒr den Kunden liefern kann und gleichzeitig zur Nachhaltigkeit des Unternehmens beitrĂ€gt. WĂ€hrend der Scrum Guide mehrere Beispiele fĂŒr diese agile Verhandlung anfĂŒhrt, stammen viele andere aus der Anwendung von agiler Vorgehensweise in etablierten Organisationen.

Es gibt verschiedene Szenarien fĂŒr agile Verhandlungen, die bekanntesten sind die teaminterne und die Team-Stakeholder-Ebene:

Beispiele fĂŒr teaminterne Verhandlungen

Diese Bereiche decken die praktische Arbeit eines Scrum-Teams ab, von der Verfeinerung des Produkt-Backlogs ĂŒber den Sprint bis zur Retrospektive. Daher sind die Listen bei weitem nicht vollstĂ€ndig. Sie sollten jedoch die Möglichkeit bieten, zusĂ€tzliche Szenarien zu entdecken, um sich auf diese vorzubereiten:

Das Produkt-Backlog und dessen Verfeinerung

  • Aushandlung des Umfangs: Der Product Owner, die Teammitglieder und die Stakeholder diskutieren den Umfang des Projekts oder des Produkts und verhandeln ĂŒber eventuell notwendige Anpassungen oder Änderungen.
  • Verfeinerung des Produkt-Backlogs: Der Product Owner und die Entwickler arbeiten zusammen, um die Elemente des Produkt-Backlogs auf der Grundlage von Wert, Risiko und AbhĂ€ngigkeiten zu verfeinern, zu schĂ€tzen und zu ordnen.
  • Ausbalancieren von technischen Schulden und neuen Funktionen: Das Scrum-Team muss aushandeln, wie die technischen Schulden beseitigt und gleichzeitig neue Funktionen geliefert werden können, wobei QualitĂ€t, Wartbarkeit sowie Kunden- und GeschĂ€ftsanforderungen berĂŒcksichtigt werden mĂŒssen.
  • Akzeptanzkriterien: Der Product Owner, die Entwickler und wahrscheinlich auch die Stakeholder verhandeln ĂŒber die spezifischen Anforderungen, die erfĂŒllt sein mĂŒssen, damit ein Element des Produkt-Backlogs als “done” akzeptiert wird.
  • AufwandsschĂ€tzung: Die Entwickler können den Aufwand fĂŒr die Fertigstellung jedes Produkt-Backlog-Elements mithilfe von Techniken wie Planning Poker, T-Shirt Sizing oder dem Bucket System aushandeln.

Die Sprint-Planungsebene

  • Sprint-Ziel: Die Mitglieder des Scrum-Teams einigen sich auf ein Sprint-Ziel, das beschreibt, was das Team auf der Grundlage der GeschĂ€ftsziele des aktuellen Sprints erreichen will.
  • Technische Lösungen: Die Entwickler verhandeln ĂŒber Architekturentscheidungen, Designmuster und Codepraktiken, um die besten technischen Lösungen zu implementieren.
  • Zuweisung von Aufgaben und Verantwortlichkeiten: Die Entwickler verhandeln untereinander die Verteilung von Aufgaben und Verantwortlichkeiten auf der Grundlage ihrer FĂ€higkeiten, ihres Fachwissens und ihrer KapazitĂ€ten.
Download the ’Scrum Anti-Patterns Guide’ for Free

Der Sprint Level

  • Konflikte und Probleme lösen: WĂ€hrend des Sprints kann es zu Unstimmigkeiten und Konflikten kommen, so dass die Teammitglieder verhandeln und Lösungen finden mĂŒssen.
  • KlĂ€rung von Anforderungen: Die Entwickler benötigen möglicherweise weitere Klarstellungen oder Details zu Elementen des Produkt-Backlogs aus dem Sprint Backlog. Sie könnten mit dem Product Owner verhandeln, um die Abnahmekriterien oder andere Spezifikationen zu verfeinern, um ein klares VerstĂ€ndnis dessen zu gewĂ€hrleisten, was sie liefern sollen.
  • Änderungen der PrioritĂ€t: Unvorhergesehene Ereignisse oder verĂ€nderte GeschĂ€ftsanforderungen können dazu fĂŒhren, dass der Product Owner die PrioritĂ€t bestimmter Elemente des Produkt-Backlogs wĂ€hrend des Sprints neu bewertet. Die Entwickler und der Product Owner mĂŒssen verhandeln, ob das Team die Änderungen im Rahmen des aktuellen Sprint-Ziels berĂŒcksichtigen kann oder ob sie auf einen zukĂŒnftigen Sprint verschoben werden sollen. In seltenen FĂ€llen kann das Ergebnis dieser Diskussion eine Absage des Sprints sein.
  • Anpassungen des Umfangs: Es kann vorkommen, dass die Entwickler feststellen, dass ein Element des Produkt-Backlogs komplexer ist als ursprĂŒnglich angenommen und zusĂ€tzlichen Aufwand oder Zeit erfordert. Die Entwickler und der Product Owner mĂŒssen möglicherweise eine Anpassung des Umfangs aushandeln, z. B. die Verschiebung eines Teils der Arbeit auf einen zukĂŒnftigen Sprint.
  • Technische Entscheidungen und Zielkonflikte: Die Entwickler können auf technische Herausforderungen oder EinschrĂ€nkungen stoßen, die sie dazu zwingen, Kompromisse zwischen verschiedenen Lösungen zu schließen. Möglicherweise mĂŒssen sie mit dem Product Owner verhandeln, um sich unter BerĂŒcksichtigung von Kosten, Zeit, Wartbarkeit und Leistungsfaktoren auf den besten Ansatz zu einigen.
  • Hindernisse und Blocker: Die Entwickler können wĂ€hrend des Sprints auf Hindernisse oder Blocker stoßen, die ihre FĂ€higkeit, ihre Arbeit abzuschließen, beeintrĂ€chtigen. Möglicherweise mĂŒssen sie mit dem Product Owner verhandeln, um Lösungen zu finden, z. B. indem sie die Aufgaben neu priorisieren.
  • Release-Planung: Die Mitglieder des Scrum-Teams mĂŒssen aushandeln, was das Team wann an wen freigeben wird.

Der Sprint-Review-Level

  • Sprint Review: WĂ€hrend des Sprint Reviews ĂŒberprĂŒfen das Scrum Team und die Stakeholder die wĂ€hrend des Sprints geleistete Arbeit und diskutieren mögliche Verbesserungen oder Änderungen am Produkt.
  • Priorisierung des Feedbacks: Die Stakeholder geben möglicherweise Feedback zu dem/den Inkrement(en), und das Scrum-Team muss möglicherweise die PrioritĂ€t und Dringlichkeit der Bearbeitung dieses Feedbacks aushandeln. Diese Diskussion könnte das HinzufĂŒgen neuer Produkt-Backlog-Elemente, das Ändern bestehender Elemente oder das Ordnen des Backlogs in Übereinstimmung mit dem Produktziel beinhalten.
  • Zeitplan und Release-Erwartungen: Stakeholder haben womöglich Erwartungen, wann bestimmte Funktionen oder FĂ€higkeiten im Produkt verfĂŒgbar sein werden. Folglich muss das Scrum-Team möglicherweise Änderungen am Zeitplan fĂŒr die Veröffentlichung aushandeln.
  • Risikominimierung: Die Stakeholder könnten wĂ€hrend des Sprint Reviews neue Risiken identifizieren oder Bedenken zu bestehenden Risiken Ă€ußern. Das Team und die Stakeholder mĂŒssen Strategien zur AbschwĂ€chung dieser Risiken aushandeln und sie gegen andere PrioritĂ€ten abwĂ€gen.

Die Retrospektivenebene

  • Reflektieren ĂŒber Prozessverbesserungen: WĂ€hrend der Sprint-Retrospektive diskutiert und verhandelt das Scrum-Team ĂŒber mögliche Prozessverbesserungen und Experimente fĂŒr den nĂ€chsten Sprint, um seine Arbeitsweise zu verbessern.
  • Abgleich der Verbesserungsmaßnahmen mit der Arbeit im Sprint: Das Team muss möglicherweise verhandeln, wie viel Zeit und Aufwand es fĂŒr die Umsetzung von Verbesserungsmaßnahmen im nĂ€chsten Sprint aufwenden kann, wobei es seine anderen Verpflichtungen und PrioritĂ€ten berĂŒcksichtigt.
  • Priorisierung von Verbesserungsmaßnahmen: Das Scrum-Team kann mehrere potenzielle Maßnahmen identifizieren, um die Verbesserungsbereiche anzugehen. Sie mĂŒssen diese Aktionen auf der Grundlage von Auswirkungen, Aufwand und AbhĂ€ngigkeiten aushandeln und priorisieren.
  • Zuweisung von Verantwortung und Ownership: Die Teammitglieder mĂŒssen möglicherweise aushandeln, wer bestimmte Verbesserungsmaßnahmen umsetzt und ihre Fertigstellung wĂ€hrend der kommenden Sprints sicherstellt, eine direkt verantwortliche Person (DRI).
  • ÜberprĂŒfung frĂŒherer Entscheidungen und Vereinbarungen: Das Team kann Entscheidungen oder Vereinbarungen, die in frĂŒheren Retrospektiven getroffen wurden, erneut ĂŒberprĂŒfen, ihre Wirksamkeit bewerten und darĂŒber diskutieren, ob sie angepasst oder beibehalten werden sollten. Eventuell mĂŒssen sie Änderungen an diesen Vereinbarungen aushandeln.
  • Entscheidung ĂŒber Teamnormen und -praktiken: Die Mitglieder des Scrum-Teams verhandeln und vereinbaren ihre Arbeitsvereinbarung, einschließlich Kommunikationsnormen, Tools und Techniken, die ihre Zusammenarbeit und ProduktivitĂ€t am besten unterstĂŒtzen.
  • Ansprechen von Teamdynamik und zwischenmenschlichen Problemen: Das Team kann Bedenken hinsichtlich der Kommunikation, der Zusammenarbeit oder des Vertrauens zwischen den Teammitgliedern diskutieren. Sie mĂŒssen möglicherweise aushandeln, wie diese Probleme durch teambildende Maßnahmen, Konfliktlösung oder Coaching angegangen werden können.
  • Definition of Done (DoD): Das Scrum-Team verhandelt und vereinbart die Kriterien, die ein Produkt-Backlog-Element erfĂŒllen muss, um als „done“ zu gelten.
Download the 60 Scrum Master Interview Questions to Identify Suitable Candidates

Agile Verhandlungen: Beispiele auf der Team-Stakeholder-Ebene

Beispiele fĂŒr agile Verhandlungen zwischen Scrum-Teams und Stakeholdern sind deutlich weniger offensichtlich, da sie weitgehend von den organisatorischen und kulturellen Bedingungen der Organisation abhĂ€ngen. Außerdem sind sie von der Art des angebotenen Produkts oder der Dienstleistung abhĂ€ngig. Um ein Mindestmaß an Struktur zu schaffen, unterscheide ich zwischen drei grundlegenden Szenarien, von der Produktebene ĂŒber die Koordination (der tĂ€glichen Arbeit) bis hin zum Personalmanagement. NatĂŒrlich gibt es zahlreiche weitere Bereiche, die ein systematischer Ansatz zur Kategorisierung von Szenarien berĂŒcksichtigen mĂŒsste:

Die Produktebene

  • Abstimmung der Produktvision und der Produktziele: Die Stakeholder und der Product Owner mĂŒssen möglicherweise die allgemeine Produktvision, die Ziele und die strategische Ausrichtung aushandeln und abstimmen, um sicherzustellen, dass die Arbeit des Scrum-Teams die Ziele der Organisation unterstĂŒtzt.
  • Priorisierung organisatorischer Initiativen: Das Scrum Team und die Stakeholder mĂŒssen die Priorisierung verschiedener organisatorischer Initiativen aushandeln, die sich auf den Fokus und die KapazitĂ€t des Teams auswirken können.
  • Erstellung eines Release-Plans: Der Product Owner, das Management und die Stakeholder arbeiten zusammen und verhandeln einen Release-Plan, wobei sie Erwartungen, Ressourcen und zeitliche BeschrĂ€nkungen ausbalancieren.
  • Ausgleich der Interessen der Stakeholder: Das Scrum-Team muss die Interessen mehrerer Stakeholder vereinbaren und dabei sicherstellen, dass ihre BedĂŒrfnisse und Bedenken berĂŒcksichtigt werden, wĂ€hrend der Fokus des Teams auf der Lieferung von Mehrwert fĂŒr die Kunden liegt.
  • Erwartungen setzen und managen: Das Scrum-Team muss mit dem Management und den Stakeholdern verhandeln, um die Erwartungen in Bezug auf Lieferfristen, Umfang und QualitĂ€t festzulegen und zu managen.
  • QualitĂ€t und Compliance: Der Product Owner und die Entwickler mĂŒssen möglicherweise mit den Stakeholdern verhandeln, um QualitĂ€tsstandards, gesetzliche Anforderungen oder andere Compliance-Kriterien zu definieren, die das Scrum Team wĂ€hrend der Produktentwicklung einhalten muss.
  • Risikomanagement: Der Product Owner und die Stakeholder mĂŒssen möglicherweise bei der Identifizierung, Bewertung und EindĂ€mmung von Risiken, die sich auf das Projekt auswirken könnten, zusammenarbeiten und eine Risikopriorisierung und Reaktionsstrategien aushandeln.

Die Koordinationsstufe

  • Beteiligung der Stakeholder und Kommunikation: Der Product Owner und der Scrum Master mĂŒssen möglicherweise den Grad und die HĂ€ufigkeit der Beteiligung der Stakeholder am Scrum-Prozess aushandeln, um sicherzustellen, dass die Stakeholder informiert und einbezogen werden, wĂ€hrend die Arbeit des Scrum-Teams möglichst wenig gestört wird.
  • Ressourcenzuteilung: Das Scrum-Team muss möglicherweise mit den Stakeholdern verhandeln, um die notwendigen Ressourcen wie AusrĂŒstung, Werkzeuge oder Budget zu sichern, um das Produkt effektiv zu liefern.
  • Management organisatorischer VerĂ€nderungen: Das Scrum-Team muss möglicherweise mit dem Management und den Stakeholdern verhandeln, um organisatorische VerĂ€nderungen voranzutreiben und zu unterstĂŒtzen, z. B. die EinfĂŒhrung agiler Praktiken wie Scrum, neuer Tools oder struktureller VerĂ€nderungen.
  • Berichterstattung und Metriken: Das Scrum Team und die Stakeholder mĂŒssen gegebenenfalls ĂŒber die Art der Berichte, Metriken oder KPIs verhandeln, die zur Verfolgung des Fortschritts und der Leistung des Scrum Teams verwendet werden: Die Ergebnisse sollten sicherstellen, dass sie wertvolle Einblicke liefern und die Entscheidungsfindung unterstĂŒtzen, ohne einen ĂŒbermĂ€ĂŸigen Aufwand zu verursachen.
  • Handhabung von Eskalationen und kritischen Problemen: Wenn kritische Probleme auftauchen, mĂŒssen das Scrum-Team, das Management und die Stakeholder verhandeln und zusammenarbeiten, um die Situation zu bewĂ€ltigen, wobei die Notwendigkeit schnellen Handelns mit der Autonomie und Arbeitsweise des Teams in Einklang zu bringen ist.
  • AbhĂ€ngigkeiten managen: Das Scrum-Team muss möglicherweise mit anderen Scrum-Teams oder Abteilungen verhandeln, um AbhĂ€ngigkeiten zu managen, die Arbeit zu koordinieren und einen reibungslosen Lieferprozess zu gewĂ€hrleisten.

PersonalfĂŒhrungsebene

  • Teamzusammensetzung: Die Mitglieder des Scrum-Teams und das Management mĂŒssen unter UmstĂ€nden die optimale Teamzusammensetzung aushandeln und dabei Faktoren wie FĂ€higkeiten, Erfahrung und Teamdynamik berĂŒcksichtigen. Außerdem mĂŒssen sie sich darauf einigen, wie sie neue Teammitglieder finden.
  • Ausgleich zwischen individuellen und Scrum-Team-Zielen: Die Teammitglieder mĂŒssen möglicherweise mit dem Management ihre persönlichen Entwicklungsziele und -wĂŒnsche mit den kollektiven Zielen und BedĂŒrfnissen des Scrum-Teams aushandeln.
  • Karriereentwicklung: Vorgesetzte und Scrum-Team-Mitglieder mĂŒssen gegebenenfalls PlĂ€ne fĂŒr die berufliche Entwicklung aushandeln, einschließlich Zielen, Weiterbildungsmöglichkeiten und möglichen Karrierewegen innerhalb des Unternehmens.
  • VergĂŒtung und Sozialleistungen: Vorgesetzte und Scrum-Teammitglieder mĂŒssen möglicherweise darĂŒber verhandeln, ob die bestehenden individuellen VergĂŒtungspakete, einschließlich Gehalt, Boni und anderer Leistungen, mit den BedĂŒrfnissen des Scrum-Teams ĂŒbereinstimmen, das als geschlossene Einheit und nicht als Gruppe von Einzelpersonen arbeitet.
  • Leistungsmanagement: Vorgesetzte, Scrum Master oder agile FĂŒhrungskrĂ€fte mĂŒssen möglicherweise Leistungserwartungen, Feedback-Mechanismen und Bewertungskriterien fĂŒr Teammitglieder aushandeln.
Download the Remote Agile Guide for Free

Schlussfolgerung

Der Versuch, vermeintliche AutoritĂ€t ĂŒber Teamkollegen oder Stakeholder auszuĂŒben oder eine Brechstange als das Werkzeug Ihrer Wahl zu verwenden, um Probleme zu lösen und Entscheidungen zu beschleunigen, wird Sie bei der Arbeit in einer komplexen Umgebung mit agilen Teams nicht weiterbringen.

Stattdessen sollten Sie besser gut im kontinuierlichen agilen Verhandeln werden, denn die Lösung der Probleme Ihrer Kunden in einem komplexen Umfeld erfordert KommunikationsfĂ€higkeit, EinfĂŒhlungsvermögen, Geduld, Diplomatie und ProfessionalitĂ€t.

Wie verhandeln Sie mit Teamkollegen, Stakeholdern und dem Management? Bitte teilen Sie uns Ihre Erfahrungen in den Kommentaren mit.

📖 Agile Verhandlungen — Weitere LektĂŒre

Why Agile Turns into Micromanagement

Agile FĂŒhrung — Ein kurzer Überblick ĂŒber Konzepte und Ideen

The Power and Pains of Autonomy — Jimmy JanlĂ©n auf dem Agile Camp Berlin 2021

Adapt How You Lead for Agile Success — Johanna Rothman at the Agile Camp Berlin 2021

The Free Scrum Anti-Patterns Guide

✋ Nicht versĂ€umen: Lernen Sie mehr ĂŒber Agile Verhandlungen in der 12.000-köpfigen „Hands-on Agile“ Slack-Community

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.

Membership Application for the Hands-on Agile Slack Community

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 Agile Verhandlungen – Das Leben ist Verhandlungssache; warum sollte Scrum anders sein? erschien zunĂ€chst auf Berlin-Product-People.com.


What did you think about this post?