Die meisten neuen Scrum Master haben ein grundlegendes Verständnis für ihre neue Rolle. Viele haben eine Schulung absolviert und den Titel Certified Scrum Master erhalten. Wenn ihre Teams sie bitten, als Scrum Master einzusteigen, sind sie oft aufgeregt und begierig. Was sind nun die ersten Schritte um Scrum zu starten. In diesem Artikel zeigen wir eine simple Checkliste mit einfachen Fragen, die die Grundlagen von Scrum abdecken. Bevor man Scrum vertieft, muss man alle Fragen mit ja beantworten.

1.   Die Scrum Rollen besetzen

Scrum Master [link]

Der Scrum Master sorgt dafür, dass der Scrum Prozess zielgerichtet verläuft und aus Dynamik nicht Chaos wird. Er ist sozusagen die Seele des Prozesses und sorgt dafür, daß das Team die Regeln einhölt.

Ist ein Scrum Master vorhanden?

Das Team braucht einen Scrum Master. Dieser ist ein Meister im Umgang mit Scrum. Er muss Scrum so gut kennen, dass er es anderen in Begriffen erklären kann, die sie verstehen, auch wenn sie noch nie etwas über Scrum gelernt haben. Darüber hinaus muss er verstehen, warum Scrum funktioniert, welches Problem jede Rolle, jedes Ereignis und Artefakt löst und warum traditionelle Wasserfallmodelle im Bereich der Lieferung neuer Produkte schlechter sind.

Wie man ein Scrum Master wird liest du im Artikel Karriere als Scrum Master [link]

Entwickelt sich der Scrum Master stetig weiter?

Wie kann man Scrum auf einem Masterniveau verstehen? Lesen, üben und experimentieren. Scrum Master müssen die von Scrum angewandten Prinzipien der kontinuierlichen Verbesserung aufgreifen und auf einer sehr persönlichen Ebene umsetzen. Auch wenn sie einen Kurs besucht haben, lesen sie zunächst den Scrum Guide. Sogar der Scrum Guide selbst ändert sich, um sich kontinuierlich zu verbessern.

Wie man sich als Scrum Master ständig verbessert liest du im Artikel Selbstentwicklung [link]

Product Owner [link]

Die Auswahl eines geeigneten Product Owners ist entscheidend für den Erfolg des Projekts. Diese Person muss sowohl auf Strategie- als auch auf Detailebene, sowohl auf kaufmännischer als auch auf technischer Ebene, auf der Ebene des oberen Managements und des Nachwuchses arbeiten können.

Ist ein Product Owner vorhanden?

Product Owner spielen eine wichtige Rolle in agilen Teams. Schließlich sind sie die Einzigen, die für den Standard der Teamleistung verantwortlich sind. Es ist eine sehr sichtbare Position, da sie auch für die Pflege des Product Backlog und die Information über die aktuellen Anforderungen des Teams verantwortlich sind. Es kann eine schwierige Rolle sein, da die Produkte nicht manchmal unklar definiert sind. Die endgültige Verantwortung, die Arbeit effektiv zu erledigen, liegt direkt bei einer Person. Infolgedessen kann es eine komplizierte Aufgabe sein, wenn es um das Management aller Beteiligten und die Priorisierung von Items geht

Hat der Product Owner die nötige Befugnis?

Unternehmen haben Angst, dem Product Owner zu viel Macht zu geben, was oft damit erklärt wird, dass sie eine falsche Entscheidung treffen können. Scrum garantiert nicht, dass der Product Owner immer korrekte und maßvolle Entscheidungen trifft. Product Owner sind Menschen. Das bedeutet, dass sie Fehler machen können. Einem Product Owner Entscheidungsmacht zu verleihen bedeutet, agiler zu werden. Agil zu sein bedeutet, flexibel zu sein, schnell die Richtung der Produktentwicklung ändern zu können und sich dem Markt anzupassen. Agilität verschafft Unternehmen einen Wettbewerbsvorteil. Um dies zu erreichen, bietet Scrum eine neue Organisationsstruktur, bei der die Schlüsselrolle den Product Ownern zukommt.

