Ich bezeichne mich als SCRUM-Magier. Ich begleite Teams von bis zu sieben Mitgliedern als SCRUM Master und steigere ihre Produktivität um das 3- bis 8-Fache – je nachdem, welche Voraussetzungen das Team bereits hat, bezogen auf die Mitglieder und das Unternehmensethos. Das gesamte Unternehmen profitiert davon, denn ein solches Team wird zum Führungsträger innerhalb der Organisation.

Ich bin ein SCRUM Magiker seit vielen Jahren. In vielen Firmen und Situationen. Das Problem ist das grundsätzliche Verständnis von SCRUM. Vor allem bei Vorgesetzten und Ownern der Organisation.

In erster Linie ist SCRUM ein Demokratie Element für die Firma, die Abteilung. Das wird leider oft völlig missachtet. Also die Arbeitslast von einem Sprint muss von den Mitgliedern und zwar von Allen selbst bestimmt werden. Ein Produktmanager (und weiter oben) oder so darf die Richtung bestimmen, die nächsten Schritte, aber niemals ob der Umfang für den Sprint korrekt ist und mit der Life Balance übereinstimmt. Das bestimmen die Mitglieder welche die Arbeit machen im Team. 

Im Team deshalb weil sie als Team eine höhere Macht entwickeln und Life Balance zerstörende Auftragslast abwehren können. Es ist ein heiliger Grundsatz wo die Macht der Definition liegt, was in dem nächsten Sprint zu schaffen ist und was nicht. Das liegt alleine bei den Teammitgliedern welche die Arbeit machen.

Wenn das nicht korrekt gehandhabt wird und funktioniert fällt die grundsätzliche SCRUM Idee in sich zusammen und es wird zu einem Stress Tool um die einzelnen Teammitglieder perfekt unter Druck zu setzen. Auch die Dynamik was SCRUM auslösen kann wird so massiv begrenzt, bzw. zerstört.

Andererseits, wenn das echte SCRUM in seinen demokratischen Funktionen in der Firma aufrechterhalten wird, kann es zu einer guten Life-Balance aller Teammitglieder kommen und auf lange Sicht sind solche Teams dann sogar deutlich produktiver. Das ist meine langjährige Erfahrung, ohne Ausnahme.

• Die Tasks müssen beim Sprint Planing auf maximal 6h heruntergebrochen werden 
• • Wer da sagt, es gibt längere Aufgaben/Tasks, welche man nicht teilen kann, der zeichne einfach mal die tägliche Arbeit so ein langer Aufgabe, begleitend zur Arbeit daran, auf. In ein-zwei Sätzen pro Tag beschreiben was man effektiv gemacht hat. In der Retrospektive wird dann ersichtlich, was die Task gewesen wären, wie die Aufgabe/Task gesplittet hätte müssen
  • Der Effekt ist, dass alle sich genauer die Aufgaben vorstellen müssen und durch die Erfahrung auch immer besser wissen, was eine Aufgabe wirklich im Detail bedeutet
  • Im Team kommt die gegenseitige Erkenntnis dazu. Zum Beispiel, es wird bekannt wer sicher immer unter- oder überschätzt. Unverhofft kommen Cross-Erfahrungen der anderen zum tragen. So sammelt sich das Knowhow zu immer mehr Wissen für die Firma
• Ein Arbeitstag hat 6 Stunden. Ein Halbtag max. 4 Stunden
• • Der Mensch arbeitet an einem 8Stunden Arbeitstag nie 8 Stunden produktiv.
  • Beim Schätzen der Arbeit gehen wir aber davon aus, dass wir produktiv arbeiten.
  • 6 Stunden Tage (3 Story Points) sind nach meiner Erfahrung ein Wert der kein Stress auslöst. Zusätzlich etwas erledigen, darf man/frau ja sowieso
• Ein Story Point hat den Wert von 2h. Das heisst, es gibt keine Aufgaben die kleiner sind. Gibt es diese, werden sie sinnmässig zusammengefasst/aufgezählt
• Das heisst, dass am Sprint Start alles was man im Sprint plant Tasks sind welche 1, 2 oder 3 Story-Points hat.
• • Während des Prozesses
• Schätzen einer Aufgabe erfolgt immer mit allen Entwicklungsteam Mitgliedern (Planing POKER). Auch Lehrlinge !

