Inhouse-Schulung Scrum

Bei der „Inhouse-Schulung Scrum“ wird das Scrum-Framework praxisnah ohne den Einsatz von Powerpoint, dafür mit Whiteboard, Flipchart und Post-Its vermittelt. So entsteht ein vollkommen interaktiver Workshop, der die SCRUM-Inhalte nicht nur theoretisch erklärt. Sie werde mit einbezogen in den Workshop und können so die Arbeitsweise eines SCRUM-Teams hautnah erleben.

Maßgeschneiderte Inhalte

Die Inhalte können Sie selbst steuern – die Inhouse-Schulungen werden auf Ihre Bedürfnisse hin abgestimmt. Auch der Zeitplan und die Dauer der Schulungen richtet sich nach Ihnen und Ihren Mitarbeitern. Möchten Sie lieber früh am Morgen beginnen oder den Workshop gar auf ein Wochenende legen? Gar kein Problem! Wir richten uns ganz nach Ihnen.

Agile Raumbelegung

Wenn Sie keinen Raum für die Schulung zur Verfügung haben, dann unterstützen wir Sie bei der Suche nach einem optimalen Raum. Dies kann bei Ihnen in der Umgebung sein oder auch weiter weg. Dann können Sie die Inhouse Schulung Scrum gleich mit einem Firmenausflug kombinieren. Auf Wunsch bringen wir sogar eigenes Meeting-Equipment mit.

Teilnehmerkreis für Inhouse Schulung SCRUM

Die Inhouse-Schulung Scrum eignet sich für Scrum Master, Scrum Development Team-Member, Product Owner, Führungskräfte, Projektleiter, Produktmanagern und Business Analysten. Sie richtet sich an alle, die Scrum selbst einsetzen (werden) oder die in Kontakt mit Scrum-Teams stehen.


Sie sind sich unsicher, ob eine Inhouse Schulung das ist, was Sie suchen? Nutzen Sie unser Angebot und vereinbaren Sie einen kostenlosen Telefontermin zur Erstberatung.

Der Termin zur Erstberatung ist für Sie kostenlos. Wir werden gemeinsam eruieren, ob Ihnen eine Inhouse Schulung weiterhilft und welchen Bedarf Sie genau haben. Sie werden am Telefon keine weiteren Verpflichtungen eingehen müssen.

Sofern Sie sich eine Inhouse Schulung mit uns vorstellen können, werden wir im Anschluss ein auf Sie zugeschnittenes unverbindliches Angebot erstellen, dass Sie per E-Mail erhalten werden.

Sie möchten direkt ein Angebot ohne vorherige Beratung? Auch das ist natürlich möglich. Ein paar Informationen zu Ihrem Vorhaben benötigen wir allerdings. Nutzen Sie dazu bitte unser Kontaktformular: https://agile-pm.de/kontakt/

LeSS Lego Scrum

In meinem letzten Workshop Agiles Projektmanagement am Beispiel von Scrum an der VHS Wiesbaden habe ich das Lego Scrum-Spiel erweitert, so dass es zwei Teams mit einem gemeinsamen Backlog gegeben hat, die zusammen einen Zoo gebaut haben. Die Teams haben dabei das LeSS-Framework eingesetzt, um skaliert arbeiten zu können.

Ich denke, dass sich die Ergebnisse sehen lassen können. 😉

Was ist Less?

Mit Hilfe von LeSS gelingt es mehreren Teams parallel an einem Backlog arbeiten zu können. In der Übung gab es zwei Teams mit einem gemeinsamen Product Owner.
Das Sprint Planning 1 haben beide Teams gemeinsam mit dem Product Owner durchgeführt. Beim Sprint Planning 2 hingegen agierten die Teams eigenständig.
In der anschließenden Iterationsphase und den Daily Scrums waren die Teams jeweils unter sich und haben sich erst zum Sprint Review wieder zusammengefunden.
Die Sprint Retrospektive hat wieder jedes Team für sich alleine durchgeführt.

