---

Die Scrum-Master-Zertifizierung bezahlbar machen: Schritt-für-Schritt-Plan

Wir freuen uns, dass dieser Artikel vorgestellt wurde …
HIER auf LinkedIn >>>

Seit das Scrum-Rahmenwerk zu einer der besten Möglichkeiten geworden ist, Software zu entwickeln und zu liefern, scheinen alle dasselbe Ziel zu haben.

Morgens aufwachen, den Laptop öffnen und die begeisternde Gewissheit genießen, so etwas zu besitzen:

Eine Scrum-Master-Zertifizierung.

Das ist doch der Traum, oder?

Hervorragende Software für Ihre Arbeitgeber und Kunden liefern.

Eine großartige Karriere aufbauen, getragen von Ihren Fähigkeiten und Ihrem Wissen im Scrum-Prozess und Ihrer Scrum-Master-Zertifizierung.

Für die meisten Menschen beginnt der Einstieg in das Scrum-Rahmenwerk mit der Scrum-Master-Zertifizierung.

In diesem Artikel möchte ich erstmals einen ausführlichen und detaillierten Leitfaden mit Ihnen teilen, der Ihnen Schritt für Schritt hilft, Ihre Scrum-Master-Zertifizierung zu erwerben.

Kostengünstig, schnell, online und unkompliziert!

In nur vier einfachen Schritten werden Sie zu einer hervorragenden Scrum-Fachkraft mit Ihrer Scrum-Master-Zertifizierung.

Mit diesem Artikel möchte ich Ihnen zeigen, wie Scrum Ihre Karriere unterstützen und Ihre berufliche Wirksamkeit verbessern kann. Außerdem erfahren Sie, warum Sie die Fähigkeiten eines Scrum Masters lieber früher als später weiterentwickeln sollten.

Definition: Was ist die Scrum-Master-Zertifizierung?

Die beste Definition dessen, was Scrum-Master-Zertifizierung ist, finden Sie auf International Scrum Institute™von Scrum Master Accredited Certification™.

Die Scrum-Master-Zertifizierung ist der Nachweis Ihrer Kompetenz im Scrum-Prozess für Softwareentwicklung und Lieferung. Die Scrum-Master-Zertifizierung bestätigt Ihr nachgewiesenes Wissen und Ihr hervorragendes Fachwissen im Scrum-Rahmenwerk nach einer formellen Bewertung durch einen Multiple-Choice-Test.

Der Scrum-Softwareentwicklungsprozess hat bis heute Millionen von Fachkräften enorme Vorteile gebracht. Es gibt daher keinen Grund, warum Sie sich nicht diesen erfolgreichen Männern und Frauen anschließen sollten, die ihre Karriere und ihre Fähigkeiten mithilfe des Scrum-Rahmenwerks weiterentwickelt haben.

Wenn Sie noch unsicher sind, möchte ich Ihnen versichern, dass eine wachsende Karriere ohne Scrum-Master-Zertifizierung nicht mehr vorstellbar ist. Das gilt unabhängig von Ihrer Rolle, Ihrem Titel und Ihrer Erfahrung im Ökosystem der Informationstechnologie (IT) .

Sie müssen nicht einmal mehr eine IT-Fachkraft sein, um zu verstehen, was Scrum ist, wie es funktioniert, und eine Scrum-Master-Zertifizierung zu erwerben.

Was auch immer Sie beruflich tun und ob Sie zur IT-Abteilung gehören oder nicht: Eine wesentliche und unbestreitbare Tatsache bleibt. Ihre Aufgaben und der berufliche Mehrwert, den Sie Ihrer Organisation bieten, hängen zusammen mit IT, Software und den agilen Scrum-Prozessen und -Prinzipien.

Darüber hinaus ist es angesichts des Wandels traditioneller Geschäftsmodelle hin zu Software as a Service (SaaS) basierten Unternehmen oder der sogenannten Digitalisierungsbewegung, für Fachkräfte innerhalb und außerhalb der IT-Abteilung keine freiwillige Entscheidung mehr, sich als Scrum Master zertifizieren zu lassen. Heute ist eine Scrum-Master-Zertifizierung vielmehr ein Muss.

Vielleicht beginnen Sie gerade Ihre Karriere oder sind eine erfahrene IT-Fachkraft. Das spielt keine Rolle. Sie brauchen Ihre Scrum-Master-Zertifizierung.

Ihre Rolle kann Personal- und Funktionsmanagement umfassen oder auch nicht. Auch das spielt keine Rolle: Sie brauchen dennoch eine Scrum-Master-Zertifizierung.

Vielleicht haben Sie einen Titel wie:

• Business-Analyst,
• Softwarearchitekt,
• Unternehmensarchitekt,
• Softwaredesigner
• User-Experience-Designer (UX),
• User-Interface-Designer (UI),
• Softwareentwickler,
• Leiter der Softwareentwicklung,
• Testingenieur,
• Spezialist für Testautomatisierung,
• Testmanager,
• Spezialist für IT-Systembetrieb,
• Unix-/Linux-Administrator,
• Ingenieur für Informationssicherheit (InfoSec),
• IT-Netzwerkingenieur,
• Datenbankadministrator (DBA),
• Projektmanager,
• Programmmanager,
• Produktmanager,
• Teamleiter, Manager, Direktor oder Führungskraft,
• oder irgendeinen anderen Titel, den ich hier nicht aufgeführt habe.

Sie sollten das Scrum-Rahmenwerk für Softwareentwicklung lernen und noch heute Scrum Master werden durch den Erwerb Ihrer Scrum-Master-Zertifizierung.

3 Ursachen für Chaos und Frustration vor dem agilen Scrum-Prozess und Scrum-Master-Zertifizierungen

Um die Auswirkungen des Scrum-Rahmenwerks auf unsere Softwareentwicklung und Unternehmen besser zu verstehen, lohnt sich ein Blick auf einen typischen Arbeitstag (oder ein Softwareprojekt).

Deshalb möchte ich kurz über ein früheres Softwareprojekt sprechen, bevor wir das Scrum-Rahmenwerk für Entwicklung und Softwarelieferung in unseren Organisationen eingeführt haben.

Einige Tage, bevor ich diese Zeilen schrieb, aß ich mit einem ehemaligen Kollegen zu Mittag, mit dem ich vor fast 20 Jahren zusammengearbeitet hatte. Dieser Herr, Marcus, hat seine Scrum-Master- und Scrum-Product-Owner-Zertifizierung erworben bei International Scrum Institute™.

Er arbeitet derzeit als Scrum Master bei einem der führenden Softwarehäuser im Bereich agiler Projektmanagementsoftware.

Als Scrum Master unterstützt Marcus heute ein agiles Scrum-Team, dessen Mitglieder an geografisch verteilten Standorten auf der ganzen Welt arbeiten.

Bei unserem Mittagessen räumte Marcus ein, dass verteilte agile Scrum-Teams viele typische Herausforderungen haben. Einige Probleme, die er im Zusammenhang mit seinem Softwareprojekt ausdrücklich nannte, waren:

• Unterschiedliche Arbeitsweisen der Scrum-Teammitglieder,
• Zeitzonenunterschiede,
• kulturelle Reibungen und
• sprachliche Grenzen.

Trotz dieser Schwierigkeiten ergänzte Marcus, dass die Durchführung eines Softwareprojekts mit dem agilen Scrum-Prozess mehr Spaß macht, produktiver und bereichernder ist als unsere Arbeitsweise vor 20 Jahren. Verglichen mit den Tagen, als wir ohne Scrum-Prozesse für Softwareentwicklung und Softwarelieferung arbeiteten.

Marcus’ Aussage war tatsächlich ein starkes Zeugnis zugunsten des Scrum-Rahmenwerks von einem sehr erfolgreichen und erfahrenen Manager, Scrum Master und Product Owner.

Danke, Marcus!

Dann erzählte ich ihm von einem meiner früheren Softwareprojekte, bevor ich das Scrum-Rahmenwerk kennenlernte. Ich bin sicher, dass viele Scrum Master darin ihre früheren Projekte aus der Zeit vor ihrer Scrum-Master-Zertifizierung wiedererkennen.

