Teamentwicklung als Scrum Master
Nutze die 5 Dysfunctions of a Team
Die 5 Dysfunktionen eines Teams sind ein Teamentwicklungsmodell von Patrick Lencioni. Über die 5 Dysfunktionen kann man klare Handlungsfelder zur Entwicklung des Teams finden und so seinem Team helfen, sich weiterzuentwickeln.
Diese Seite zeigt dir, wo du wie dieses Modell zur Teamentwicklung in Scrum nutzen kannst.
Weitere Infos zur
Teamentwicklung
Die 5 Dysfunktionen eines Teams von Patrick Lencioni
Patrick Lencioni stellt die fünf Dysfunktionen eines Teams als Pyramide dar, da die einzelnen Dysfunktionen aufeinander aufbauen und sich gegenseitig beeinflussen.
- Ein Mangel an Vertrauen im Team führt zur Vermeidung eines offenen Austausches
- Ohne offenen Austausch im Team lassen sich Konflikte oft leicht vermeiden
- Offene Konflikte im Team führen leicht zur Vermeidung von verbindlichen Absprachen
- Ohne Verbindlichkeit von Absprachen im Team ist es schwer Verantwortung zu übernehmen
- Ohne Übernahme von Verantwortung ist es schwer den Fokus auf gemeinsame Resultate und Ziele zu halten
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Teamentwicklung, Kernaufgabe des Scrum Masters
Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Die Teamentwicklung ist dabei ein zentrales Handlungsfeld eines Scrum Masters, um einem Scrum Team zu helfen effektiver zu werden.
Mehr zu weiteren wichtigen Scrum Master Aufgaben in unserer umfassenden Artikelserie.
Voraussetzung für die 5 Dysfunktionen
Die 5 Dysfunctions of a Team geben uns vor allem einen Anhalt dazu wo wir in der Entwicklung eines Teams stehen und wie wir hier agieren können.
Dabei greift dieses Modell nur, wenn es förderliche Rahmenbedingungen für effektives Teamplay gibt.
Das Team Effectiveness Model, von Richard Hackman, gibt konkrete Anhaltspunkte, welche förderlichen Rahmenbedingungen geschaffen werden sollten.
Ein wirkliches Team
Damit sich eine Gruppe als wirkliches Team zusammenraufen kann, braucht es:
1. Ein klares Verständnis, wer Teil des Teams ist und wer nicht.
2. Eine klare Erwartung zu dem Mass an Eigenverantwortung und Autonomie, aus der diese Gruppe agiert.
3. Eine stabile Zugehörigkeit, in der sich diese Gruppe als Team finden kann.
Ein forderndes Vorhaben
Warum sollten wir als Team eng Zusammenarbeit und Verantwortung übernehmen? Die meisten Teams sehen dazu keine Notwendigkeit und raffen sich entsprechend auch nicht auf, als wirkliches Team zu agieren. Deswegen braucht es ein herausforderndes Vorhaben oder Zielrichtung, aus der man die enge Zusammenarbeit als Team motiviert.
Eine befähigende Struktur
Um als Team gemeinsam Verantwortung zu übernehmen und die Arbeit effektiv anzugehen, braucht es einen befähigenden Rahmen.
Dieser hilft dem Team:
- Sich gemeinsame Arbeitsschwerpunkte vorzunehmen
- Die Arbeit zu koordinieren
- Aus Ergebnissen zu Produkt und Arbeitsweise zu lernen
Scrum sinnvoll ausgestaltet, ist genau ein solch befähigender Rahmen, der so vielen Teams fehlt.
Habt ihr diese Voraussetzungen?
Wenn ihr sie nicht habt, schafft sie. Ansonsten fehlt den vorgeschlagenen Massnahmen aus dem weiteren Artikel das Fundament!
Möchtest du als Scrum Master mehr bewegen?
Die 5 Dysfunktionen übertragen auf Scrum
In diesem Artikel münzen wir die Indikatoren für die 5 Dysfunktionen auf Scrum um und zeigen konkrete Massnahmen für diese Situation auf.
Dieser Artikel ist aus einer gemeinsame CoCreation-Session im August 2020 in einem Community Event entstanden
Heiko Bartlog und ich haben den Rahmen und die erste der 5 Dysfunktionen eines Teams für diesen Artikel als Grundlage für die gemeinsame Erarbeitung dieser umfassenden Ressource geschaffen.
Vom Austausch und Ergebnis dieser Community Session sind wir sehr begeistert und weitere Session, um gemeinsam Themen aufzuarbeiten werden Folgen. Ein besonderer Dank noch einmal an alle Praktikern, die sich in die Erarbeitung dieser Inhalte eingebracht haben und besonders noch einmal an Heiko mit dem es eine unglaubliche Freude war dieses Projekt auf die Beine zu stellen.
Dysfunktion #1 : Mangel an Vertrauen
Ohne vertrauensvolle Offenheit kann eine distanzierte bzw. formalisierte Art der Zusammenarbeit nicht überwunden werden. Wie sollte gutes Teamwork auch gelingen, ohne dass man sich sicher fühlt, wagemutige Vorschläge, neuartige Ideen und kritische Hinweise einbringen zu können?
Die Wichtigkeit von Vertrauen für erfolgreiche Teamarbeit wird oft nicht gesehen. Zusammenarbeit ohne Vertrauen ist natürlich möglich, im Sinne eines Nacheinanders mit klar definierten Schnittstellen und Regeln. Dies ist unseres Erachtens aber weder effizient noch besonders effektiv. Ein lebendiges und mutiges, motivierendes Miteinander gedeiht dagegen auf gegenseitigem Vertrauen. Mit Vertrauen meinen wir keine esoterische Übung sondern den Ausdruck von Verlässlichkeit expliziter und impliziter Vereinbarungen im Team. Dem Soziologen Michael Welch von der US-amerikanischen University of Notre Dame zufolge ist Vertrauen die Basis sozialer Beziehungen – ohne Vertrauen seien keine Kooperationen, keine Handelsgeschäfte möglich. Vertrauen vereinfacht und beschleunigt das Treffen von Entscheidungen. [welt.de 2011] Diese Wirkung kann die Hirnforschung inzwischen sogar “zeigen”. [br.de (Inhalt leider nicht mehr verfügbar)]
Teammitglieder versuchen, eigene Schwächen und Fehler voreinander zu verbergen
- Im “Daily Scrum” werden gar keine oder nur kleine, formale Hindernisse angesprochen und zum Ende des Sprints ist dann aber wiederholt viel weniger fertig geworden als man geplant hatte.
- Man lässt die Anderen erst dann auf die eigene Arbeit schauen, wenn man zu einhundert Prozent sicher ist, dass man wirklich fertig und das Ergebnis perfekt ist.
- In der “Sprint Retrospektive” wird nichts direkt angesprochen und Probleme werden nicht beim Namen genannt.
- Man geht kontroversen, tiefergehenden Diskussionen aus dem Weg, es fallen oft Ausdrücke wie “passt schon”.
- Es sind kaum Pausen des Nachdenkens/Innehaltens zu beobachten.Nicht-Wissen wird nicht zugegeben, man stellt sich bzw. die eigene Meinung und Expertise nicht selbst in Frage.
An dieser Stelle möchten wir betonen, dass die hier und in den anderen Kapiteln aufgeführten Indikatoren nur Anhaltspunkte sind, um Anzeichen für die jeweilige Dysfunktion zu erkennen. Es sind Indizien, keine Beweise. Es kann vielfältige Gründe für das beobachtete Verhalten geben. So kann die Ursache hier ein konkreter Mangel an eigener Kompetenz sein oder der Mangel an Selbstvertrauen oder ein Mangel an Vertrauen in die (soziale) Kompetenz der anderen. Und am Beispiel dieses Indikators wird die mögliche Mehrdeutigkeit besonders greifbar: Denn eventuell handelt es sich bei dem verborgenen Fehler gar nicht um eine Schwäche sondern um eine Chance!
Nach Hilfe fragen oder konstruktives Feedback geben
- Die Aufgaben während des Sprints werden meist von einzelnen Personen abgearbeitet, selten zu zweit oder mit mehreren Teammitgliedern zusammen.
- Im “Daily Scrum” bittet selten jemand um Unterstützung.
- Wenn doch einmal jemand Feedback gibt, endet es meist im Konflikt.
- Teammitglieder investieren lieber mehr Zeit für aufwändige Recherchen bevor sie im Team um Hilfe bitten und damit eine Schwäche zeigen.
- Offene Fragen und kritische Einwände werden im “Sprint Planning” nicht adressiert, was wiederholt zu Problemen während des Sprints führt.
Teammitglieder bieten einander nur ungerne und zögerlich Unterstützung außerhalb des eigenen Verantwortungsbereichs an
- Alle konzentrieren sich auf die eigenen Aufgaben und versuchen sich von anderen Themen fernzuhalten, auch wenn diese im Sprint gerade dringend benötigt werden.
- Wenn doch einmal jemand um Hilfe bittet, wird es ganz ruhig – die anderen Teammitglieder versuchen Augenkontakt zu vermeiden, schauen auf den Boden oder aus dem Fenster.
- Im “Sprint Planning” planen alle nur ihre eigenen Aufgaben.
- Alle konzentrieren sich ausschließlich auf die eigenen Aufgaben, nicht auf den gemeinsamen Plan als Team (z. B. im Sprint Planning, im Backlog Refinement bzw. beim Schätzen)
Teammitglieder ziehen voreilige Schlussfolgerungen über Absichten und Fähigkeiten Anderer
- Vorschläge werden nur selten mit einem “Warum?” hinterfragt
- Es wird generell gerne ausgewichen, wenig diskutiert im Team.
- Oder es wird sehr viel, heftig und konfrontativ über Nebensächlichkeiten diskutiert.
- Man spekuliert lieber über hinter dem Rücken über Absichten anderer Teammitglieder, als miteinander offen darüber zu reden.
- Im Sprint Planning werden Aufgaben direkt passgenau auf die Fähigkeiten der Kolleginnen und Kollegen zugeschnitten, ohne sie zu fragen oder einzubinden.
- Es fallen oft Sätze wie “na, das ist doch etwas für Klaus”, ohne Klaus oder jemand anderen zu fragen
Die Fähigkeiten und Erfahrungen der anderen Teammitglieder werden untereinander weder erkannt, noch anerkannt oder aktiv genutzt
- “Sprint Retrospektiven” fallen aus oder sind nur ganz kurze bzw. rein formale Treffen, ohne echten Mehrwert.
- Alle Versuche, offen über Fehler, Schwächen und Irrtümer zu sprechen und daraus zu lernen, werden nicht angenommen, ignoriert oder ausgebremst.
- Im “Sprint Review” steht mehr das alleinige “ICH” als das gemeinsame “WIR” im Vordergrund.
- Im “Backlog Refinement” geben die erfahrenen Experten den Ton an, Meinungen und Ideen Anderer werden übergangen oder gar nicht erst geäußert.
- Das Team nimmt sich keine Zeit, um untereinander “Danke” zu sagen, um sich gegenseitig Wertschätzung und positives Feedback zu schenken.
Teammitglieder verschwenden Zeit und Kraft, um ihr eigenes Verhalten im Griff zu haben und taktisch einzusetzen
- In Meetings wird wenig bzw. betont sachlich diskutiert, es wird kaum gelacht, selbst die Mimik und Gestik ist reduziert.
- Selbst wenn über offensichtliche Probleme gesprochen wird, wird so lange wie möglich “gute Miene zum bösen Spiel” gemacht.
- Man bleibt so lange wie möglich “in Deckung”, bezieht so spät wie möglich klar Stellung zu kontroversen Themen, um sich nicht angreifbar zu machen.
- Teammitglieder wirken immer beschäftigt, ausgelastet und konzentriert, selbst wenn sie sich eigentlich langweilen.
- Die Kommunikation im Team wird immer mehr durch unverfängliche Floskeln und taktische Standardformulierungen bestimmt.
- Die Kommunikation verlagert sich auf digitale Kanäle, jede Äußerung wird durchdacht, Antworten dauern immer länger.
- Man investiert viel Zeit für die Dokumentation der eigenen Entscheidungen und Vorgehensweise, um sich selbst abzusichern.
- In “Sprint Retrospektiven” werden “Nebenkriegsschauplätze” aufgetan, um nicht über die eigentlichen Themen sprechen und Stellung beziehen zu müssen. Die daraus resultierenden Maßnahmen sind eher oberflächlicher Natur, wenig wertstiftend und werden auch selten angegangen/umgesetzt.
Man hegt Groll untereinander, ohne dies offen auszusprechen und zu klären
- Mitglieder werden von Daily zu Daily ungeduldiger mit den Äußerungen anderer Mitglieder, man fällt sich gegenseitig ins Wort oder rollt mit den Augen, man schaut nebenbei immer öfter aufs Handy etc..
- Man verwendet gerne Verallgemeinerungen und pauschalisierte Vorwürfe (“nie darf ich ausreden”)
- Wenn einmal Lob ausgesprochen wird, dann wird sich nicht wirklich darüber gefreut, weil man es ja eh nicht ernst gemeint haben wird.
- In der Zusammenarbeit wird viel geschwiegen, Gespräche verlaufen oft einsilbig.
- Unverhofft entlädt sich der aufgestaute Groll in lautem Streit über unwichtige Themen und vermeintliche Kleinigkeiten.
Meetings werden vermieden, Teammitglieder finden immer wieder gute Gründe, um möglichst wenig Zeit miteinander zu verbringen
- Teammitglieder ziehen sich zurück, finden immer neue Ausreden, um so selten wie möglich an Teammeetings, insbesondere an Retrospektiven teilzunehmen.
- Aufgaben werden allein erledigt, wenn jemand den Input einer Kollegin oder eines Kollegen benötigt, wird ein Ticket eingestellt, anstatt miteinander zu sprechen.
» Aktivitäten und Maßnahmen
Bevor man als Scrum Master bzw. Agile Coach mit konkreten Maßnahmen loslegt, kann eine Einordnung des Status Quo helfen: Handelt es sich um eine neu zusammengestellte Gruppe oder um ein Team, das bereits seit längerer Zeit so oder so ähnlich zusammenarbeitet? Oder differenzierter: In welcher Entwicklungsphase (z. B. nach Tuckman) befindet sich das Team? Kann man also “auf der grünen Wiese beginnen” und in eine vertrauens aufbauende Forming-Phase investieren? Oder gilt es, in einem bestehenden System neue Reize zu setzen?
Ein Blick in die Vergangenheit kann in jedem Fall helfen: Gab es Vertrauensbrüche oder gar Vertrauensmissbrauch? Im Team und auf individueller Ebene. Und auch auf Unternehmensebene: Öffentliche Betrugsskandale haben Auswirkungen auf die Vertrauenskultur im gesamten Unternehmen! Und umgekehrt: Gab es konkrete Erfahrungen und Erlebnisse mit großem Vertrauen?
Eine erste Möglichkeit, um ein (neues) Team für die Wichtigkeit von Vertrauen für die erfolgreiche Arbeit im Team zu sensibilisieren, ist die gemeinsame Reflexion der 5 Dysfunktionen eines Teams im Kick-off.
Um die gemeinsame Reflexion der 5 Dysfunktionen einzuleiten, bietet sich ein Einstieg mit einer praktischen Übung an, um Teamwork spielerisch erlebbar zu machen.
Auf diesem gemeinsamen Erlebnis kann dann im Team darüber gesprochen werden, was Vertrauen im Team bedeutet. Wer tiefer in die Reflexion der 5 Dysfunktionen einsteigen möchte: Patrick Lencioni bietet auch ein kostenpflichtiges Online Team Assessment an.
Man kann Vertrauen nicht einfordern oder als Scrum Master gar anordnen, man kann Vertrauen schenken und darauf vertrauen, ebenfalls Vertrauen zurück zu bekommen. Wie aber kann ich als Scrum Master mit gutem Beispiel vorangehen und Vertrauen so schenken, dass mein Team das auch bemerkt? Zum Beispiel, indem ich mich verletzlich zeige, indem ich Schwächen eingestehe, um Hilfe bitte und eigene Fehler, eigenes Scheitern offen äußere. (Aber bitte nicht über das Ziel hinausschießen: Mach Dich in Deiner eigenen Kernkompetenz nicht kleiner als Du bist! Schließlich soll man Dir und Deiner Kompetenz als Scrum Master oder Agile Coach vertrauen! Und Dein Verhalten sollte Impulse setzen und nicht komplett verstörend wirken: Kleine iterative Schritte und Experimente, Inspect & Adapt, also agiles Vorgehen ist auch hier angebracht!)
Eine Aufgabe eines Scrum Masters ist es, das Team vor Störungen von außen zu schützen: Dazu gehört auch, Vertrauensunterwanderungen von außen zu verhindern!
Darüber hinaus kann sich ein Scrum Master auch in der täglichen Zusammenarbeit als Vorbild anbieten, indem man bspw. nach getroffenen Absprachen explizit nicht kontrolliert, ob sie auch wirklich eingehalten werden, sondern offen mitteilt, dass man dem Team vertraut! Egal, wie es dann ausgeht, kann das dann ein wertvolles Thema für die nächste Retrospektive sein.
Apropos: Der wahrscheinlich offensichtlichste Ort für den Aufbau von Vertrauen im Scrum Team ist die Sprint Retrospektive. Um den Raum für einen offenen Austausch in Retrospektiven zu schaffen, kann man eine Retrospektive mit einen Safety-Check starten. In dieser Übung sammelt man in einer vertraulichen und ggf. anonymen Umfrage das aktuelle Sicherheitsgefühl der einzelnen Teammitglieder ein und nutzt das Ergebnis als Anstoßpunkt für eine gemeinsame Reflexion darüber, wie man die gefühlte oder tatsächliche Sicherheit im Team verbessern kann.
Elemente einer solchen Sicherheitsabfrage können auch fortlaufend, bspw. täglich, durch die Teammitglieder in Form eines Vertrauens-Barometers gepflegt werden. Wenn man sich dann den Verlauf gemeinsam in der Retrospektive anschaut, kann man über konkrete Ereignisse sprechen, die das Vertrauensempfinden im Team beeinträchtigt (“Vertrauensbrüche”) oder gefördert (“Vertrauensbeweise”) haben, und daraus gemeinsam lernen.
Eine wichtige Grundlage von Vertrauen ist gegenseitige Offenheit! Auch auf persönlicher Ebene. Natürlich ist es nicht notwendig, dass man im Team regelmäßig “Seelenstriptease” tanzt und jedes Team ist da anders. Ein tiefergehender Aspekt ist bspw. die persönliche Verletzlichkeit und inwiefern Gefühle offen kommuniziert werden können. Die folgenden Techniken dienen dazu, sich im Team besser kennenzulernen und so Vertrauen aufzubauen. Sie sind nach “persönlichem Tiefgang” sortiert, beginnend mit Übungen, die eher an der “Oberfläche” kratzen:
- Market of Skills,
- Mittelinventar (Folien 14-19 und 24/25),
- Personal Maps,
- Teamrollen nach Belbin,
- Moving Motivators,
- Influence Maps,
- Persönlichkeitstests (MBTI, DISG, Reiss, TMP, …)
Die hier aufgeführten beispielhaften Techniken sind vor allem Katalysatoren, um sich selbst zu reflektieren und auf dieser Basis miteinander ins Gespräch zu kommen. Sie lassen sich unabhängig voneinander situativ einsetzen oder auch aufeinander aufbauend.
Um im Team offen über eigene Schwächen und Verletzlichkeit sprechen zu können, ist es zudem hilfreich, dass die Teammitglieder ihre eigenen Schwächen selbst schon einmal reflektiert haben, dabei kann ein individuelles Coaching bspw. auf Basis des Johari-Fensters nützlich sein.
Weiterhin kann die Offenlegung der persönlichen Motive, in dem Team mitzumachen und des Nutzens, den man sich davon verspricht (“was habe ich davon?”) sehr helfen, um unterschiedliches Verhalten besser verstehen und so Vertrauen aufbauen zu können.
Noch ein Hinweis: Vertrauen drückt sich auf drei Ebenen aus: Selbstvertrauen, Vertrauen in die anderen und Vertrauen in das System. Wir fokussieren in diesem Artikel auf das Vertrauen in die anderen (im Team). Da allerdings alle drei Aspekte miteinander in Wechselwirkung stehen, kann es durchaus sinnvoll sein, einen Blick auf die beiden anderen Ebenen zu werfen.
Welcher Scrum Master Typ bist du?
Dysfunktion #2: Angst vor Konflikten
Ohne offene Auseinandersetzung können schwelende Konflikte nicht tiefergehend im Team aufgearbeitet und gelöst werden. Wie sollte ein Team blind zusammenarbeiten können, wenn persönliche Bedürfnisse nicht eingebracht, Sichtweisen nicht ausgetauscht werden und Ärger übereinander heruntergeschluckt wird?
Langweilige Meetings
- In den “Retrospektiven” wird ausschließlich über “formale” Punkte gesprochen, nicht über Zwischenmenschliches
- Langgezogene Klärung von belanglosen Themen, statt den Kern zu adressieren
- Es gibt keinen Platz für persönliche Bedürfnisse, Emotionen und Zwischenmenschliches
Das Taktieren hinter dem Rücken anderer und persönliche Attacken stehen an der Tagesordnung oder sind sogar die Regel
- Dem Scrum Master werden in Einzelgesprächen Probleme benannt, die aber im Gespräch mit dem Team nicht zur Sprache kommen.
- Man spricht übereinander, statt miteinander.
- “Retrospektive” ohne PO, da die größten Probleme mit dem PO gesehen werden.
- “Der Elefant im Raum”: Offensichtliche und bekannte Probleme werden nicht angesprochen.
- Der Flurfunk ist merklich / sehr aktiv – der Scrum Master nimmt in der Kaffeepause häufig kritische Diskussionen ÜBER andere wahr
Kontroverse Themen, die für den Teamerfolg entscheidend sind, werden ignoriert
- Außerhalb der Scrum Events wird einfach nur abgearbeitet und kontroverse Punkte und Widersprüche ausgeblendet.
- In Einzelgesprächen werden kontroverse Themen sichtbar, die (auch bei explizitem Nachhaken) in den Scrum Events, insbesondere in der Sprint Retrospektive, nicht auf den Tisch kommen.
- Es werden wenig oder keine klaren Entscheidungen (SMART, mindestens Verantwortlicher und Termin) getroffen, siehe z.B.:9 Stufen der Konflikteskalation nach Friedrich Glasl
- Entscheidungen werden solange ignoriert, bis andere (z. B. Manager) diese treffen (“müssen”). Hinter dem Rücken werden dann diese “schlechten” Entscheidungen infrage gestellt.
- Der PO muss auch Technisches für das Team entscheiden.
- Selbst wenn ein Problem offen angesprochen wird, wird dies von den anderen heruntergespielt
Die unterschiedlichen Meinungen und Perspektiven im Team werden kaum gehört
- In den Meetings reden bzw. schweigen immer dieselben Personen
- Techniken wie Brainwriting und Planning Poker werden abgelehnt oder sogar aktiv sabotiert (durch Dazwischenreden)
Teammitglieder verschwenden viel Zeit und Kraft mit Selbstdarstellung und zwischenmenschlicher Absicherung
- Events werden aufwendig und akribisch vorbereitet, mit klarer Abgrenzung und Ausklammerung von kritischen Themen
- Positive Aspekte werden gerne als persönliche Erfolge vorgestellt
- Für negative Aspekte werden proaktiv Ausreden und Entschuldigungen vorbereitet
- Die weniger kritischen angesprochenen Themen werden aufwendig in Powerpoint-Folien / Bilder verpackt ohne die Kernthemen (unangenehmen Themen anzusprechen und mit Kennzahlen oder anderen harten Fakten zu thematisieren).
» Aktivitäten und Maßnahmen
Idealerweise sollten sich alle im Team um Transparenz und Klärung für Konflikte kümmern. Insbesondere hat aber der Scrum Master bzw. Agile Coach als Moderator/Facilitator in der Sprint Retrospektive die Möglichkeit, Konflikte gezielt anzugehen.Eine gute Basis ist die Erkenntnis, dass Konflikte nicht zwingend negativ sein müssen, sondern auch Chancen bieten, voneinander zu lernen und neues zu entwickeln, solange frühzeitig und offen daran gearbeitet wird, bevor sich der Konflikt zu tief einbrennt und toxisch auf die Zusammenarbeit auswirkt. Es braucht Mut, um Konflikte aufzuzeigen und anzusprechen. Doch je kleiner, unwichtiger, oberflächlicher und frischer ein Konflikt, desto leichter lässt sich darüber sprechen und gemeinsam eine Lösung finden. Diese Erfahrungen kann man dann nutzen, um sich schrittweise tiefergehenden Konflikten zu öffnen, also mutiger zu werden.
- Anhand kleiner Konflikte den konstruktiven und wertschätzenden Diskurs regelmäßig üben/trainieren (z. B. mithilfe von fragenbasierter Kommunikation, Gewaltfreier Kommunikation oder WWW-Feedback)
- Einzelgespräche mit eher konfliktscheuen Teammitgliedern führen und diese ermutigen, Konflikte anzusprechenWenn ich einen Konflikt erahne oder er an mich herangetragen wird, gilt es gut abzuwägen, ob es sich um einen Konflikt handelt, der das ganze Team betrifft und bspw. in einer Retrospektive adressiert werden sollte oder um einen persönlichen Konflikt, der eher in EInzelgesprächen bzw. durch eine erfahrene Mediatorin behandelt werden sollte. Und falls sich der “rosa Elefant” im Raum einfach nicht zeigen möchte dann kann es helfen, Einzelinterviews mit allen Beteiligten zu führen und die Zitate (Mutmaßungen übereinander) dann (anonymisiert) im Team transparent zu machen. Sobald diese Aussagen ihren “Heimlichkeits-Charakter” verloren haben, fällt es viel leichter, darüber zu sprechen.Um mögliche Konfliktpotenziale frühzeitig sichtbar zu machen und Gelegenheiten zur Lösung anbieten zu können, solange es noch frisch und leicht auflösbar ist, ist maximale Transparenz im Team eine wichtige Voraussetzung:
- Kontinuierliches Messen und Aufzeigen der Erreichung der (selbstgesteckten) Ziele
- Kontinuierliches Aufzeigen der Einhaltung der (gemeinsam vereinbarten) Regeln zur Zusammenarbeit im Team, z. B. Aufzeigen der Maßnahmen & Vereinbarungen aus der jeweils vorhergehenden Retrospektive
- In der Moderation nicht mit der ersten Antwort/Lösung zufrieden geben sondern dranbleiben und tiefer gehen und die eigentlichen Ursachen eines Themas (und damit auch das mögliche Konfliktpotenzial) herausfinden: Z. B. mit den 5 Whys oder anderen geeigneten Fragetechniken
- Wenn es um gemeinsame Entscheidungsfindung und Abstimmungen geht, helfen geeignete Moderationstechniken dabei, sämtliche Stimmen und Meinungen (und damit Konfliktpotenziale) transparent zu machen: Z. B. Brainwriting, “Fist for Five”, Planning Poker oder ähnliche Techniken
Und natürlich können gezielte Workshops/Trainings (Konflikte, Kommunikation, Resilienz, …) dem Team helfen, kompetenter mit Konflikten umzugehen.
Hilfreiche Modelle:
- Die 9 Konfliktstufen von Glasel, um die aktuelle Konfliktstufe und jeweilige Phase einordnen und Lösungsoptionen (Win-Win, Win-Lose, Lose-Lose) ableiten zu können
- Das Eisberg-Modell der Kommunikation
- Das Konflikt-Dreieck nach Galtung
Unabhängig davon: Sucht den Austausch mit anderen Scrum Mastern bzw. Agile Coaches z. B. in Form einer Scrum Master Community für gegenseitige Unterstützung und Erfahrungsaustausch.
Was Product Owner tun können:
- Die Priorisierung des Product Backlogs und die Product Roadmap regelmäßig im Team reflektieren, um schon frühzeitig Ängste bezüglich Überlastung und unklarer Zukunft abzubauen. Z. B. im Sprint Planning und Product Backlog Refinement
- Ideenaustausch fördern und alle im Team die Möglichkeit geben, sich regelmäßig daran zu beteiligen
- Den Scrum Master bzw. Agile Coach bei Bedarf um Unterstützung beim Konfliktmanagement bitten
Was alle Team-Mitglieder tun können:
Ich-Botschaften senden: das eigenes Empfinden ausdrücken, ohne den anderen anzugreifen
Dysfunktion #3: Fehlendes Commitment/ Engagement
Der Mangel an Klarheit und/oder die mangelnde Akzeptanz hindert die Teammitglieder daran, gemeinsame Entscheidungen zu treffen, an die sie sich halten.
Das Team verpasst Gelegenheiten/Chancen aufgrund übermäßiger Analyse und übervorsichtigen Zögerns
- Die Definition of “Ready” ist sehr detailliert oder sehr vage
- Product Backlog Einträge durchlaufen das Refinement manchmal sehr oft, bis sie letztendlich komplett verworfen werden, weil die passende Gelegenheit (z. B. Marktchance) verpasst wurde
- Identifizierte Probleme werde von allen Richtungen beleuchtet und analysiert, es werden aber keine Entscheidungen getroffen bzw. Maßnahmen ergriffen.
- Themen werden nicht an das Team gegeben, da man sie im Vorfeld trotz umfänglicher Diskussionen nicht “ausreichend” vorbereitet bekommt.
- Die “User Stories” werden immer ausführlicher beschrieben und mit umfangreichen Anhängen (bis hin zu detaillierten Spezifikationen/Konzepten) ergänzt
- Es werden immer mehr “Spikes” und andere Formen der Vorbereitung künftiger “User Stories” gestartet, um ganz sicherzugehen, dass nichts schief gehen kann.
Zuversicht ist Mangelware, die Angst vorm Scheitern ist in den Entscheidungen des Teams erkennbar
- In der Sprint Planung wird im Zweifel immer eine “User Story” weniger in den Sprint gezogen aufgrund früherer “Fehler” (Abwärtsspirale durch Selbstschutz)
- Im “Daily Scrum” wird ständig angezweifelt, dass das Sprint Ziel ja wieder nicht geschafft werden kann. (Das wird in der Regel im Team akzeptiert und man verharrt in Resignation statt einen Plan zu entwickeln, wie man es doch noch schaffen kann.)
- Maßnahmen in der Sprint Retrospektive werden verworfen mit der Begründung “das bringt ja eh nix” oder “darauf haben wir doch eh keinen Einfluss”.
- Vorschläge etwas neues auszuprobieren oder anders anzugehen werden zerredet oder “auf die lange Bank geschoben”.
- Das gewachsene Softwaresystem wird beklagt, aber man sieht sich nicht in der Lage etwas zu bewegen.
Gemeinsam getroffene Entscheidungen werden immer wieder infrage gestellt und neu diskutiert
- Man trifft Entscheidungen in der Retrospektive und tut sich schwer, diese dann auch anzugehen – alle zwei Wochen dieselben Themen in der Retro, kein Fortschritt
- Getroffene Action- Items haben keine Verbindlichkeit
- Während des Sprints wird die ursprüngliche Schätzung von “User Stories” immer wieder neu diskutiert
- Im Daily gibt es keinen Bezug zum getroffenen Sprint Ziel, oder dieses wird immer wieder in Frage gestellt.
Es besser Wissen ist gelebte Praxis und Teammitglieder ziehen sich gegenseitig in Zweifel
- Wenn eine Argumentation sich später tatsächlich als falsch herausstellt, bekommt diese Person diesen Fakt noch lange Zeit später in ähnlichen Situationen “unter die Nase” gehalten
- Wenn ein Problem nicht mehr “unter den Teppich gekehrt” werden kann, investiert man viel Zeit, um den Schuldigen für den Fehler zu finden, statt für eine gemeinsame Ursachenanalyse und die Ableitung von Verbesserungsmaßnahmen einzutreten.
- In Meetings, Workshops oder anderen Gesprächen fällt man sich oft gegenseitig ins Wort, lässt sich nicht ausreden.
- Kaum eine Äußerung verbleibt ohne eine “ja, aber …”-Reaktion eines anderen Teammitglieds
- Wenn andere Teammitglieder z. B. ihren Beitrag ins Daily Scrum einbringen, machen andere Teammitglieder abwertende Gesten oder Augenrollen.
- Im Backlog Refinement werden Ansichten anderer Teammitglieder zu potenziellen Risiken eingestuft
Im Team herrscht oft Unklarheit über Richtung und Prioritäten
- Es ist unklar was eigentlich im Sprint ist und was Priorität hat
- Man kann sich auf kein Sprint Ziel einigen
- Das Sprint Planning ist vom PO schlecht vorbereitet
- Die Vision ist unklar
- Die Backlog Items haben keine Priorisierung
- Das Sprint Ziel ist nicht definiert
- Im Sprint (Planning) wird häufig zwischen Epics / Themen hin und her gewechselt (z.B. durch den PO)
- Es gibt keine einheitliche Linie in aufeinanderfolgenden Sprints. Themen werden willkürlich bearbeitet
- Experten/Stakeholder kommen zu spät oder sind nicht anwesend, um klare Ziele festzulegen oder Feedback zu geben
- Fehlende, unklare, unvollständige oder nicht präsente DoD, DoR und Working Agreements
- Fehlender Bezug (Austausch, anerkennendes Feedback) von und zur realen Welt (Kunden, Nutzer, Markt, Konkurrenz)
» Aktivitäten und Maßnahmen
Für Scrum Master bzw. Agile Coach stehen vielfältige Ansätze und Möglichkeiten zur Verfügung, um fehlendem Engagement und Commitment im Team zu begegnen, z. B.:
Scrum Events und Meetings
- Klarstellen, dass die Scrum Events nicht für den Scrum Master oder den Product Owner oder für andere Stakeholder stattfinden sondern für das Team und dass das gesamte Team dafür verantwortlich ist, dass die Scrum Events regelmäßig stattfinden, ihren jeweiligen Sinn erfüllen und dafür ständig hinterfragt und optimiert werden: Z. B. mithilfe einer kurzen Feedbackrunde zum Ende eines jeden Scrum Events, um direkt Optimierungspotenziale zu sammeln und konkrete Regeln für eine bessere Durchführung zu vereinbaren.
- Im Product Backlog Refinement, im Sprint Planning gemeinsam reflektieren, inwieweit das Sprint Ziel und die jeweiligen User Stories auf die Product Vision einzahlen.
- In jedem Daily anschauen, wie die jeweilige Aufgabe zum Sprint Ziel beiträgt.
Retrospektiven
- Wenn ich als Scrum Master bzw. Agile Coach den Eindruck habe, dass es im Team an Engagement und Commitment mangelt, kann ich dies in Retrospektiven zum Thema machen bzw. selbst offen ansprechen und meine Beobachtungen schildern.
- Erfolge und Misserfolge dokumentieren und gemeinsam reflektieren, um die Selbstwirksamkeit aufzuzeigen und das Selbstvertrauen zu stärken: auch kleine Erfolge feiern.
- Team-Vereinbarungen (Definition of Ready, Definition of Done und andere “Working Agreements”) dem Team regelmäßig zur Prüfung und Optimierung vorlegen, um Selbstorganisation und Verantwortung als Team bewusst zu machen. Z. B. in Form einer kompakte Abfrage (Ampeln zum Ankreuzen).
Entscheidungsfindung
- Entscheidungsmethoden anwenden, die das Engagement aller Beteiligten fördern (Konsentstatt Konsens, systemisches Konsensieren, verdeckte statt offener Abstimmung, …)
- Gelegenheit bieten, dass jeder einzeln und verdeckt/anonym die eigene Meinung/Priorität einbringen kann – z. B. durch Poker-Techniken (Planning Poker, Value Poker, Delegation Poker, …)
- Gemeinsames Commitment bei kleinen/risikoarmen Entscheidungen üben. Die Furcht vor Entscheidungen dadurch senken, dass die Tragweite reduziert wird: Entscheidungen nicht direkt “in Stein meißeln” sondern als (mutige) Experimente begrenzen und aus den Erfahrungen neuen Mut schöpfen: Good for now, safe enough to try, Done is better than perfect.
- Manchmal kann es sich aber auch lohnen, im Vorfeld von Entscheidungen Worst-Case-Szenarien aufzustellen und diese im Team offen zu diskutieren, um die Notwendigkeit zum Handeln besser zu verstehen
- Je nach Kultur im Unternehmen und Team kann es sinnvoll sein, persönliche Unterschriften und/oder Fotos unter wichtige Entscheidungen zu setzen, als Symbol für ein starkes Commitment
Teamausrichtung
- Team- Vision bzw. Team-Mission bzw. den gemeinschaftlichen Sinn (evolutionary purpose) für das Team und für jeden Einzelnen im Team gemeinsam erarbeiten: Was hat jeder einzelne davon in diesem Team zu arbeiten? Welchen Zweck erfüllen wir als Team? Was würde passieren, wenn es uns nicht mehr gebe? Methoden: Lego Serious Play, Gespräche über die persönlichen Motive (Einzel- und Gruppengespräche vor allem in der Forming Phase), …
- Für möglichst direktes Feedback (Lob, Wünsche und Kritik) der Kunden/Nutzer zur Arbeit des Teams sorgen, mindestens im Sprint Review
Möchtest du mehr über den Scrum Master erfahren?
Auf dieser Seite haben wir alle unsere Informationen zum Scrum Master gebündelt. Hier findest du Antworten zu wichtigen Fragen, vertiefende Podcast-Folgen und aufbauende Artikeln.
Dysfunktion #4: Scheu vor Verantwortung im Team
Das Bedürfnis, zwischenmenschliches Unbehagen zu vermeiden, hindert die Teammitglieder daran, sich gegenseitig für ihr Verhalten und ihre Leistung verantwortlich zu fühlen.
Leistungsstandards führen zu Unmut im Team und zu Vorbehalten gegenüber den anderen Teammitgliedern
- Qualität des Codes, Verständnis, Technische Skills, Technische Schuld, DoD und Akzeptanzkriterien verbessern sich nicht bzw. verbleiben auf einem niedrigen Niveau
- Teammitgliedern wird nicht die Erwartung kommuniziert, dass Sie sich ständig verbessern sollen. Daher decken sie Probleme nicht auf und adressieren diese nicht untereinander
Disziplin entsteht nicht aus dem Team selbst heraus, sondern muss durch die Teamleitung/Vorgesetzten erzeugt werden
- Das Daily Scrum hat Statusreport-Charakter und findet nur statt, wenn Product Owner, Scrum Master oder ein anderer Manager da sind
- Das Team hält sich nicht an die eigenen Regeln und DOD/DOR solange nicht jemand explizit die Aufgabe zugeordnet bekommt, darauf zu achten
- Teammitglieder machen nicht auf das unproduktive Verhalten von anderen aufmerksam
- Teammitglieder geben sich gegenseitig kein konstruktives Feedback
- Teammitglieder stellen Vorgehensweisen von anderen nicht in Frage
- Teammitglieder konfrontieren andere nicht mit Problemen in deren Verantwortungsbereichen
Das Team gibt sich mit Mittelmäßigkeit zufrieden
- Teammitglieder finden es ok, im eigenen Spezialgebiet einfach weiter machen und für sich alleine arbeiten zu können
- Problemstellungen in dem gewachsenen System werden als gegeben angesehen
- Es werden keine Anforderungen und Bedürfnisse im Sprint Review hinterfragt
- Herausfordernde Kundenanforderungen und dynamische Marktentwicklungen werden konsequent ignoriert und ausgeblendet
- Man vergleicht sich gerne mit Teams, die vermeintlich “noch schlechter” dastehen
Wichtige Termine und Key Deliverables werden verpasst
- Das Team führt keine tägliche Forschrittsprüfung (Daily Scrum) durch
- Es gibt keine mittelfristige Releaseplanung/Prognose oder sie ist komplett entkoppelt vom laufenden Product Backlog Refinement und der Arbeit in den Sprints
- Das Sprint Ziel wird selten erreicht, im Sprint Review können häufig wichtige Elemente nicht gezeigt werden
Bonus: Abhängigkeiten werden maximiert
- Der Product Owner formuliert die User Stories (bewusst oder unbewusst) mit Blick auf die Expertisen im Team (“jedem seine User Story”) und verteilt so quasi direkt die Arbeit im Team und alle finden das ok
- Und selbst wenn die User Stories “vertikal” formuliert sind, bricht das Teams sie im Sprint Planning so in Aufgaben herunter, dass jeder in seinem Spezialgebiet allein arbeiten kann
- Das Team delegiert Aufgaben und Entscheidungen gerne an andere Teams/Abteilungen (gerne auch an “Bedenkenträger” und potenzielle „Bremser“) und hat dadurch im Zweifelsfall immer eine “Ausrede” parat, wenn etwas schief geht oder länger dauern sollte
» Aktivitäten und Maßnahmen
Als Scrum Master bzw. Agile Coach habe ich vielfältige Möglichkeiten, um der Scheu vor Verantwortung im Team zu begegnen bzw. entgegen zu wirken, bspw.:
Scrum-Rahmen und -Regeln stabilisieren
- Scrum-Philosophie und -Methodik im Team (insbesondere in den frühen Phasen) mit allen Beteiligten diskutieren und gemeinsam Wege zur Implementierung erarbeiten und dafür gemeinsam die Verantwortung übernehmen
- Vereinbarungen zur Zusammenarbeit im Team (wie Working Agreements, DoR/DoD) gemeinsam erarbeiten, sichtbar machen und immer wieder auf die gemeinsame Verantwortung zur Einhaltung hinweisen, sowie regelmäßig reflektieren, ob die Vereinbarungen so noch passen
- Auswirkungen von fehlender Verantwortungsübernahme und mangelnder Qualität des Produkts transparent machen (mögliche Metriken: Anzahl DoD-Verstöße, Anzahl Bugs, Anteil Refactoring und Abbau technischer Schulden je Sprint, …) und im Team gemeinsam diskutieren, woran das liegt (Ursachenanalyse mit der Hypothese: fehlende Verantwortungsübernahme) und entscheiden, wie das künftig vermieden werden kann
- Wenn TEAM für “toll, ein anderer macht’s” steht, kann es helfen, die Verantwortung für bestimmte Themen einzelnen Personen im Team zu übertragen, als temporäre/rollierende Rolle
- Z. B. kann man die Moderation des Daily Scrums im Team rotieren lassen (jeder nominiert den jeweils nächsten Moderator)
Feedback und Austausch anstoßen
- Transparente Fortschrittskontrolle im Team mit dem Ziel, Zusammenarbeit und gegenseitige Unterstützung zu fördern
- Gemeinsame Team Code Reviews, Pair-Programming, Mob-Programming unterstützen
- Regelmäßiges Peer-Feedback (bspw. Peer-Review aus Sociocracy 3.0) ermöglichen
An der Außenwahrnehmung arbeiten
- Erfolge gemeinsam als Team feiern (z. B. im Sprint Review)
- Krismap erstellen, um herauszufinden, wie das Team nach außen wirkt bzw. wirken soll
Themen, denen wir ausweichen, in den Fokus bringen
- Themen, die im Team vermieden werden, können positiv aufgeladen werden, z. B. durch den gezielten Einsatz von Gamification-Techniken wie Challenges oder das Ausloben und Sammeln von Badges
- Als Scrum Master bzw. Agile Coach haben wir einen Vorteil: Wir können Verhalten beobachten, ohne direkt involviert zu sein. Wenn wir Auffälligkeiten wie unproduktives Verhalten und Scheu vor Verantwortung beobachten, sollten wir das – genauso wie messbare Probleme wie mangelnde Qualität oder häufige Systemausfälle – gezielt in Retrospektiven thematisieren, wenn es nicht von alleine auf den Tisch kommt
- Wenn das Team Schwachstellen/Problemfelder (z. B. lange Laufzeiten von Backlog Items von der Idee bis zur Realisierung) erkannt hat, lassen sich gemeinsam Indikatoren erarbeiten, um den Fortschritt (der durch gezielte Maßnahmen erzielt werden konnte) messen und sichtbar machen zu können
Dysfunction #5: Fehlende Ergebnisorientierung
Das Streben nach individuellen Zielen und persönlichem Status untergräbt den Fokus auf die gemeinsamen Zielsetzungen des Teams.
Es ist keine (positive) Weiterentwicklung im Team sichtbar/messbar
- Impulse zur Veränderung von Arbeitsweisen/Regeln verhallen, der Status Quo wird erhalten
- Es finden kaum Experimente statt
- Das Team hat selbst keine Zielsetzung für die eigene Entwicklung und keine Indikatoren, ob man auf dem richtigen Weg ist
- In den Sprint Retrospektiven werden dieselben Themen über viele Wochen hinweg immer wieder genannt, diskutiert aber nie angegangen oder gar gelöst
Das Team schottet sich gegen das Umfeld ab und ist nicht dazu aufgestellt, mit starken Meinungen von Stakeholdern umzugehen bzw. sich zu behaupten
- Im Sprint Review bleibt man gerne unter sich, Stakeholder oder gar Anwender sind nicht eingeladen.
- Das Team ist nicht sichtbar für Nutzer oder Stakeholder
- Das Team geht jedem Vergleich des Produkts mit anderen Produkten oder dem Nachweis der Nützlichkeit aus dem Weg
- Das Scrum Team ist nicht willens, in einen Dialog über kritische Meinungen von Stakeholdern/Kunden zu gehen.
- Fertige “User Stories” werden nicht oder nur auf Nachfrage im Review gezeigt
- Das Ausliefern fertiger Funktionalitäten an echte Nutzer – und damit das ungeschönte Feedback – wird so lange aufgeschoben wie möglich. (Man nennt die erste Version mit komplettem Funktionsumfang einfach “MVP”.)
- Die Technischen Schulden wachsen stetig an oder werden erst gar nicht gemessen.
- Identifizierte Fehler werden für “später” aufgehoben, aktuell sind die ja noch nicht so wichtig
Teammitglieder konzentrieren sich auf ihre eigenen Karrieren und individuellen Ziele
- Teammitglieder definieren und ziehen sich Aufgaben, die gut zu ihren individuellen Skills bzw. zur persönlichen Skillentwicklung passen statt jene, die erledigt werden müssen, um als Team zu glänzen
- Teammitglieder versuchen in der eigenen Rolle und mit den eigenen Skills zu glänzen und von außen als Experten wahrgenommen zu werden, statt als Team die Entwicklung eines wertvollen Produkts voranzutreiben
- Im Sprint Review möchte jeder “seine” Ergebnisse vortragen und spricht dann meist von “ich” statt “wir”
- Der Stellenwert von Communities of Practice oder ähnlichen sekundären Strukturen und die darin/dafür verbrachte Zeit steigt stetig
- Interne Kommunikationsmedien (Intranet, Chat etc.) werden häufig und gerne zur Selbstdarstellung statt zur Vernetzung und gegenseitigen Unterstützung genutzt
- Teammitglieder orientieren sich im Verhalten immer zuerst an den eigenen persönlichen Zielen aus der Linienorganisation, auch wenn diese den Zielen des Teams oder den Zielen der anderen Teammitglieder widersprechen
Das Team lässt sich leicht von den wesentlichen Zielen ablenken
- Die Produktvision ist nicht präsent und dient weder zur Priorisierung der Backlog Items noch zum Ableiten der Sprint-Ziele.
- Die Ergebnisse der Sprints zahlen nicht auf die Produktvision ein
- Das (Sprint-) Ziel ist entweder nicht existent, beliebig/nichtssagend oder schnell vergessen
- Das Team lässt sich bei Rückfragen, Wünschen und Anmerkungen von Außen leicht und immer wieder vom eigenen (Sprint-) Ziel abbringen
- Es werden (zu) viele Aufgaben gleichzeitig begonnen, eine Limitierung des “Work in Progress” (WIP-Limit) findet nicht statt.
- Teammitglieder nutzen viele Gelegenheiten für Ablenkungen und Arbeit an anderen Themen als jenen vom Sprint Backlog
- Lange und immer wiederkehrende Diskussionen und fehlende Entscheidungsfreudigkeit
- Ein signifikanter (und anwachsender) Teil der Arbeit im Sprint hat nichts mit dem übergeordneten Sprint-Ziel zu tun
- Teammitglieder ziehen neue “User Stories” in den laufenden Sprint, obwohl noch gar nicht alle geplanten “User Stories” fertig sind (der Fokus liegt auf der persönlichen Auslastung statt auf dem Team-Ergebnis)
- Das Ergebnis zum Ende des Sprints ist eine lose Sammlung von Teilgewerken einzelner Experten statt ein integriertes, funktionsfähiges Produkt
Leistungsorientierte Mitarbeiter verlassen das Team oder resignieren
Dieser Indikator spricht aus unserer Sicht für sich selbst und entsprechend haben wir hier keine weiteren konkreten Stichpunkte.
» Aktivitäten und Maßnahmen
Um unsere Arbeit als Team übergreifend an gemeinsamen Ergebnissen auszurichten, benötigen wir ein gemeinsames Verständnis unserer Ziele als Orientierung.
- Produktvision mit allen Beteiligten gemeinsam entwickeln z.B. durch Event Storming Workshop
- Product Owner und Team stellen gemeinsam eine RoadMap auf und konkretisieren diese schrittweise und kontinuierlich. So werden Teilziele (Sprint Ziel, MVP, nächstes Kunden Release) benannt und können sichtbar in Einklang mit dem übergreifenden Ziel gebracht werden.
- User Stories werden ausgerichtet am erlebbaren Mehrwert für den Nutzer geschrieben und stimulieren das Team Fachthemen-übergreifend am orientiert am Nutzen, zusammenzuarbeiten.
- Keine Individual-Boni bzw. Personalziele setzen, sondern Teamziele. Das schafft Anreiz für jeden Einzelnen sich für den gemeinsamen Erfolg einzusetzen.
Im Sprint Planning schaffen wir Klarheit, was wir gemeinsam als Entwicklungsteam im Sprint erreichen wollen:
- Aus dem Ausblick des Produktes (Product Backlog, RoadMap, Product Vision) ein gemeinsames Sprint-Ziel ableiten, diskutieren und sichtbar aufschreiben
- Das Sprint-Ziel als Hypothese formulieren. Wie kann durch das Produkt ein Mehrwert für den Kunden erzeugt werden? Diese These anhand des gelieferten Inkrements nach dem Sprint mit den Nutzern validieren.
- Auswahl der Product Backlog Items im Sprint Planning konsequent aus dem Sprint-Ziel begründen statt sich auf die vorhandene Position zu verlassen.
- Gemeinsamer Task-Breakdown im Entwicklungsteam durchführen
- Bereits in den ersten Tagen eines Sprint ein Inkrement liefern das Wert erzeugt
- Im Team hinterfragen, wie wir es schaffen, (nur) an den möglichst obersten Product Backlog Items zu arbeiten, die den höchsten Wert versprechen ohne uns mit anderen Dingen zu verzetteln
Durch unsere enge Zusammenarbeit im Sprint nutzen wir die Synergien zwischen unseren unterschiedlichen Fähigkeiten und übernehmen gemeinsam die Verantwortung für das Ergebnis
- Um von der Daily Status Runde wegzukommen, die Frage stellen: Welches Ziel / Stories möchtet IHR heute erreicht haben, um für uns einen Erfolg im Sinne des Sprint-Ziels zu erzielen?
- Thumb-Vote am Ende des Daily Scrum “Können wir das Sprint ZIel noch erreichen” um die Selbstreflexion des Teams anzuregen und aktiv Korrekturmaßnahmen zu erwägen.
- Anzahl der parallel zu bearbeitender Elemente im Team begrenzen, damit wir die übergreifende Zusammenarbeit im Team forcieren statt jeden mit seiner Wohlfühl-Aufgabe zu belassen.
- Transparenz über Störungen durch Benennen herstellen, damit diese aufgelöst werden können. Hinterfragen wie wir diese Störungen das nächste mal möglichst automatisiert verhindern können.
Zum Abschluss des Sprints nutzen wir das geschaffene Inkrement als Reflexionspunkt für Ergebnis und Wert.
- Key Value Indikator (KVI) als Kennzahl nutzen, um Wert zu prüfen statt das geschaffene Produkt zu messen. Beim Messen von Produkteigenschaften müssen zumeist Annahmen eintreten, um daraus Nutzen zu ziehen.
- Mit dem Product Owner einen Parking Lot View als Ausblick erstellen und dies zur Einordnung des aktuellen Sprints im Sprint Review nutzen
- Sprint-Ziel gemeinsam mit den Nutzern, Kunden und Stakeholdern aktiv und transparent inspizieren. Diskussionen dazu anstoßen.
- Ergebnisse im Sprint Review werden als Teamleistung vorgestellt.
- Kunden/ User einladen zum Sprint Review und direkten Austausch und Feedback anregen. Feedback sichtbar für alle mitschreiben bzw. auf Zetteln (auch remote möglich) sammeln – so bleibt die Sprache der Anwender 1:1 sichtbar.
- Kunden anregen Strategie- und Marktentwicklungen mit ins Review einbinden und gemeinsam die Auswirkungen auf das Produkt, die Roadmap und Erwartungen diskutieren. Diese Sammlung mit der Product-Roadmap abgleichen.