Hat der Product Owner das Wissen, um zu priorisieren?

Im Idealfall sollte das Produkt Backlog eine Liste aller produktbezogenen Aufgaben sein, die das Team als nächstes erledigen muss. Die Elemente auf dem Backlog können schnell zu einem Problem werden, weil sie die Liste aufblasen und überladen, was die Überprüfung und Organisation erschweren. Aus diesem Grund ist es so wichtig, das Produkt Backlog zu priorisieren, um sicherzustellen, dass es nicht zu einer offenen Liste zufälliger Gedanken wird, die jemand über das Produkt hat. Das Backlog muss strukturiert, organisiert und arrangiert werden, um die strategisch wichtigsten Dinge zu begünstigen, an denen das Team arbeiten kann.

Wie User Stories geschätzt werden kannst du im Artikel Planning Poker und Value Poker [link] nachlesen

Steht der Product Owner im direkten Kontakt mit Scrum Master, Entwicklungsteam und Stakeholdern?

Bei einem Scrum Projekt ist der Product Owner die Brücke zwischen dem Unternehmen und den Entwicklern. Seine Aufgabe ist es, sicherzustellen, dass sowohl Stakeholder als auch das Scrum Team das bekommen, was sie für ihren Erfolg benötigen. Product Owner müssen lernen, wie sie sich mit dem Scrum Master, dem Entwicklungsteam und den Stakeholdern zusammenschließen können, um einen maximalen Nutzen zu erzielen

Entwicklungsteam [link]

Entwicklungsteams werden von dem Unternehmen strukturiert und befähigt, ihre eigene Arbeit zu organisieren und zu verwalten. Die daraus resultierende Synergie optimiert die Gesamteffizienz und Effektivität des Entwicklungsteams

Ist das Team ein echtes Team?

Teamgeist ist essentiell. Es ist für jedes Mitglied des Unternehmens von entscheidender Bedeutung, das Konzept der Teamarbeit zu verstehen und seinen Job als Teil einer Teamarbeit zu betrachten. Teamarbeit gründet sich auf die Kultur eines Unternehmens. Unternehmen, die eine offene, ehrliche Kommunikation fördern und die Interaktion mit den Mitarbeitern fördern, sind besser in der Lage, eine gute Teamarbeit unter den Mitarbeitern zu haben. Die Schaffung von Möglichkeiten zur ungezwungenen Geselligkeit ist eine gute Möglichkeit, den Teamgeist am Arbeitsplatz zu fördern. Die Suche nach Gelegenheiten für eine Party ist ein guter Ausgangspunkt. Wenn sich der Dezember nähert, könnte die Planung einer Weihnachtsfeier im Büro den Mitarbeitern die Möglichkeit geben, das Eis zu brechen, sich gegenseitig kennenzulernen und engere Teamkollegen zu werden.

Ist das Team selbstorganisiert?

Die Bildung eines selbstorganisierten Teams erfordert eine Bewertung, ob die Teammitglieder selbstständig und selbstgesteuert sein können. Keinen Manager zu haben, ist nicht dasselbe wie keine Führungskraft zu haben. In einem selbst geführten Team zu arbeiten, ist für viele Menschen lohnend. Es erfordert viel Verantwortung, Antrieb, Geduld, Verständnis und Ehrlichkeit, aber die Fähigkeit, seine Arbeit und seinen Erfolg selbst zu gestalten und zu definieren, macht es wertvoll. Wenn ein Unternehmen nicht richtig aufgestellt ist, können selbstverwaltete Teams riskant, herausfordernd und letztlich erfolglos sein. Selbstorganisierte Teams haben eine gewisse Entscheidungsbefugnis und übernehmen die Verantwortung dafür, wie sie funktionieren und sich selbst weiterentwickeln. Sie arbeiten daran, ihre Vision zu verwirklichen und ziehen Aufgaben selbst für sich an. Sie kommunizieren mehr miteinander als mit ihrem ScrumMaster, haben jedoch keine Angst Fragen zu stellen.

Verfügt das Team über alle benötigten Fähigkeiten und Ressourcen?