Ende der 1990er-Jahre war ich Teil einer Softwareentwicklungsgruppe, die ein chipkartenbasiertes Public-Key-Infrastruktur. Smartcards schützten private Schlüssel der Mitglieder. Öffentliche Schlüssel und ihre Zertifikate wurden dagegen offen verteilt.

Das komplexe IT-Projekt brauchte mehrere voneinander abhängige Hard- und Softwareteams. Umfangreiche Forschung und Entwicklung (F&E) war für ein voll funktionsfähiges System nötig.

Denken Sie daran: Das war, bevor wir das Minimum Viable Product (MVP) zum Experimentieren, Erstellen, Lernen und erneuten Experimentieren.

Wenn Sie mehr darüber erfahren möchten, wie Sie mit agilen Methoden ein MVP entwickeln, lesen Sie diesen Artikel von Cleevio, der Ihnen einen besseren Überblick über diesen komplexen Prozess gibt.

Ohne Scrum eine so anspruchsvolle Infrastruktur aus zahlreichen Hardware- und Softwareelementen zu schaffen, war eine echte Herausforderung.

Hier sind drei wesentliche Rückschläge, die wir ohne Scrum Master und ohne Personen mit Scrum-Master-Zertifizierung in unseren Teams erlebten.

1. Ursache für Chaos und Frustration ohne Scrum-Master-Zertifizierung: Wir mussten das gesamte Projekt planen, bevor wir verstanden, worum es überhaupt ging

Ohne Scrum hatten unsere Teams völlig falsche Software- und Hardwareprodukte entwickelt und geliefert, die den Anforderungen unseres Kunden nicht entsprachen.

Es gab Zeiten in unserem Berufsleben, in denen uns Drittunternehmen vorschrieben, wie wir unsere Softwareprodukte oder Softwaredienstleistungen entwickeln sollten.

Capability Maturity Model (CMM), ISO 9001:2008 und weitere Ableitungen versuchten, unseren Unternehmen zu helfen, die richtige Software auf die richtige Weise zu entwickeln.

Wie erfolgreich sie waren, ist nicht Thema dieses Artikels. Dieser Artikel konzentriert sich auf den Scrum-Prozess und die Vorzüge einer Scrum-Master-Zertifizierung, statt Qualitätsmanagement- und Prozessverbesserungsstandards als ausgestorbene Alternativen zu Scrum zu behandeln.

Ich muss jedoch ergänzen, dass diese Prozessverbesserungsrahmenwerke vor dem Scrum-Rahmenwerk für Softwareentwicklung in unseren Projekten phasenweise umgesetzt wurden. Wir nutzten einen phasenorientierten Softwareentwicklungsansatz, den wir das Wasserfallmodell der Softwareentwicklung nannten.

Beim Wasserfallmodell sollte jedes Softwareprojekt mit einer Anforderungsanalyse beginnen, in der wir verstehen wollten, was unser Kunde brauchte und wollte.

Dann entwarfen wir Lösungen für diese Anforderungen, setzten sie um, testeten (verifizierten) sie und warteten sie in unseren Softwareproduktionsumgebungen. Schließlich erreichten wir das Ende des Softwareentwicklungslebenszyklus.

Doch die Wirklichkeit sah anders aus!

Die negativen Auswirkungen unvorhergesehener Verzögerungen während einer bestimmten Phase des Wasserfallmodells wirkten sich unweigerlich auf die folgenden Softwareentwicklungsphasen aus.

So war das Leben vor dem Scrum-Rahmenwerk.

Das Hin- und Herschieben unserer Software zwischen verschiedenen Teams ohne Anleitung durch Fachkräfte mit Scrum-Master-Zertifizierung machte unsere Arbeit bürokratisch, komplex und unproduktiv.

Letztlich litt nicht nur das Produkt, sondern auch die Mitarbeitermoral und das Engagement für unsere Unternehmensmission wurden völlig erschüttert.

2. Ursache für Chaos und Frustration ohne Scrum-Master-Zertifizierung: Mangelndes Engagement, Change-Management und mangelnde Disziplin bei der Zusammenarbeit verschiedener Teams

Die größte Schwäche der früheren Verbesserungsmodelle war: Sie konzentrierten sich hauptsächlich auf eigennützige organisatorische Forderungen der Führung.

Dazu gehörten Überwachung, Regelkonformität und Vorhersagbarkeit. Guter Kundenservice und eine bessere Mitarbeitermoral standen überhaupt nicht im Mittelpunkt.

Management und interne wie externe Stakeholder wollten feste Liefertermine und einfach überwachte Entwicklungsphasen.

Abweichungen wurden bestraft. Man hoffte, neue Probleme vor dem geplanten Abschluss zu beheben.

Außerdem führten unabhängige Silos vollständig voneinander getrennte Softwareentwicklungsphasen aus. Zum Beispiel war das Entwicklungsteam völlig unabhängig vom Softwaretestteam (Verifizierung). Die meisten Menschen, die an derselben Geschäftsmission arbeiten sollten, kannten einander nicht einmal mit Namen.

Warum dominierten Silos statt Geschäftsmission und beruflicher Reife?

Der Grund ist einfach: das Matrixmanagement. Diese Führungs- und Personalstruktur gibt es seit den 1970er-Jahren. Ihr Grundgedanke wirkt zunächst klug.

Die Führung schafft eine Organisationsstruktur, indem sie Mitarbeiter mit ähnlichen funktionalen und technischen Fähigkeiten in denselben oder bestenfalls benachbarten Silos zusammenfasst.

Damals waren sogenannte „Kompetenzzentren“ in unseren Unternehmen sehr verbreitet, wobei jedes Kompetenzzentrum ein unabhängiges und autonomes Silo bildete.

Ein Silo für C++-Entwickler, eines für Datenbankadministratoren, ein völlig getrenntes Qualitätssilo im Ausland und so weiter. Stellen Sie sich das vor!

Die größte Herausforderung der Matrixorganisation bestand darin, dass Projektmanager für die Lieferung eines Softwareprojekts ohne Scrum-Rahmenwerk und Scrum Master vorübergehend Mitarbeiter aus den Silos ausleihen mussten.

Diese Mitarbeiter saßen nicht einmal räumlich bei ihren Projektteams, sondern blieben in den Räumen ihres jeweiligen Kompetenzzentrums.

Nach Abschluss der Projekte wurden diese temporären Projektteams aufgelöst, und die Projektteilnehmer wechselten zu ihren nächsten Aufgaben in anderen Projekten.

Der angestrebte Geschäftsnutzen war für die unabhängigen Silos deshalb nie die höchste Priorität.

Sie sahen ihre Arbeit eher als abgehakte Kästchen für dieses oder jenes Projekt.

Führung und Matrix lehrten sie nicht, sich für bessere Verkäufe, Umsätze und Gewinne einzusetzen.

Ein Beitrag von McKinsey & Company in McKinsey Quarterly verdeutlichte ebenfalls diese Illusion der Kostenoptimierung über die Matrix hinaus..

Der Quellartikel zitiert eine Gartner-Schätzung über die weltweiten jährlichen 600 Milliarden USD für die Wiederherstellung ihrer IT-Systeme ausgaben, bedingt durch ungeplante Wartung und Fehler.

Nehmen wir uns nun kurz Zeit, uns vorzustellen, wie Change-Management und der Umgang mit Hindernissen in Softwareprojekten abliefen. Wie sie in einer Projektkonstellation mit Wasserfallmodell und Matrixorganisation und ohne Scrum-Prozess abliefen.

Ja, Sie haben recht. Führungskräfte und Mitarbeiter behandelten Change-Managementsowie den Umgang mit Hindernissen und Fehlern wie unerwünschte Ausnahmen, die gar nicht erst hätten auftreten dürfen.