Als Besonderheit gab es neben einem Product Owner auch nur einen Scrum Master, der zwischen den beiden Teams hin und her wechseln musste.

Die Spieldefinition

Rahmen:

  • einfacher Workflow (Sprint Planning, Daily, Sprint Review, Sprint Retrospective)
  • keine Schätzungen durchführen
  • mehrere Teams mit gemeinsamen Backlog
  • je 2 Teams ein Scrum Master
  • 1 Product Owner

Zeiten:

  • Sprint Planning 3 Minuten
  • Daily Stand-up alle 3 Minuten für jeweils 1 Minute
  • Sprint Review 5 Minuten
  • Sprint Retrospektive 2 Minuten
  • 3 Sprints a 7 Minuten

Ablauf:

  • zwei Teams (od. mehr) erstellen und Arbeitsbereich einrichten 5 Minuten
  • Projektbekanntgabe 10 Minuten
    • Teams arbeiten an gemeinsamen Ziel
    • das Projekt heißt „Zoo“
    • Hauptmaterial ist Lego, anderes Material ist zugelassen
  • Backlog erstellen 15 Minuten
    • auf Flipchart die vorher erstellen Stories hängen und erklären
    • Rückfragen klären
  • Durchführung der Sprints 55 Minuten

Sprint 1 (19 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW -> RETRO

Sprint 2 (19 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW -> RETRO

Sprint 3 (17 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW

Retro anschließend (10 Minuten):

  • wie fühlt es sich an, in einem Scrum-Team zu sein?
  • wie liefen die Sprints?
  • was würde geändert werden, wenn das Spiel nochmals gespielt werden würde?
  • was waren die Aufgaben des PO?

Die Spieldauer wird in etwa 95 Minuten zzgl. Pausen betragen.

Agiles Projektmanagement mit Scrum

Der Ansatz des agilen Projektmanagements lässt sich sehr gut mit Scrum kombinieren. Die Rollen, Meetings und Verantwortungen aus Scrum werden dabei 1 zu 1 übernommen. Allerdings ergänzen wir Scrum mit Werkzeugen aus dem agilen Projektmanagement und nehmen das Project Inception und die Projektbeauftragung hinzu.

Der Scrum-Zyklus verändert sich ein wenig uns sieht wie im folgenden Beispiel aus:

Vision

Der Auftraggeber (z.B. CEO, Marketingchef, externer Kunde) hat eine Produktvision und kommt mit dieser Vision zum Projektteam, um über die Machbarkeit zu diskutieren.

Project Inception

Es wird ein erstes Projektteam gebildet, z.B. aus Scrum Master, Product Owner und einem oder zwei Entwickler mit genügend Wissen für eine erste Analyse der Vision.
Die Vision wird näher betrachtet und das Projektteam fertigt ein Project Inception an. Mit dem Auftraggeber werden Rahmenbedingungen wie die Priorität von Umfang/Qualität/Budget/Zeit bestimmt und eine erste Generierung der Backlog Items geschieht. Je nachdem in wie weit der Kunde in den Prozess mit eingebunden werden kann (und möchte), wird entschieden, ob in dieser Phase bereits eine umfangreiche Aufwandsschätzung zu erfolgen hat. In dem Fall wird bereits frühzeitig das Projektteam erweitert, so dass die Aufwandsschätzung von den Team-Mitgliedern durchgeführt wird, die an dem Projekt auch arbeiten werden.
Sobald die Rahmenbedingungen für das Projekt festgelegt worden sind, erfolgt eine schriftliche Genehmigung des Projekts durch den Auftraggeber. Dies stellt den Startschuss für das Projektteam dar.

Backlog füllen

Die erste Aufgabe wird es sein, das Backlog mit weiteren Backlog Items zu füllen. Das Team wird sich dabei zunächst auf der Ebene von Master Stories bewegen und nur nach und nach die User Stories dazu erstellen.
Das Füllen wird in einem oder mehrere Sprints durchgeführt. Dazu werden vor allem SPIKES angewendet, um eine Analyse der Requirements durchzuführen.

Vorbereitung zu Sprint 1

Im Rahmen des Füllens des Backlogs wird auch der erste Sprint vorbereitet. Dazu werden die User Stories identifiziert, die für den Projektstart erforderlich sind und bereits detaillierter beschrieben und geschätzt. Umso mehr User Stories zur Wahl für Sprint 1 stehen, desto besser. Allerdings sollte auch diese Phase zeitlich begrenzt sein, um nicht zu viel Zeit auf die Planung anzuwenden. Die weitere Planung wird im Laufe der Projektumsetzung parallel zur Entwicklung des Produktes erfolgen.

Der Sprint-Zyklus beginnt

Ab jetzt arbeitet das Scrum-Team wie gewohnt an den User Stories aus dem Product Backlog. In den Estimation Meetings werden nach und nach die noch nicht als User Stories heruntergebrochenen Master Stories besprochen und User Stories generiert sowie geschätzt.

Parallel dazu: die Roadmap

Während das Scrum-Team mit Sprint 1 beginnt, wird der Product Owner die bereits zur Verfügung stehenden Master Stories in die Roadmap und einen Releaseplan übertragen. Beide Pläne werden im Sprint-Zyklus kontinuierlich aktualisiert.

Das Produkt entsteht inkrementell

Das Scrum-Team hat weiterhin das Ziel, am Ende jedes Sprints einen releasbaren Stand des Produktes zu haben. Im Projekt werden neue Releases allerdings anhand des Releaseplans abgebildet, weshalb sich das Release am Sprintende vermutlich auf eine neue testbare Version beschränken wird. Vielleicht hat das Team ein Demosystem für den Auftraggeber aufgesetzt, auf das am Sprint-Ende der jeweils aktuelle Stand eingespielt wird.
Sobald das Projekt abgeschlossen ist, bekommt der Auftraggeber das fertige Produkt ausgeliefert.

Dank vieler Releases in der Zwischenzeit und kontinuierliches Feedback durch den Auftraggeber, wird das Produkt am Ende keine Überraschung für den Auftraggeber sein und ein für Scrum-Team und Auftraggeber zufriedenstellendes Ergebnis darstellen.

Die Aufgaben von Scrum Master und Product Owner

Wenn Scrum oder andere Prozesse in einem Unternehmen eingeführt werden, dann ist es sehr hilfreich, wenn die Rollen klar definiert werden. Es muss klar herausgestellt werden, wer für was verantwortlich ist und zu wem jemand gehen muss, um eine(n) Lösung/Antwort/Denkanstoß zu erhalten. In Scrum gibt es im Wesentlichen drei Rollen: Scrum Team (oder auch Scrum Developer genannt), Product Owner und Scrum Master.
Hier eine kurze Auflistung der Aufgaben von Scrum Master und Product Owner, die typischerweise von diesen Rollen übernommen werden.

Product Owner:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budger-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Scrum Master:

  • sorgt dafür, dass Scrum funktioniert
  • setzt sich für die Organisationsentwicklung ein
  • hilft bei der Organisation im Team
  • führt eine kontinuierliche Prozess-Optimierung durch
  • stimmt sich mit anderen Scrum Mastern ab
  • sorgt für die Abstimmung mit anderen Teams
  • pocht auf Regeln und Meetings
  • unterstützt den Product Owner bei Bedarf
  • moderiert Meetings
  • Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)
  • Bindeglied zum Product Owner
  • das gute Herz des Teams
  • fordert Dokumentation ein und erstellt ggf. Meeting Minutes
  • beseitigt Hindernisse (und deckt sie ggf. auf)
  • beschafft Informationen/Räume/Material