Das Team muss erforderliche, fehlende oder knappe Fähigkeiten und Ressourcen identifizieren. Hierzu vergleicht man einfach die benötigten Fähigkeiten mit den verfügbaren Fähigkeiten. Hieraus leiten sich Risiken und erforderliche Lernpfade für das Team ab.

Ist der Arbeitsraum agil gestaltet?

Die Gestaltung des Arbeitsraumes ist wichtig. Das Team muss an einem Ort sein, der idealerweise neben einer geräumten Wand liegt, die es als Scrum  Board verwenden kann. Sie sollten auch leicht Zugang zu einem Besprechungstisch oder Raum für Planungen, Retrospektiven und andere Besprechungen haben. Die Tischstruktur sollte die Zusammenarbeit fördern. Eine Idee ist, dass das Team Rücken an Rücken arbeitet, so dass sie einfachen Zugang zu den anderen Bildschirmen haben, indem sie mit ihren Stühle rüberrollen.

2.   Das neue Team schulen

Das Team braucht zunächst einmal ein Grundverständnis von Scrum – die Scrum Basics [link]. Dieses Wissen kann in einem Workshop überliefert werden. Wie man diese gestaltet kannst du im Artikel 10 Dinge die Du mit deinem neuen Scrum Team tun solltest [link] nachlesen. Wenn man es mit der Einführung von Scrum ernst mein, darf man dies nicht überspringen. Ein externer Experte kann helfen, sowohl Teams als auch Interessenvertreter zu schulen. Das Experimentieren Scrum erfordert einen mentalen Wandel, der ohne einen externen Moderator nicht ausgelöst werden kann. Der physische Einstieg in Scrum erfordert eigentlich nur ein paar Haftnotizen und Marker. Hiermit erstellt man ein Scrum-Taskboard. Scrum-Boards sind Haftnotizen, die auf einem Raster angeordnet sind. Die Technik ist praktisch und anpassungsfähig.

3.   Die Scrum Artefakte

In der Archäologie bezieht sich der Begriff „Artefakt“ auf ein Objekt, das von einem Menschen hergestellt wurde. Die lateinischen Wurzeln des Wortes Artefakt übersetzen sich grob mit „Kunstwerk“. Ein Artefakt ist also etwas, das Teams herstellen, entweder ein Werkzeug, das ein Problem löst, oder ein Kunstwerk, das uns inspiriert. Scrum Artefakte liefern wichtige Informationen, die das Scrum Team und die Stakeholder kennen müssen, um das zu entwickelnde Produkt, die durchgeführten Aktivitäten und die im Projekt geplanten Aktivitäten zu verstehen. Folgende Artefakte müssen vom Entwicklungsteam verstanden, erstellt, priorisiert und täglich aktualisiert werden. Dabei müssen sie gut sichtbar und zugänglich sein.

• Product Backlog [link]
• Sprint Backlog [link]
• Impediments Backlog [link]
• User Stories [link]
• Definition of Done [link]
• Burn-down Chart/ Burn-up Chart [link]

Versteht jeder die Inhalte der Artefakte?

Es sollten immer genügend gut analysierte und verstandene Backlog Items vorhanden sein, damit das Team 2-3 Sprints durchführen kann. Bei einem Impediment Backlog muss zum Beispiel der Scrum Master sicherstellen, dass das gesamte Team die Top 1-3 Hindernisse kennt. Er hat eine Strategie, wie man das obere Hindernis beheben kann. Er eskaliert an das Management, wenn das Team nicht lösen kann.

Sind die Artefakte vorhanden?

Zu Beginn der Entwicklung des Produkts werden die Artefakte nur die am besten verstandenen, großformatigen Anforderungen enthalten und sich mit der Zeit weiterentwickeln, wenn neue Informationen verfügbar werden. Diese neuen Informationen stammen aus einer Vielzahl von Quellen – die Entwicklung des Produkts selbst, externe und interne Stakeholder-Inputs, Benutzerfeedback, Marktveränderungen, die Beobachtungen des Entwicklungsteams und vieles mehr…

Werden die Items vom Team geschätzt und nach dem Geschäftswert priorisiert?