Änderungen in einem Softwareprojekt waren deshalb gleichbedeutend mit Verzögerungen. Meist lösten sie einen Dominoeffekt mit aufeinanderfolgenden Verzögerungen aus. Die Teams suchten jemanden, dem sie die Schuld an Fehlern und Hindernissen zuschieben konnten.

Ohne Verfahren zum Bearbeiten, Beheben und Lernen wiederholten Silos dieselben Fehler.

Außerdem erhöhten sie fortlaufend die Menge an technischen Schulden während sie nur passiv mit ihren Problemen umgingen.

3. Ursache für Chaos und Frustration ohne Scrum-Master-Zertifizierung: Autokratische Entscheidungen verdrängten demokratische Entscheidungen

Steve Jobs sagte einmal:

„Es ist nicht sinnvoll, kluge Menschen einzustellen und ihnen zu sagen, was sie tun sollen. Wir stellen sie ein, damit sie uns sagen, was wir tun sollen.“

Das ist jedoch genau das Gegenteil davon, wie die meisten traditionellen Führungskräfte vor dem Scrum-Zeitalter Entscheidungen trafen.

Bevor wir den Scrum-Prozess in unseren Organisationen hatten, setzten sich autokratische Entscheidungen der Führungskräfte über die gemeinsame Intelligenz ihrer Teams hinweg.

Sie setzten die demokratische Entscheidungsfähigkeit der Gruppen außer Kraft, die die eigentliche Arbeit erledigten. vom Softwarekonzept bis zum Betrieb über den gesamten Lebenszyklus.

Je weiter eine Entscheidung von den betroffenen Arbeitszentren (Teams) entfernt getroffen wurde, desto schwieriger war eine richtige, missionskritische Entscheidung.

Urteile waren meist impulsiv, wenig durchdacht, spät und vorläufig, manchmal aber auch zu früh.

Diese autokratischen Entscheidungen von oben ließen Menschen sich geringgeschätzt fühlen. Sie verhinderten kreative und innovative Antworten auf geschäftliche und technische Wettbewerbsherausforderungen.

Außerdem entmutigten sie die Softwareentwicklungsteams, ihre Sichtweise einzubringen, wenn diese um Beiträge zu Entscheidungen gebeten wurden.

Das war ein kurzer Überblick darüber, wie wir unsere Softwaredienstleistungen und Serviceprodukte entwickelten und lieferten, bevor wir das Scrum-Rahmenwerk in unseren Organisationen einführten. Sehen wir uns nun an, wie wir diese Ursachen für Chaos und Frustration mithilfe des Scrum-Prozesses beseitigten.

Was ist Scrum?

Zunächst möchte ich betonen, dass dieser Abschnitt nicht als Nachschlagewerk für alle Fragen zum Scrum-Rahmenwerk gedacht ist. Die hier behandelten Inhalte geben den meisten Scrum-Fachkräften auf Anfänger- und mittlerem Niveau dennoch einen fundierten Einstieg.

Für alle, die einen fortgeschritteneren, aber weiterhin praxisnahen Leitfaden suchen, um das Scrum-Rahmenwerk schnell zu lernen, haben wir ebenfalls etwas. Ich empfehle Ihnen, unseren Leitfaden zum Scrum-Rahmenwerk über diesen Link herunterzuladen.

Was ist Scrum? Ohne es unnötig kompliziert zu machen, lässt sich das Scrum-Rahmenwerk so definieren:

Scrum ist ein leichtgewichtiges Rahmenwerk, um durch adaptive Lösungen für komplexe Probleme Wert zu schaffen. Iterative und inkrementelle Softwareentwicklung ist eine wichtige Anwendung.

Obwohl Software der Hauptschwerpunkt des Scrum-Rahmenwerks ist, kann der iterative und agile Scrum-Prozess auch außerhalb der Softwarebranche angewendet werden und wird dort bereits genutzt.

Die meisten Menschen in der IT-Branche glauben, der Begriff „Scrum“ sei Anfang der 2000er-Jahre parallel zu aufkommenden Trends agiler Softwareentwicklung und Lieferung entstanden. Das ist falsch!

Der Artikel der Harvard Business Review vom Januar 1986 beschrieb einen Ansatz der Produktentwicklung, der dem späteren Scrum-Rahmenwerk vorausging. Hirotaka Takeuchi und Ikujiro Nonaka verfassten den Artikel: The New New Product Development Game. (Ja, zweimal „New“)

Sie sollten sich „The New New Product Development Game“ ansehen, um zu erfahren, wie alles mit Scrum begann!

Wenn die IT-Branche über das Scrum-Rahmenwerk spricht, hören wir häufig neben „Scrum“ auch den Begriff „Agile Scrum“. Das hat einige von uns dazu gebracht, Unterschiede zwischen „Agile Scrum“ und „Scrum“ zu vermuten und zu suchen.

Hier ist eine gute Nachricht: „Agile Scrum“ und „Scrum“ bezeichnen dasselbe. Beide stehen für den Scrum-Softwareentwicklungsprozess. Warum setzen wir dann manchmal „Agile“ vor „Scrum“?

Weil das Scrum-Rahmenwerk das Agile Manifest (Manifest für agile Softwareentwicklung) vollständig übernommen und eingebettet hat in seinen Kernprozess, seine Prinzipien und seine zugrunde liegende Philosophie. Deshalb sollten wir das Agile Manifest und die Werte des Scrum-Prozesses besser verstehen, bevor wir in die technischen Einzelheiten einsteigen.

Das Agile Manifest (Manifest für agile Softwareentwicklung)

Die Werte des Agilen Manifests:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge,
• Funktionierende Software mehr als umfassende Dokumentation,
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,
• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Obwohl die Faktoren auf der rechten Seite weiterhin erheblichen Wert besitzen, schätzt und priorisiert das Agile Manifest die Faktoren auf der linken Seite höher.

Die vom Agilen Manifest bevorzugten Elemente wurden sorgfältig über die Zeit erprobt und ausgewählt, um:

• Kunden und Stakeholder besser zu betreuen und mit Software Wert für sie zu schaffen,
• Den Beruf der Softwareentwicklung zu fördern, unabhängig von Ihrer Rolle, Ihrem Titel oder Ihrer Karrierestufe.

Die Werte des Scrum-Rahmenwerks

Ich habe bereits erwähnt, dass das Scrum-Rahmenwerk nicht nur ein Softwareentwicklungsprozess ist. Es besitzt auch ein starkes Fundament aus Prinzipien.

Die meisten Berufsfelder können diese Prinzipien anwenden und nutzen.

Eine Scrum-Master-Zertifizierung allein reicht nicht für großen Erfolg mit Scrum. Sie sollten die Scrum-Werte fest verinnerlicht haben, um mit Scrum erfolgreich zu sein.

damit Sie hervorragende Arbeit und großartige Software liefern, die Ihre Kunden und Arbeitgeber begeistern. Lassen Sie mich Ihnen nun mehr über diese Prinzipien des Scrum-Prozesses erzählen.

Mut

Manchmal ist es nicht einfach, das Richtige zu tun, um unseren Kunden den besten Wert und Nutzen zu bieten. In solchen Momenten sollten Scrum Master, Scrum Product Owner und Scrum-Teammitglieder an ihre Pflicht und Verantwortung denken.

Sie sollen die bestmöglichen Produkte und Dienstleistungen in ihrem Geschäfts- und IT-Bereich schaffen. Um mehr als Mittelmaß zu bieten, ein Scrum-Team muss sich früher oder später schwierigen Entscheidungen stellen, die nicht alle Stakeholder in seinem jeweiligen Umfeld glücklich machen.

Um damit umzugehen, sollten alle Scrum-Teammitglieder daran denken, was sie während ihrer Scrum-Master-Zertifizierungsschulung gelernt haben.

Sie sollten daran denken, mutig zu sein, und lernen, mutig zu entscheiden und zu handeln.

Fokus

Wenn Sie im Scrum-Rahmenwerk den Wert Fokus hören, sollten Sie an zwei Dinge denken:

