view

Sicherstellen, dass die Rollen und Verantwortlichkeiten in Scrum für alle Beteiligten klar und transparent sind?

Ich habe gute Erfahrungen damit gemacht, die Verantwortlichkeiten zwischen Scrum Master, Product Owner und Dev Team gemeinsam zu besprechen.

Ich gehe dabei wie folgt vor: 1. Der Scrum Master erstellt ein Board, das die “Grundeinstellung” in Scrum beschreibt, z.B. Ownership des Product Backlogs oder des Scrum Backlogs. 2. dann werden a.) die Aufgaben konkretisiert, geschnitten oder geteilt und b. gemeinsam diskutiert, um 3. zu einer gemeinsamen Matrix zu gelangen, die als Teamvereinbarung fungiert.

Als Scrum Master ist es besonders wichtig, die Grundeinstellungen des Frameworks im Auge zu behalten und eventuelle Abweichungen zu korrigieren.

Überprüfen Sie diese Vereinbarung regelmäßig und passen Sie sie an ... ;)

Lesen Sie den Artikel von LinkedIn collab hier: https://lnkd.in/ek8STtin.

#Scrum #ScrumMaster #DevTeam #ScrumTeam #TeamAgreement

view

Scrum Events x Meetings

Dieses Thema begegnet mir immer wieder... und es ist immer wieder eine Herausforderung:

• wie gelingt es, “bisherige” und “normale” Meetings in Scrum events aufgehen zu lassen?
• wie gelingt es, Scrum Meetings nicht zu Statusreportings zu degradieren?
• wie gelingt es, der Wahrnehmung entgegen zu wirken, dass Scrum events Zeitverschwendung sind?

Duncan Maddox schreibt dazu auf LinkedIn:

“Scrum sollte Entwickler vor all diesen sinnlosen Meetings bewahren... und nicht noch mehr sinnlose Meetings in ihren ohnehin schon vollen Arbeitstag einbauen.”

🔥 Sie müssen nicht stundenlang eine PowerPoint-Präsentation für Ihr Sprint-Review aktualisieren.

🔥 Sie müssen nicht jede Woche ein anderes, lustiges und überraschendes Thema für die Retrospektive vorbereiten

🔥 Das Daily Scrum ist von den Entwicklern und für die Entwickler

Diese Veranstaltungen sollten andere Meetings ersetzen und nicht überlagert werden.

Und denken Sie daran, dass diese “Timebox” ein Maximum und ein Maximum für einen einmonatigen Sprint ist.

Überprüfen Sie Ihre Pläne und passen Sie sie an.

Überprüfen Sie Ihre Arbeitsweise und passen Sie sie an.

Und dann gehen Sie wieder an die Arbeit.

(Obwohl es natürlich alles Arbeit ist)

#Scrum #Meetings #ScrumEvents

I have had good experiences with discussing the responsibilities between Scrum Master, Product Owner and Dev Team together.

I proceed as follows: 1. the Scrum Master builds a board that describes the “default setting” in Scrum, e.g. ownership of the product backlog or the Scrum backlog. 2. then a.) the tasks are concretized, cut or divided and b. discussed together in order to 3. arrive at a common matrix that functions as a team agreement.

As Scrum Master, it is particularly important to keep an eye on the basic settings of the framework and to correct any deviations.

Inspect and adapt this agreement regularly ... ;)

Read the collab article here: https://lnkd.in/ek8STtin

#Scrum #Responsibilities #ScrumMaster #DevTeam #ScrumTeam #TeamAgreement

view

Nutzt Du “Domain Leadership” als Scrum Master?

Was tue ich als Scrum Master, wenn ich mit “ Servant Leadership” nicht weiter komme?

Eine vollkommen unterschätzte Rolle des Scrum Masters ist die des “Domain Leaders”. Neben dem “Servant Leader” eine der Führungsrollen in Scrum – allerdings eine offensivere.

Wenn Servant Leadership an ihre Grenzen stößt

Der “Domain Leader” sorgt dafür, dass quasi die Diskursethik im und gegenüber dem Scrum Team stimmt. Gibt es beispielsweise Probleme mit notorisch störenden Charakteren (bis hin zu Saboteuren), kann diese Führungsrolle auch Menschen zeitweise von Events bspw. ausschließen, oder Auflagen formulieren, die in der “Domäne” des Scrum Teams vereinbart sind.

Bis hin zum Entfernen von Personen aus dem Scrum Team.

Als Tool nutze ich gerne “Team Agreements”, die auch beinhalten, dass es Sanktionen geben kann, wenn sich nicht an gemeinsame Vereinbarungen gehalten wird.

#Scrum #ScrumMaster #Leadership