Dies kann je nach Komplexität und Größe des Product Backlogs einige Tage oder mehr dauern. Das Team diskutiert und analysiert das Product Backlogs mit dem Product Owner und möglicherweise einigen der Stakeholder und konzentriert sich dabei auf die wichtigsten Punkte. Im Idealfall sollte das Ergebnis dieser Sitzung ein geschätztes Backlogs mit identifizierten Abhängigkeiten sein Die Top-Items müssen genug sein, um in einen Sprint zu passen. Jeder im Team sollte an der Schätzung teilnehmen. Die Schätzung selbst sollte in relativen Größen (Story Points) durchgeführt werden. Das Team sollte damit vertraut sein, Akzeptanzkriterien zu ermitteln, User Stories auszuarbeiten und relative Schätzungen vorzunehmen.

Was man beim Schätzen beachten musst erfährst Du im Artikel Scrum Basics: Planning Poker vs. Value Monopoly [link].

Werden die Artefakte täglich aktualisiert?

Scrum Teams beherrschen die Kunst, sachlich zu sein. Die Überwachung des Fortschritts in Scrum erfolgt in erster Linie durch die direkte Überprüfung des tatsächlichen Inkrements. Sprint Reviews dienen dazu, den Fortschritt in Richtung Sprintziele zu überwachen. Das Entwicklungsteam überwacht die Fortschritte nur, um die Wahrscheinlichkeit der Erreichung des Sprintziels zu prognostizieren, so dass sie sich im Laufe des Sprints entsprechend anpassen können. Dies geschieht ebenfalls, indem sie täglich die tatsächlichen Fortschritte bei der Erhöhung transparent machen. Obwohl sich Scrum Teams möglicherweise an anderen projektiven Praktiken wie Burn-Up/Down-Diagrammen beteiligen, sollte die Verwendung dieser Methoden nicht die Notwendigkeit ersetzen, den tatsächlichen Fortschritt der tatsächlichen Arbeit zu überprüfen.

Sind die Artefakte gut sichtbar und zugänglich?

Obwohl Sichtbarkeit und Zugänglichkeit zur Transparenz beitragen können, heißt das nicht, dass Artefakte sichtbar und für alle zugänglich sein müssen, damit sie transparent sind. Die Teams werden herausfinden, welche Ebenen der Sichtbarkeit, Offenheit und Zugänglichkeit am besten funktionieren, um die Produktion reibungslos und sicher zu gestalten. Eine grundlegende Sichtbarkeit und Zugänglichkeit muss aber für alle Teammitglieder gewährleistet sein.

4.   Die Scrum Events abhalten

Vorgeschriebene Ereignisse werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und den Bedarf an Meetings, die nicht in Scrum definiert sind, zu minimieren. Alle Ereignisse sind zeitgesteuert, so dass jedes Ereignis eine maximale Dauer hat. Sobald ein Sprint beginnt, ist seine Dauer festgelegt und kann nicht verkürzt oder verlängert werden. Die verbleibenden Events können enden, wenn der Zweck der Veranstaltung erreicht ist. Abgesehen vom Sprint selbst, der ein Rahmenevent für alle anderen Events bildet, bietet jede Veranstaltung in Scrum eine Gelegenheit, zu inspizieren und anzupassen. Diese Ereignisse sind speziell darauf ausgerichtet, kritische Transparenz und Inspektion zu ermöglichen. Die Nichtbeachtung eines dieser Ereignisse führt zu einer geringeren Transparenz und ist eine verpasste Gelegenheit zur Inspektion und Anpassung.

•  Sprint [link]
•  Sprint Planning [link]
• iSprint Review [link]
•  Sprint Retrospektive [link]
• Daily Scrum [link]

Nehmen die richtigen Personen an den Events teil?

Das Sammeln von Feedback von den richtigen Personen ist entscheidend, um die richtigen Produktentscheidungen zu treffen: Wenn man die falschen Personen einlädt oder Schlüsselpersonen fehlen, dann ist es unwahrscheinlich, dass man das notwendige Feedback erhält. Dazu können Personen aus den Bereichen Marketing, Vertrieb, Service und Support sowie andere Geschäftseinheiten zählen, je nach Produkt und Organisation. Es ist hilfreich, den Teilnehmern zu erklären, warum man sie einlädt und was sie zu sehen bekommen, um sie zur Teilnahme zu ermutigen und ihre Erwartungen festzulegen.