• Die richtige Arbeit erkennen: Welche Aufgaben sind notwendig, um die Ziele meines Sprints zu erreichen? Was ist entscheidend, um die besten Softwareprodukte und -dienstleistungen für meine Kunden zu entwickeln, damit sie mit meiner Arbeit zufrieden sind?
• Priorisierung: An welchen Aufgaben sollte ich als Nächstes arbeiten?

Zu jedem Zeitpunkt muss das gesamte Scrum-Team einschließlich Scrum Master und Product Owner eine entscheidende Frage beantworten. Diese Frage lautet: „Was sind die wichtigsten Dinge, die wir jetzt tun sollten, um die Gründe zu erfüllen, aus denen unser Arbeitgeber uns überhaupt eingestellt hat?“

Das Scrum-Rahmenwerk enthält mehrere feste Ereignisse (Rituale), um User Stories und Aufgaben sinnvoll zu priorisieren. Nach dem Scrum-Prozess sollte die Priorisierung von User Stories und ihren zugehörigen Aufgaben fortlaufend Vorrang haben.

So stellen wir sicher, dass das Scrum-Team an den richtigen Dingen in der richtigen Reihenfolge arbeitet. Die formellen Scrum-Ereignisse und die zugehörigen Refinement-Praktiken helfen uns, unseren Fokus zu überprüfen und unsere Arbeit anzupassen:

• Scrum-Grooming-Meeting: Refinement klärt, zerlegt und bemisst kommende Product-Backlog-Einträge und hilft, ihre Reihenfolge festzulegen. Eine Besprechung ist eine Möglichkeit für diese fortlaufende Tätigkeit.
• Sprint Planning: Diese Treffen zeigen Abhängigkeiten und die richtige Arbeitsreihenfolge für unsere User Stories.
• Daily Scrum: Daily-Scrum-Meetings (Daily Stand-ups) helfen uns, den kommenden Arbeitstag auszurichten. Wir müssen unseren Fokus dorthin lenken, wo er am dringendsten gebraucht wird.
• Sprint Review: Das Sprint-Review-Meeting zeigt uns indirekt, worauf sich das Scrum-Team konzentrieren muss, um künftige Reviews erfolgreicher zu gestalten.
• Sprint Retrospective: Diese Besprechungen helfen dem Scrum-Team zu priorisieren, welche Aspekte seines Entwicklungsprozesses zuerst verbessert werden müssen.

In diesem Abschnitt habe ich die Scrum-Rituale nur unter dem Gesichtspunkt des Fokus behandelt. Eine ausführlichere Erläuterung der Scrum-Zeremonien finden Sie später in diesem Artikel.

Nach all dem sollte Ihnen klar sein, wie wichtig Priorisierung und Fokus für das Scrum-Rahmenwerk sind.

Commitment

Ohne das Engagement des Scrum Masters, des Scrum Product Owners und des Scrum-Teams ist es unmöglich, herausragende Softwareergebnisse zu liefern.

In der Welt der Scrum-Softwareentwicklung verstehen die meisten Menschen den Wert Commitment als Vereinbarung und Bindung an die Ziele bestimmter Sprint-Lieferergebnisse.

Das ist sinnvoll, aber nicht die ganze Bedeutung. Wenn im Zusammenhang mit Scrum-Werten von „Commitment“ die Rede ist, verwendet der Autor das Wort „Besessenheit“, um Hingabe zu betonen. Nach der Scrum-Definition betrifft Commitment die Ziele des Teams und gegenseitige Unterstützung; es verlangt weder Überarbeitung noch Sicherheit über jeden prognostizierten Eintrag.

Um in der Softwareentwicklung sowie im Leben und im Geschäft erfolgreich zu sein, sollten Sie Ihre Ziele mit Besessenheit verfolgen. Im Zusammenhang mit dem Scrum-Prozess sollten Sie davon besessen sein, großartige Software zu schaffen, die Kundenprobleme löst.

Warum sind Commitment und die damit verbundene Besessenheit von den Scrum-Zielen so wichtig? Ohne diese Besessenheit von der Teammission, hervorragende Software zu entwickeln und zu liefern, wird Ihre Arbeit jedes Mal langsamer und kommt zum Stillstand, wenn das Scrum-Team auf ein nicht triviales Hindernis trifft.

Dann beginnen der Scrum Master und das Scrum-Team, dem Scrum Product Owner mit Erklärungen zu rechtfertigen und zu begründen, warum sie die Sprint-Ziele nicht erreichen können. Ausreden sollten in Ihrem Team keinen Platz mehr haben, wenn Sie ein überdurchschnittliches Scrum-Team werden möchten.

Nur mit einem enorm hohen Maß an Hingabe ist es vergleichsweise leichter und erfüllender, die Probleme unserer Kunden zu lösen, ihnen zu helfen und mit Software Wert für sie zu schaffen.

Respekt

Unabhängig von Alter, Geschlecht, Herkunft, Glauben, Erfahrung, Kompetenz, Meinungen und Arbeitsleistung müssen alle Scrum-Teammitglieder einander respektieren und sich aufeinander verlassen können.

Dieser Respekt endet nicht an den Grenzen des Scrum-Teams. Alle internen und externen IT- und Geschäfts-Stakeholder, die mit dem Scrum-Team interagieren, werden von ihm uneingeschränkt respektiert und willkommen geheißen.

Erfahrene Teammitglieder müssen darauf achten, die Bereitschaft weniger erfahrener Mitglieder zur Mitarbeit nicht zu entwerten.

Besonders wichtig ist es, gegenteilige Meinungen, denen die Mehrheit der Gruppe nicht zustimmt, angemessen aufzunehmen und zu beantworten.

Offenheit

Der Scrum-Wert Offenheit ist oft eines der wichtigsten Unterscheidungsmerkmale zwischen einem durchschnittlichen und einem leistungsstarken Scrum-Team. Stellen Sie sich die Offenheit eines Scrum-Teams als die große Stärke einer Gruppe aufgeschlossener Menschen vor.

Sie sind kreativ, innovativ, intellektuell, ehrlich, direkt und bescheiden. Im Scrum-Prozess für Softwareentwicklung und Lieferung sollten Menschen Herausforderungen und unterschiedliche Sichtweisen offen besprechen können. Offenheit macht nicht jede Entscheidung oder Handlung angemessen: Respekt, Qualität und die Ziele des Teams bleiben wichtig.

Die einzige Bedingung ist, dass sie transparent sind und zur gemeinsamen Mission des Scrum-Teams beitragen wollen.

Das bedeutet nicht, dass jede Entscheidung und Handlung zwangsläufig die Ergebnisse des Scrum-Teams beschleunigen und zu großen Erfolgsgeschichten führen muss.

Dank der Werte Offenheit und Mut hat die Scrum-Softwareentwicklungsgruppe keine Angst, Fehler zu machen. Es betrachtet Fehler und nicht optimale Ergebnisse als wichtige Chancen, Produktivität und Arbeitsqualität wesentlich zu verbessern.

Die Hauptkomponenten des Scrum-Rahmenwerks

Das Scrum-Team besteht aus einem Product Owner, einem Scrum Master und Developern mit drei unterschiedlichen Ergebnisverantwortlichkeiten. Die frühere Bezeichnung „Scrum Team Member“ in diesem Artikel meint die Entwicklungsgruppe, keine vierte Ergebnisverantwortlichkeit und kein separates vollständiges Scrum-Team.

Neben anderen Programmen für weltweite Lernende bietet International Scrum Institute™ drei grundlegende Schulungs- und Zertifizierungsprogramme für diese Rollen an.

Diese Programme sind Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™)und Scrum Team Member Accredited Certification™ (STMAC™).

Eine angemessene Scrum-Organisation muss Menschen mit allen drei Kompetenzprofilen haben. Das ist besonders wichtig für den Erfolg mit dem Scrum-Rahmenwerk für Softwareentwicklung.

Jede Scrum-Ergebnisverantwortlichkeit muss erfüllt werden. Die Verantwortlichkeiten bleiben getrennt; ein Product Owner oder Scrum Master kann bei der Arbeit am Sprint Backlog auch als Developer mitwirken, ohne die Pflichten seiner anderen Ergebnisverantwortlichkeit zu verlieren.