• Die Personen welche in SCRUM nun Product Owner sind, haben in agilen Projekten klar weniger Macht. Es ist darauf zu achten, dass die Product Owner die Rollendefinition ernst nehmen
• Product Owner sollen beim Sprint Planing dabei sein: 
• • Das ist der Moment, wo sein Backlog-Point vom Team bewertet, umdefiniert und in Sprint- und Teammitglied gerechte Aufgaben gesplittet wird. Er soll das Verstehen
  • Userstory, Alles was der Produkt Owner schreibt, sind eine Sicht vom Kunden aus. Diese Sicht ist etwas welche der Product Owner beherrscht (beherrschen muss). Das ist auch wichtig, denn Entwicklungsteams sind diese Sicht nicht gewohnt
  • Praktisch immer wird beim herausfinden der zu einer User Story Tasks klar, dass diese Kundensicht nicht klar genug definiert ist. Damit das Team nicht einfach Annahmen macht, ist der Produkt Owner da, welcher wie ein Kunde denkt 
  • • Oft ergibt sich auch, dass der Product Owner beauftragt wird beim Kunden noch etwas zu einer Userstory nachzufragen
  • Empfindet der Product Owner es als notwendig/hilfreich, soll er angekündigt (das Entwicklungs-Team weiss Bescheid) einen Stakeholder einladen
  • • Niemals mehr als einen Stakeholder. Sonst könnte die gesammelte Macht das Entwicklungsteam zum nachgeben bewegen und somit so zu falschen Entscheidungen
    • Die Stakeholders sind noch mehr Macht gewohnt. Es sollen nur solche eingeladen werden, welche ihre Rollendefinition kenn und ernstnehmen
    • Entscheidungen werden bei Anwesenheit eines Stakeholders nicht gemacht, oder diese Sitzung wird anders benannt und ist nicht das Sprint Planing sondern eine vorbereitende Sitzung.
    • Der Einbezug von Stakeholdern ab und zu, jeder zehnte Sprint oder so, ist sehr wertvoll, denn so versteht der Stakeholder das Funktionieren des Entwicklungsteams und sein fachliche Brillanz

Ein SCRUM-Master ist eine zentrale Figur im SCRUM-Team, die dafür sorgt, dass das SCRUM-Framework effektiv umgesetzt wird. Hier sind einige der Hauptaufgaben, Rechte und Pflichten eines SCRUM-Masters:

Stand-up-Meetings (Daily SCRUM): Der SCRUM-Master leitet die täglichen Stand-up-Meetings, bei denen das Team den Fortschritt bespricht und Hindernisse identifiziert

Iterations-/Sprint-Planungsmeetings: Der SCRUM-Master schützt das Team vor Überlastung und Scope Creep. Er unterstützt bei Schätzungen und hilft beim Erstellen von Sub-Tasks

Sprint-Reviews: Der SCRUM-Master nimmt an diesen Meetings teil und erfasst das Feedback. Dabei geht es darum, das entwickelte Endergebnis zu präsentieren

Retrospektiven: Der SCRUM-Master notiert Verbesserungsmöglichkeiten und Aufgaben für künftige Sprints. Ziel ist es, den Arbeitsablauf des Teams kontinuierlich zu optimieren

Board-Administration: Als Administrator des SCRUM-Boards sorgt der SCRUM-Master dafür, dass die Karten aktuell sind und das SCRUM-Tool (z. B. Jira Software) reibungslos funktioniert

Meetings unter vier Augen: Bei Bedarf hält der SCRUM-Master persönliche Meetings mit einzelnen Teammitgliedern und Stakeholdern ab. Dabei können Unstimmigkeiten im Team über Prozesse und Arbeitsstile ausgeräumt werden

Interne Beratung: Der SCRUM-Master stimmt sich mit Teammitgliedern und internen Stakeholdern über die optimale Zusammenarbeit mit dem SCRUM-Team ab

Der SCRUM-Master ist ein Wegbereiter, der das Team durch das SCRUM-Framework leitet und begleitet. Er fungiert als Coach und Servant Leader, der die agilen Prinzipien und Best Practices von SCRUM verinnerlicht hat und gleichzeitig flexibel bleibt, um den Team-Workflow zu verbessern

