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

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.

🗞 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.

Last week’s most popular discussion on LinkedIn: 🤬 Rant: Scrum Masters are no Project Managers!

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

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

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.

Cannot see the form? Please click here.

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.

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.

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

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Lernen Sie mit unseren Scrum-Schulungen, -Workshops und -Veranstaltungen Agile Verhandlungen besser zu verstehen. Sie können sich Ihren Platz direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ 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.

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.

Unterstützen Sie Ihre Scrum Team in Hinblick auf agile Verhandlungen, indem Sie auf den kostenlosen Scrum Anti-Patterns Guide hinweisen:

Tags: Agility, Business Agility