Mehrere Scrum-Teams, die an einem Produkt arbeiten, teilen einen Product Owner, ein Product Goal und ein Product Backlog. Jedes Team hat die Scrum-Master-Ergebnisverantwortlichkeit und braucht wirksame Unterstützung; Scrum schreibt nicht vor, dass eine Person nur ein Team unterstützen darf.

Bitte unterschätzen Sie nicht, wie wichtig es ist, Zweck und Funktion dieser Rollen zu verstehen und sie mit geeigneten Talenten zu besetzen. Oft haben wir beobachtet, dass Schwierigkeiten eines Scrum-Teams darauf zurückgehen, dass diese Rollen nicht verstanden oder nicht mit den richtigen Menschen besetzt werden.

Sprechen wir nun über diese drei Rollen.

Drei Scrum-Rollen — Die Rolle des Scrum Product Owners

Der Scrum Product Owner ordnet das Product Backlog, um den Produktwert zu maximieren, und arbeitet mit Stakeholdern an Produkt- und Release-Entscheidungen. Die Developer wählen die Arbeit aus, die sie für einen Sprint prognostizieren; Release-Regelungen hängen vom Produktkontext ab. Sie vertritt funktionale und nicht funktionale Anforderungen der Endnutzer.

Sie ist weit breiter als traditionelle Projekt-, Programm- oder Produktmanagementrollen.

Diese Rolle verbindet Aufgaben des Produkt- und Projektmanagements und ist eng mit Softwareentwicklung und Lieferung verknüpft.

Wichtige Aufgaben eines Scrum Product Owners sind:

• Anforderungen verwalten und klären,
• Releases lenken und ROI sichern,
• Eng mit dem Scrum-Team zusammenarbeiten,
• Stakeholder managen.

Drei Scrum-Rollen — Die Rolle des Scrum-Teammitglieds

Das Scrum-Team setzt die Software um. Die Developer wählen aus, wie viel Arbeit sie voraussichtlich abschließen können während eines Sprints. Der Sprint ist ein Ereignis mit fester Dauer; das dabei entstandene nutzbare Produktergebnis ist ein Increment, das die Definition of Done erfüllt.

Ein leistungsstarkes Scrum-Team enthält in der Regel die meisten Softwareentwicklungskompetenzen. Softwareentwickler, Architekten, Tester, Datenbankadministratoren und Teammitglieder aus allen weiteren Rollen arbeiten zusammen.

Gemeinsam entwickeln und liefern sie großartige Software, für die ihr Kunde bezahlt.

Scrum-Teammitglieder gehören nicht länger zu einem funktionalen Silo einer Matrixorganisation. Developer gehören nicht mehr zu Kompetenzzentren für Softwareentwicklung, Tester nicht mehr zum Kompetenzzentrum für Softwaretests und so weiter.

Unabhängig von ihrer früheren Position in der Organisation gehören Scrum-Teammitglieder zu ihrem jeweiligen Scrum-Projekt. Ihre Aufgabe ist nun, die bestmögliche Software zu entwickeln, um die Anforderungen ihres Scrum Product Owners zu erfüllen.

Scrum-Teams haben folgende Eigenschaften:

• Befähigt und ermächtigt,
• Autonom,
• Funktionsübergreifend,
• Selbstorganisiert,
• Klein,
• Ausreichend verfügbare Teilnehmer (Vollzeitmitarbeit ist eine häufige organisatorische Entscheidung),
• Zu enger Zusammenarbeit fähig, ob am selben Ort oder verteilt,
• Einer für alle, alle für einen.

Drei Scrum-Rollen — Die Rolle des Scrum Masters

Der Scrum Master hilft allen Beteiligten eines Scrum-Projekts und externen Stakeholdern, das Scrum-Rahmenwerk zu verstehen und richtig anzuwenden. Sie unterstützt das Scrum-Team bei der erfolgreichen Durchführung des Scrum-Prozesses und dabei, Produktivität und Leistung fortlaufend zu verbessern.

Die Aufgabe des Scrum Masters besteht darin, den Scrum-Prozess und die neue Denk- und Handlungsweise zu etablieren.

Außerdem wirkt der Scrum Master als Veränderungsbegleiterin. Sie coacht das Team bei der Entwicklung neuer Teamnormen und Standards. Sie bleibt für das Team erreichbar; räumliche Nähe kann helfen, ist aber keine Scrum-Anforderung.

Zu den wesentlichen Aufgaben des Scrum Masters gehören:

• Scrum in seinem Geschäfts- und IT-Umfeld etablieren,
• Das Team coachen, damit es die Scrum-Werte versteht und lebt,
• Eine enge Zusammenarbeit zwischen Scrum Product Owner und Scrum-Team sicherstellen,
• Hindernisse beseitigen,
• Durch Dienen führen,
• Wirksame Scrum-Ereignisse unterstützen und bei Bedarf moderieren, wobei die Verantwortung der Developer für das Daily Scrum erhalten bleibt.

Product Backlog (Scrum-Backlog)

Das Product Backlog (Scrum Backlog), auch Scrum Product Backlog, ist das zentrale Element zur Verwaltung aller bekannten Anforderungen eines Scrum-Projekts.

Es enthält alle Kundenanforderungen und Arbeitselemente, die zur erfolgreichen Durchführung und Fertigstellung eines Projekts erforderlich sind. Zu den Anforderungen zählen funktionale und nicht funktionale Anforderungen sowie weitere Merkmale rund um die Nutzererfahrung und die Benutzeroberfläche das Design.

Das Product Backlog enthält Funktionswünsche und deren grobe User Stories. Dazu können auch notwendige oder ergänzende Projektanforderungen wie der Aufbau von Test- und Entwicklungsumgebungen gehören. Weitere User Stories zur Behebung bekannter Fehler, zum Abbau technischer Schulden oder zur Verbesserung bestimmter Softwarefunktionen haben ebenfalls ihren Platz im Product Backlog.

Jedes Produkt hat sein Product Backlog. Der Scrum Product Owner ist für dessen Erstellung, Pflege und Feinabstimmung verantwortlich. Das Product Backlog beantwortet nicht und sollte nicht beantworten, wie diese Anforderungen entwickelt und geliefert werden.

Das ist die Aufgabe des Scrum-Teams. Es entscheidet über die erforderlichen Aufgaben zur Erfüllung dieser Anforderungen und dokumentiert sie in Sprint Backlogs. Beachten Sie, dass Product Backlog und Sprint Backlog unterschiedliche Artefakte sind, nicht zwingend physisch getrennte Dokumente oder Werkzeuge, obwohl die Einträge des Product Backlogs die Inhalte des Sprint Backlogs bestimmen.

Das Product Backlog ist ein lebendes Dokument. So wie sich die Software schrittweise verbessert, verändert sich das Product Backlog mit dem Lernen des Teams durch Ergänzungen, Entfernungen und Änderungen der Reihenfolge. Das Scrum-Rahmenwerk verlangt an sich keinen separaten Change-Management-Prozess. Der Scrum Product Owner erstellt die ersten Versionen des Product Backlogs auf Grundlage seines bestmöglichen anfänglichen Produktverständnisses.

Während sie genau beobachtet, wie das Produkt von Sprint zu Sprint entsteht, und ihr Wissen über Kundenanforderungen wächst, ergänzt, entfernt und verfeinert sie Anforderungen im Product Backlog.

Der Scrum Product Owner priorisiert die Anforderungen im Product Backlog. Je höher die Priorität eines Product-Backlog-Eintrags ist, desto mehr Details sollte er enthalten. So kann das Scrum-Team diese hoch priorisierten Anforderungen leicht verstehen und die nötigen Umsetzungsaufgaben erstellen.

Außerdem schätzt das Scrum-Team mit einem Schätzansatz wie Story Pointsregelmäßig die Anforderungen im Product Backlog. Diese Schätzungen sollten für hoch priorisierte User Stories verfeinert und verbessert werden, damit diese für das Sprint Planning bereit sind.