Haben die Teammitglieder den Zweck der Events verstanden?

Wenn das Scrum Team zusätzliche Meetings abhält, sollte es sich fragen, warum es nicht an einem Event teilgenommen hat und wie das Team dieses Meeting in Zukunft zu einem Teil der Scrum Events machen kann. Damit die Entwicklungsteams mit Fokus und Konzentration arbeiten können, muss man zusätzliche Meetings aggressiv minimieren und nur diejenigen durchführen, die helfen, das Sprintziel zu erreichen. Aus diesem Grund muss man den Zweck der Scrum-Ereignisse deutlich erklären und verstehen. Der Zweck besteht darin, einen klaren Rhythmus und eine klare Fokussierung zu bieten, die unnötigen Aufgabenwechsel verhindert.

Beteiligen sich die Teammitglieder?

Wenn man sich dazu entscheidet, Zeit in eine Scrum-Veranstaltung zu investieren, sollte diese Menschen ermutigen, sich aktiv zu beteiligen. Sie sollen befreit ihre Ansichten, Ideen und Anliegen austauschen. Man muss versuchen zu verstehen, warum jemand ein Produktinkrement mag oder nicht mag. Feedback wie „sieht gut aus“ mag sich gut anfühlen, bietet aber keine neuen Erkenntnisse. Warum mag die Person die Änderungen? Gibt es etwas, das man weiter verbessern kann? Alle Teilnehmer brauchen die Möglichkeit, gehört zu werden. Die Kreativität, das Wissen und das Feedback der Beteiligten sollen helfen, die richtigen Produktentscheidungen zu treffen und das bestmögliche Produkt anzubieten.

Sind die Events timeboxed?

Die Scrum-Events bieten die Möglichkeit zu Transparenz, Inspektion und Anpassung. Diese Ereignisse sind zeitgesteuert, so dass jedes Ereignis eine maximale Dauer hat. Zeitfenster schaffen Konzentration und minimieren Verschwendung. Das Festhalten an der Zeitleiste, obwohl das Ziel des Scrum-Events nicht erreicht wurde, zwingt das Team beim nächsten Mal eine Lösung zu finden.

Werden Maßnahmen abgeleitet und umgesetzt

Teams sollten grundsätzlich mit einer gewissen Anzahl an Maßnahmen aus den Events herauskommen, die sie in der nächsten Iteration tatsächlich schaffen können. Mit kleinen Schritten kann man eine kontinuierliche und nachhaltige Verbesserung erreichen.

Werden Eventziele erreicht?

Man muss das Beste aus den Scrum-Events herausholen. Die Scrum-Events haben klare Ziele:

• Im Sprint Planning wird ein Ziel für den Sprint festgelegt Außerdem wählt das Team die Menge an Arbeit aus die zur Erreichung dieses Ziels erforderlich ist.
• In der Sprint Review sammelt man Feedback von Stakeholdern und stellt fest, welche nächsten Schritte am sinnvollsten sind, basierend auf dem, was während des Sprints gelernt wurde.
• In der Sprint Retrospektive denkt das Team über die Arbeitsweise des vergangenen Sprints nach. Man sollte mindestens eine umsetzbare Verbesserung während des nächsten Sprints sidentifizieren.
• Im Daily Scrum wird ein Tagesplan erstellt. Dieser zeigt auf, wie das Team zusammenarbeitet, um das Sprintziel zu erreichen;
• In Refinement Events, wird das Backlog analysiert und optimiert.

Wenn man die Events so durchführt, dass man diese Ziele erreicht, sollte der Bedarf an Meetings außerhalb dieser Events deutlich sinken. Fortschrittsberichte, Besprechungen zur Überprüfung von Maßnahmen, Besprechungen von Ideengenerationen, Problemlösung, Entscheidungsfindung, Informationsbeschaffung; dies alles kann Teil der Events sein und Raum in der Agenda der Teams schaffen.