• Gemäss einem Projektleiter bestimmt der SCRUM Master die Mitglieder des ausführenden Entwicklung SCRUM-Teams. Er kann also Leute einladen und ausladen. Also beispielsweise Leute entfernen, welche nicht nach SCRUM Regeln zu arbeiten bereit sind
• Das betrifft auch die Produkt-Owner. Produkt Owner welche nicht nach den SCRUM Regeln zu arbeiten darf er ausschliessen
• Stakeholder müssen anfänglich eine Vereinbarung unterschreiben, wo sie sich bereit erklären den SCRUM-Masters gemäss einem Projektleiter einzusetzen

Ein Product Owner ist eine zentrale Figur im SCRUM-Team, die für die Wertmaximierung der Produkte verantwortlich ist, die vom Entwicklungsteam erstellt werden. Hier sind einige der wichtigsten Aufgaben und Verantwortlichkeiten eines Product Owners

• Vertretung der Interessen des Kunden: Der Product Owner agiert als Stellvertreter der Stakeholder, Kunden und Geschäftsführung. Die Hauptaufgabe besteht darin, den Wert zu maximieren, den das Team durch die geschaffenen Produkte generiert. Dieser Wert kann sich aus der Nutzung der Produkte durch Kunden oder aus Kosteneinsparungen und Prozessverbesserungen ergeben.
• Zusammenarbeit mit dem Entwicklungsteam und dem SCRUM-Master: Der Product Owner legt fest, was getan werden muss, während das Entwicklungsteam autonom entscheidet, wie dies umgesetzt wird. Die Trennung zwischen “was” und “wie” kann für den Product Owner ungewohnt sein, da er zuvor möglicherweise als Projektleiter tätig war. Dennoch ist es wichtig, dass die Entscheidungen respektiert werden und die Richtung klar bleibt.
• Verwaltung des Product Backlogs: Der Product Owner erstellt und pflegt das Product Backlog. Dies umfasst die Priorisierung der Aufgaben, das Hinzufügen neuer Anforderungen und das Entfernen veralteter Elemente. Ein effektiv verwaltetes Backlog ist entscheidend für den Erfolg des Teams.
• Präsentation der Fortschritte: Der Product Owner nimmt an Sprint-Reviews teil und präsentiert den Stakeholdern den erreichten Fortschritt. Dies ermöglicht eine kontinuierliche Abstimmung und Anpassung der Produktvision.
• Entwicklung einer Vision des Endprodukts: Der Product Owner formuliert eine ganzheitliche Vision für das Produkt. Diese Vision dient als Leitfaden für das Team und hilft, einheitliche Ziele zu setzen und den Fokus zu wahren.

Der Product Owner ist somit ein Schlüsselspieler im agilen Entwicklungsprozess, der die Balance zwischen Kundenbedürfnissen, Geschäftszielen und technischer Umsetzung herstellt

Das Entwicklungsteam ist eine zentrale Rolle im SCRUM-Framework. Hier sind die Aufgaben, Rechte und Pflichten der Mitglieder des Entwicklungsteams:

• Aufgaben des Entwicklungsteams:
• • Das Entwicklungsteam arbeitet gemeinsam an einem Teil eines Projekts oder Produkts während eines Sprints.
  • Es ist ein selbst organisierendes Team, das für sein Arbeitsergebnis verantwortlich ist.
  • Das Team entscheidet, wie viel Arbeit es aus dem Product Backlog übernimmt und wie die Aufgaben erledigt werden.
  • Während der Sprint-Planung wählt das Entwicklungsteam die Backlog-Elemente aus, die es im nächsten Sprint bearbeiten wird.
• Rechte des Entwicklungsteams:
• • Das Team hat das Recht, seine Arbeit selbst zu organisieren und zu bestimmen, wie die Aufgaben erledigt werden.
  • Es kann Anforderungen aus dem Product Backlog ändern oder hinzufügen, um den Wert des Produkts zu maximieren. Nur unter Beteiligung des Teams und während einer SCRUM Sitzung
• Pflichten des Entwicklungsteams:
• • Das Team ist verantwortlich für die Qualität seiner Arbeit und die Einhaltung der Definition of Done.
  • Es passt seinen Plan täglich an das Sprint-Ziel an und arbeitet eng mit dem Product Owner zusammen.
  • Das Entwicklungsteam ist multidisziplinär und besteht aus Fachleuten verschiedener Bereiche, die gemeinsam zum Erfolg des Produkts beitragen.

Insgesamt trägt das Entwicklungsteam die Verantwortung für die Umsetzung der Produktanforderungen und die Schaffung von Mehrwert für die Kunden.