Sprints

Im Scrum-Rahmenwerk finden alle Aktivitäten zur Umsetzung der Anforderungen während der Sprints statt. Sprints sind Arbeitszyklen zur Entwicklung auslieferbarer Inkremente eines Softwareprodukts oder einer Dienstleistung. Sprints werden manchmal auch Iterationen genannt.

Stellen Sie sich Sprints als Mikroprojekte vor. Wie der Begriff „Sprint“ andeutet, dauert ein Sprint nicht lange: einen Monat oder weniger. Vierwöchige Sprints sind ein häufiges Beispiel, nicht die genaue maximale Kalenderdauer des Rahmenwerks.

Anders als bei einem Lauf sollte das Scrum-Team am Ende eines Sprints nicht außer Atem und erschöpft sein. Stattdessen sollte es frisch sein und den nächsten Sprint voller Energie beginnen.

Das Scrum-Rahmenwerk für Softwareentwicklung und Lieferung soll seinen Teammitgliedern keinen Druck und Stress bereiten. Bekanntlich leisten Menschen am meisten, wenn sie konzentriert, entspannt und ungestört arbeiten können. Bei richtiger Anwendung helfen Sprints uns genau dabei.

Jeder Sprint beginnt mit einem Sprint-Planung. Im Sprint-Planning-Meeting entscheidet das Scrum-Team, welche und wie viele Anforderungen es in diesem Sprint umsetzen wird. Anschließend beginnt das Scrum-Team mit den Aktivitäten zur Lieferung der Anforderungen.

Daily Scrum (Daily-Scrum-Meeting) findet an jedem Arbeitstag des Sprints zur selben Zeit am selben Ort statt. Die Developer überprüfen dabei den Fortschritt zum Sprint Goal und passen ihren Plan für den nächsten Tag an. Scrum-Teammitglieder können den Scrum Master auch um Hilfe bei der Beseitigung von Hindernissen bitten, die den Fortschritt eines Sprints verlangsamen oder blockieren könnten.

Das Scrum-Team beendet einen Sprint mit Sprint Review und Sprint Retrospektive. Das Sprint-Review-Meeting ermöglicht dem Scrum-Team und wichtigen Stakeholdern, das Ergebnis des Sprints und den Fortschritt zum Product Goal zu überprüfen und anschließend künftige Anpassungen zu besprechen. Es ist eine Arbeitssitzung, keine Freigabestufe durch den Product Owner.

Während der Sprint-Retrospective-Besprechung, reflektiert das Scrum-Team darüber, wie es zusammenarbeitet, das Scrum-Rahmenwerk nutzt und sich verbessern kann.

So berücksichtigt das Scrum-Team diese Verbesserungspotenziale und Rückmeldungen gemeinsam beim nächsten Sprint-Planning-Meeting. Sprints ermöglichen solche Rückkopplungsschleifen in kurzen Zeiträumen mit kleinen Arbeitsmengen. Das ist einer der wesentlichen Gründe dafür, wie und warum das Scrum-Rahmenwerk Teams und Organisationen bei kontinuierlicher Verbesserung unterstützt.

Scrum: Überprüfen und Anpassen

Scrums „Überprüfen und Anpassen“ ist ein leicht verständliches Konzept, aber äußerst schwer richtig umzusetzen und zu meistern.

Unternehmen haben schließlich bestätigt, dass keiner ihrer Projektmanager das Gesamtbild komplexer Systeme vollständig vorhersehen kann. Eine verlässliche durchgängige Planung war ihnen nicht möglich. Es war offensichtlich, dass sie etwas anderes versuchen mussten.

Zusammen mit Lean Manufacturing (auch bekannt als Lean-Bewegung) mussten Unternehmen einen Prozess entwickeln, der sie strategisch handlungsfähiger machte. Sie brauchten ein standardisiertes Vorgehen, um während laufender Projekte und sogar im Betrieb zu lernen und ihre Vorgehensweise zu korrigieren.

Das war die Geburtsstunde von Toyota Improvement Kata, das einen nützlichen Vergleich mit Überprüfung und Anpassung in Scrum bietet. Diese Verbesserungsansätze sind in ihrem Zweck verwandt, doch Toyota Improvement Kata ist nicht einfach ein anderer Name für Scrums empirische Säulen. Nach „Scrum: Überprüfen und Anpassen“ gilt:

• Schritt 1. Überprüfen: Wir versuchen, den aktuellen Projektstand mit unserem derzeitigen Wissen und Verständnis bestmöglich zu erfassen.
• Schritt 2. Anpassen: Wir definieren eine Richtung und Vision für die nächsten Projektschritte, entwickeln dann eine Strategie und setzen unsere Vision um.
• Schritt 3. Lernen: Dabei beobachten wir sorgfältig, lernen und bringen einander etwas bei. Während unserer Arbeit halten wir fortlaufend fest, was funktioniert und was nicht.
• Schritt 4. Neu beginnen: Beginnen Sie erneut bei Schritt 1.

Die folgenden vier Schritte sind eine Lehranalogie, keine Eins-zu-eins-Definition der Scrum-Ereignisse. Überprüfung, Anpassung und Lernen finden während des gesamten Sprints statt.

• Schritt 1. Überprüfen entspricht in dieser Analogie den Sprint Reviews und Sprint Retrospektiven.
• Schritt 2. Anpassen entspricht in dieser Analogie den Sprint-Planning-Meetings.
• Schritt 3. Lernen entspricht in dieser Analogie den Daily-Scrum-Meetings.
• Schritt 4. Neu beginnen entspricht in dieser Analogie dem Abschluss eines Sprints und dem Beginn eines neuen Sprints.

Selbstorganisation

Das Scrum-Team organisiert sich selbst. Seine Mitglieder entscheiden im Konsens, welche Aufgaben sie ausführen müssen, um die Ziele eines Sprints zu erreichen. Ein selbstorganisiertes Team braucht keinen Manager oder Teamleiter.

Selbstorganisation im Scrum-Rahmenwerk ist sehr diszipliniert.

Sprint Backlog und Daily-Scrum-Besprechungen unterstützen das Selbstmanagement. Ein Sprint-Burndown-Chart ist eine optionale Möglichkeit, Fortschritt sichtbar zu machen.

Die eigene Arbeitsorganisation erfordert für die meisten Teams eine Lernphase. Kompetente Scrum Master mit Scrum-Master-Zertifizierungen helfen ihren Scrum-Teams, Selbstorganisation schnell zu beherrschen.

Selbstorganisation umfasst auch die Fähigkeit, trotz unterschiedlicher Meinungen und möglicher Konflikte zwischen Teammitgliedern zusammenzuarbeiten. Sie verlangt, gemeinsame Entscheidungsprozesse einzuhalten und ihnen zu vertrauen.

Zu diesen Entscheidungsprozessen im Scrum-Rahmenwerk gehören unter anderem Planung, Schätzung, Umsetzung, Berichterstattung und Überprüfung der Arbeit, für die das Scrum-Team gemeinsam verantwortlich ist.

Scrum-Ereignisse und fortlaufendes Backlog Refinement

Scrum-Ereignis 1. Sprint Planning (Warum, Was und Wie)

Während der Sprint-Planungerstellt das Scrum-Team ein umsetzbares Sprint Backlog, das die Anforderungen festlegt, die das Team während des Sprints umsetzen wird.

Die Aufgaben der verschiedenen Scrum-Rollen in Sprint-Planning-Meetings sind:

• Der Product Owner schlägt vor, warum der Sprint wertvoll sein könnte. Das gesamte Scrum-Team erarbeitet gemeinsam ein Sprint Goal, und die Developer wählen Product-Backlog-Einträge aus, die sie voraussichtlich abschließen können.
• Das Scrum-Team bestimmt die erforderlichen Aufgaben und ihre Schätzungen. Die Developer entscheiden unter Berücksichtigung bisheriger Leistung, Kapazität und Definition of Done, welche und wie viele Einträge sie voraussichtlich im Sprint abschließen können.
• Der Scrum Master moderiert die Besprechung. Sie stellt sicher, dass die Selbstorganisation und die autonome Entscheidungsfähigkeit des Scrum-Teams erhalten bleiben.

Bei Sprint-Planning-Meetings ist die Anwesenheit des Scrum Product Owners erforderlich. So kann sie Fragen des Scrum-Teams beantworten und Anforderungen sowie ihre Akzeptanzkriterien erläutern.

Das Scrum-Team kann weitere Personen wie Endnutzer oder Manager zum Sprint Planning einladen, um Rat einzuholen. Eingeladene Mitwirkende beraten, ohne den Developern die Entscheidungen darüber abzunehmen, wie sie die Arbeit ausführen.

Scrum-Ereignis 2. Daily-Scrum-Meeting (Daily Stand-up)

Das Daily Scrum ist eine Besprechung von höchstens 15 Minuten. Diese Besprechungen finden an jedem Arbeitstag zur selben Zeit am selben Ort statt. Am besten haben die Beteiligten direkten Zugriff auf das Sprint Backlog und den Sprint-Burndown-Chart. So kann sich das Scrum Team im Daily Scrum an Fakten und Fortschritten orientieren, die für alle sichtbar sind.

Das Daily Scrum soll die Selbstorganisation des Scrum Teams unterstützen und Hindernisse systematisch erkennen.

Das Daily Scrum ist für die Developer. Ein Product Owner oder Scrum Master, der an Sprint-Backlog-Einträgen arbeitet, nimmt als Developer teil. Andere Teilnahmeregelungen müssen den Fokus und das Selbstmanagement der Developer wahren; Scrum verlangt nicht die Teilnahme jeder Rolle oder jedes Stakeholders.

Die Developer wählen eine nützliche Struktur mit Fokus auf das Sprint Goal und einen umsetzbaren Plan. Die folgenden drei Fragen sind ein bekanntes optionales Format und keine im aktuellen Scrum vorgeschriebenen Fragen.

• Daily-Scrum-Meeting — Frage Nr. 1. Welche Aktivitäten habe ich seit dem letzten Daily Scrum ausgeführt?
• Daily-Scrum-Meeting — Frage Nr. 2. Welche Aktivitäten plane ich bis zum nächsten Daily Scrum? Was ist mein Aktionsplan?
• Daily-Scrum-Meeting — Frage Nr. 3. Bin ich auf Hindernisse gestoßen oder erwarte ich welche, die den Fortschritt meiner Arbeit verlangsamen oder blockieren könnten?

Die Entwickler führen ihr Daily Scrum selbst durch. Bei Bedarf hilft der Scrum Master den Developern, Zweck und Wirksamkeit zu verstehen. Das Ereignis bleibt auf 15 Minuten begrenzt; das Drei-Fragen-Format ist optional.

Das Ziel von Daily-Scrum-Meetings umfasst keine zeitaufwendigen Entscheidungen oder Problemlösungen. Um Entscheidungen abzustimmen und Probleme zu lösen, kann das Scrum-Team bei Bedarf separate Besprechungen organisieren. Diese Besprechungen zu Entscheidungen oder Problemen finden meist im Anschluss an Daily-Scrum-Meetings statt.

Der Scrum Master dokumentiert erkannte Hindernisse und ihre Daten in einem separaten, für das Team zugänglichen Protokoll, Flipchart oder Bericht. Ich finde es sehr hilfreich, ganz am Ende des Daily Scrums kurz den Status offener Hindernisse zu aktualisieren.

Scrum-Ereignis 3. Sprint-Review-Meeting

Das Sprint Review findet am Ende des Sprints statt. Ein ein- bis zweistündiges Review kann für manche Teams passen; das formelle Maximum beträgt vier Stunden bei einem einmonatigen Sprint, wobei kürzere Ereignisse für kürzere Sprints meist angemessen sind. Je nach Softwareart und verfügbarer Infrastruktur finden Sprint Reviews in einem Besprechungsraum, Labor oder im Raum des Scrum-Teams statt.

Das Ziel des Sprint-Review-Meetings ist es, das im Sprint entwickelte auslieferbare Produktinkrement zu überprüfen und Transparenz im Produktentwicklungsprozess zu schaffen.

Das Scrum-Team zeigt seine Arbeitsergebnisse. Scrum-Team und Stakeholder besprechen, was erreicht wurde und was sich im Umfeld verändert hat. Sie überprüfen Ergebnisse und überlegen, was als Nächstes zu tun ist; das Review ist keine Erfüllungskontrolle einer festen Liste zugesagter Aufgaben.

Das Sprint Review ermöglicht Scrum-Team und Stakeholdern, Produktergebnisse zu überprüfen und das Product Backlog anzupassen. Das gesamte Scrum-Team erarbeitet später gemeinsam das nächste Sprint Goal. Deshalb sind Sprint-Review-Meetings eine formelle und praktische Anwendung von „Überprüfen und Anpassen“.

Teilnehmer des Sprint Reviews sind das Scrum-Team, der Scrum Product Owner und der Scrum Master. Optional können alle weiteren Stakeholder wie Endnutzer, Kunden und Geschäftsvertreter teilnehmen.

Bei Sprint Reviews dürfen sie ihre Rückmeldung zum vorgestellten Produktinkrement geben. So erhält das Scrum-Team ungefilterte und direkte Rückmeldungen von den Stakeholdern, für die es Software entwickelt.

Scrum-Ereignis 4. Sprint-Retrospektive

Das Sprint-Retrospective-Besprechung folgt auf das Sprint Review und beendet den Sprint. Ihre maximale Dauer beträgt drei Stunden bei einem einmonatigen Sprint; bei kürzeren Sprints ist sie üblicherweise kürzer.

Das Ziel der Sprint-Retrospektiven ist es, die Zusammenarbeit der Scrum-Teammitglieder und die Anwendung des Scrum-Prozesses zu verbessern.

Sprint-Retrospektiven führen deshalb zu höherer Produktivität, besserer Leistung der Teammitglieder und höherer Softwarequalität.

Eine Sprint-Retrospektive ist praktisch eine kleine Nachbetrachtung, um Verbesserungspotenziale zu bestimmen und prozessbedingte Hindernisse zu beseitigen. Beispiele solcher Verbesserungspotenziale, die wir häufig in unseren Projekten sehen, sind:

• Agile Softwareentwicklungspraktiken einführen, etwa Extreme Programming (XP) oder testgetriebene Entwicklung (TDD).
• Neue Teamnormen und Prinzipien bestimmen oder
• die Verfügbarkeit des Scrum Product Owners erhöhen.

Das Scrum-Team führt ausnahmslos am Ende jedes Sprints eine Sprint-Retrospektive durch. Nur so ermöglichen diese Besprechungen dem Scrum-Team, seine Anwendung des Scrum-Prozesses systematisch an die Besonderheiten seines Projekts anzupassen und zu verbessern.

Zugehörige Praxis: Product Backlog Refinement (Grooming)

Scrum Backlog-Refinement-Meetings (Grooming) zielen darauf ab, das Product Backlog aktuell zu halten. So spiegelt es den bestmöglichen Wissens- und Verständnisstand des Teams zum laufenden Projekt wider.

Refinement kann bei Bedarf oder in geplanten Gesprächen stattfinden. Zwei 30-minütige Sitzungen pro Woche sind ein praktisches Beispiel, keine vorgeschriebene Häufigkeit oder Obergrenze. Product Owner und Developer arbeiten zusammen; Scrum Master und weitere Mitwirkende werden nach Bedarf einbezogen.

Während der Scrum-Backlog-Refinement-Meetings (Grooming) verfeinern die Teilnehmer das Product Backlog mit folgenden Maßnahmen:

• Neue User Stories aus neu entdeckten Anforderungen ergänzen.
• Nicht mehr benötigte Stories entfernen.
• Story-Schätzungen verfeinern.
• Story-Prioritäten aktualisieren.
• Sehr große Stories in kleine überschaubare Einheiten aufteilen und entsprechend priorisieren.

Vier einfache Schritte zu Ihrer Scrum-Master-Zertifizierung

Der Erwerb Ihrer Scrum-Master-Zertifizierung ist unkompliziert, schnell und vollständig online.

Dank International Scrum Institute™werden Sie jetzt schneller und kostengünstiger als je zuvor als Scrum Master zertifiziert.

Vier einfache Schritte zu Ihrer Scrum-Master-Zertifizierung ohne Zeit- und Geldverschwendung und ohne Schwierigkeiten folgen hier.

• Schritt Nr. 1. Online anmelden

  Melden Sie sich für Ihre Scrum-Master-Zertifizierung online an über Ihre Anmeldeseite zur Scrum Master Accredited Certification™.

  Nach Ihrer Anmeldung stellt International Scrum Institute™ Ihren Prüfungszugangscode sofort online bereit.

  Über den folgenden Link können Sie sich für Ihr Scrum-Master-Zertifizierungsprogramm anmelden.

• Bild in voller Größe öffnen ↗

  Schritt Nr. 2. Online lernen

  Lernen Sie für Ihre Scrum-Master-Zertifizierung online mit Ihrem Scrum-Lernleitfaden The Scrum Framework™.

  The Scrum Framework™ ist vollständig praxisorientiert konzipiert. Die Inhalte helfen Ihnen, Ihre täglichen Herausforderungen im Beruf und in Ihrer Karriere als talentierter Scrum Master zu bewältigen. The Scrum Framework™ enthält zahlreiche Fallstudien und Praxisbeispiele, die den Alltag der erfolgreichsten Scrum Master zeigen.

  Über den folgenden Link können Sie Fordern Sie Ihr kostenloses Exemplar von The Scrum Framework™ an.

• Schritt Nr. 3. Ihre Scrum-Master-Zertifizierungsprüfung online ablegen

  Wenn Sie Ihren Scrum-Lernleitfaden The Scrum Framework™ sorgfältig gelesen, studiert und verinnerlicht haben, sollten Sie bereit sein! Sie sollten nun vollkommen zuversichtlich sein, Ihre Scrum-Master-Zertifizierungsprüfung zu bestehen.

  Über den folgenden Link können Sie Rufen Sie Ihre Scrum-Master-Zertifizierungsprüfung auf.

• Schritt Nr. 4. Ihre Scrum-Master-Zertifizierung erhalten

  Sobald Sie Ihre Prüfung bestanden haben, stellen wir Ihnen Ihre Scrum-Master-Zertifizierung sofort bereit.

  Ihre Arbeitgeber und Kunden können die Echtheit Ihrer Zertifizierung mit Ihrem Scrum-Zertifizierungsvalidierungstool für Arbeitgeber überprüfen. Über den folgenden Link können Sie Ihr Scrum-Zertifizierungsvalidierungstool für Arbeitgeber aufrufen.

Mein Fazit zur Scrum-Master-Zertifizierung

Es ist Zeit für einen Rückblick. Wenn Sie nicht jedes Wort dieses Schritt-für-Schritt-Leitfadens zum Scrum Master lesen konnten, möchte ich meine Gedanken aufschlüsseln. Hier sind meine Überlegungen zu den Vor- und Nachteilen einer Scrum-Master-Zertifizierung.

Die Vorteile

Vorteile für Angestellte, Freiberufler, Coaches und Trainer

• Eine Scrum-Master-Zertifizierung bestätigt Ihre Kompetenz und Ihr aktuelles Wissen im Scrum-Bereich.
• Eine Scrum-Master-Zertifizierung hilft Ihnen, sich gegen Kollegen durchzusetzen, die sich nicht mehr weiterentwickeln. Sie hilft Ihnen, Ihren Traumjob als zertifizierter und erfolgreicher Scrum Master zu bekommen.
• Eine Scrum-Master-Zertifizierung erweitert Ihren Blickwinkel und öffnet Ihren Geist weiter für kontinuierliches Lernen. Sie hilft Ihnen, mehr Verantwortung und großartige Karrierechancen zu erhalten.
• Eine Scrum-Master-Zertifizierung gibt Ihnen ein völlig neues Instrumentarium, mit dem Sie großartige Produkte und Dienstleistungen liefern können, die Ihre Kunden und Arbeitgeber lieben werden.

Vorteile für Organisationen und Arbeitgeber

• Scrum-Master-Zertifizierungen senken Kosten, indem sie die Effizienz Ihrer Teams, Aktivitäten und Prozesse verbessern.
• Scrum-Master-Zertifizierungen helfen Ihnen, mit Ihren geschulten und kompetenten Mitarbeitern Projekte zu gewinnen, die Sie sonst nicht gewinnen könnten.
• Scrum-Master-Zertifizierungen verbessern Mitarbeiterzufriedenheit und Engagement, indem sie Mitarbeiter zu Schulungen und zum Ausbau ihrer Fähigkeiten ermutigen.
• Scrum-Master-Zertifizierungen verbessern die Qualität Ihrer Lieferergebnisse, die Kundenzufriedenheit und letztlich den Erfolg und die Rentabilität Ihrer Organisation.

Die Nachteile

• Eine Scrum-Master-Zertifizierung sollte Ihr Lernen nicht beenden. Denken Sie daran, dass die Zertifizierung als Scrum Master nur der erste Schritt ist.

  Im Sinne von „Überprüfen und Anpassen“, das Sie aus dem Scrum-Rahmenwerk kennen, bleibt es Ihre Pflicht und Verantwortung, fortlaufend zu experimentieren, zu beobachten und zu lernen.

• Es gibt keine Einheitslösung für alle Organisationen weltweit. Das Scrum-Rahmenwerk für Softwareentwicklung und Lieferung ist keine Ausnahme von dieser Regel.

  Wir haben beobachtet, dass die meisten Organisationen, die nicht die beste Leistung aus dem Scrum-Rahmenwerk herausholen konnten, ein gemeinsames Merkmal haben: Sie haben Scrum nicht an ihre eigenen Geschäfts- und IT-Umfelder angepasst.

  Betrachten Sie das Scrum-Rahmenwerk deshalb, wieder im Sinne von „Überprüfen und Anpassen“, nicht als zu 100 % garantierte Erfolgsformel. Unterschätzen Sie bitte nicht Ihre geistige Fähigkeit, es an die eigene Dynamik Ihres Geschäfts und Ihrer IT anzupassen. Als bezahlte Fachkraft ist genau das Ihre Aufgabe, um mit dem Scrum-Rahmenwerk den besten Durchsatz und die besten Geschäftsergebnisse zu erzielen.

• Scrum löst nicht alle IT-Probleme. Entwickeln Sie sich weiter mit neu entstehende Prozesse für Softwareentwicklung und Lieferung wie DevOps.

  Um die bekannten Schwächen des Scrum-Rahmenwerks und den Umgang von DevOps damit besser zu verstehen, lesen Sie später diesen hervorragenden Artikel: Was sind die 6 WICHTIGSTEN Unterschiede zwischen DevOps und Scrum?

Zusammenfassend ist eine Scrum-Master-Zertifizierung ein hervorragender Einstieg in agile Praktiken der Softwareentwicklung und Lieferung.

Laut einer Gartner-Studie „Ein besserer Scrum Master werden“ Der 2019 veröffentlichte Artikel prognostizierte für 2023, dass 92 % der Unternehmen weltweit und 96 % der Unternehmen in den Vereinigten Staaten agile Scrum-Praktiken einführen würden. Das ist die im Originalartikel berichtete Prognose, keine gemessene aktuelle Einführungsquote.

Es gibt deshalb keinen besseren Zeitpunkt als jetzt, um

• Beginnen Sie, das Scrum-Rahmenwerk kostenlos zu lernen und
• Lassen Sie sich zu den sehr günstigen Gebühren von International Scrum Institute™ als Scrum Master zertifizieren.

Bleibt nur die Frage: Wann beginnen Sie?