Was ist Scrum?

Scrum ist ein Framework für die Entwicklung, Lieferung und Aufrechterhaltung komplexer Produkte durch effektive Teamzusammenarbeit. Es bietet einen schlanken Prozess, um kollaborative, teambasierte Aktivitäten zu fokussieren und zu koordinieren, während das Scrum Team komplizierte adaptive Probleme angeht und ein Produkt von optimaler Wertschöpfung schrittweise und nach einem vorhersagbaren Zeitplan liefert.

Ursprünglich von den Professoren Hirotaka Takeuchi und Ikujiro Nonaka konzipiert und als "The New Product Development Game" in der Harvard Business Review 1986 veröffentlicht, wurde Scrum von Jeff Sutherland und Ken Schwaber in den 1990er Jahren angepasst und populär gemacht. Es hat sich zu einer zunehmend beliebten Arbeitsweise entwickelt, die sich von der Softwareentwicklung auf viele Bereiche der Produktentwicklung ausgeweitet hat, die von einem iterativen und schrittweisen Ansatz profitieren können. Es steht und fällt mit der technischen Kompetenz und den kollaborativen Bemühungen des Teams.

Aus prozessualer Sicht bietet Scrum einen einfachen und äußerst effektiven agilen Ansatz für die Produktlieferung. Wie später gezeigt wird, ist Scrum nicht dazu gedacht und beschreibt auch nicht einen agilen Ansatz für Projektmanagement.  

Das Framework umfasst drei verschiedene Rollen, die ein Scrum Team bilden, jede mit klar definierten Verantwortlichkeiten, fünf Events und drei Artefakte. Die Regeln, die in The Scrum Guide beschrieben sind, verbinden die Rollen, Events und Artefakte miteinander und leiten ihre Beziehungen und Interaktionen.

• Die 5 Events: Der Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
• Die 3 Artefakte: Product Backlog, Sprint Backlog, Product Increment
• Die 3 Rollen: Product Owner, Developer, Scrum Master.

1. Der Sprint ist eine Zeitbox, die beliebig lang dauern kann, aber typischerweise 2 bis 4 Wochen beträgt, während der ein oder mehrere „fertige" (d.h. nutzbare und zumindest potentiell auslieferbare) Produktinkremente erstellt werden. Der Sprint enthält alle anderen Events.
2. Sprint Planning ist die Veranstaltung, in der die Entwickler die im nächsten Sprint zu erledigende Arbeit planen. Sie handeln mit dem Product Owner ein realistisches Sprint-Ziel aus, wählen geeignete Elemente aus dem Product Backlog aus, die zu diesem Ziel beitragen, und planen die Arbeit, um es zu erreichen.
3. Das Daily Scrum ist ein 15-minütiges Meeting, das von den Entwicklern im Scrum Team abgehalten wird. Es findet jeden Tag des Sprints statt und die Entwickler nutzen es, um ihre Verpflichtung zur Erreichung des Sprint-Ziels zu bekräftigen und ihre Pläne entsprechend anzupassen.
4. Das Sprint Review wird am Ende des Sprints durchgeführt. Sein Zweck ist es, den Stakeholdern sichtbar zu machen, was im Sprint geliefert wurde, damit sie es formal prüfen und Anpassungen am Product Backlog vorschlagen können, um die laufende Entwicklung zu steuern.
5. Die Sprint Retrospective ist eine Gelegenheit für das Scrum Team, über die Effektivität ihrer Arbeitsweise zu reflektieren und einen Plan für Verbesserungen zu erstellen, die während des nächsten oder nachfolgenden Sprints umgesetzt werden sollen.

Die drei Artefakte von Scrum sind darauf ausgelegt, den Fokus auf den zu liefernden Wert aufrechtzuerhalten. Sie sind transparent – das heißt bewusst sichtbar – für jeden, der sich dafür interessiert, was das Scrum Team tut und wie es seine Arbeit angeht. Jedes Artefakt beinhaltet eine Verpflichtung.

Das Product Backlog ist eine geordnete Liste von allem, was getan werden muss, um das Product Goal zu erreichen. Es ist die einzige Arbeitsquelle für das Scrum Team. Obwohl es mehr als ein Product Goal geben kann, zum Beispiel zur Beschreibung einer Produkt-Roadmap, wird jeweils nur an einem Ziel gearbeitet. Das Product Goal ist das Ziel, die Verpflichtung, die das Product Backlog zu erreichen bestimmt ist.

Das Sprint Backlog umfasst die Menge der für einen Sprint ausgewählten Product Backlog Items und alle Arbeiten, die zur Erreichung des Sprint Goals erforderlich sind. Während ein oder mehrere Product Increments während des Sprints geliefert werden können, gibt es nur ein Sprint Goal. Das Sprint Goal ist die Verpflichtung für das Sprint Backlog und das, was die Entwickler zu erreichen anstreben.

Das Product Increment ist das, was die Entwickler erstellen, um den Bedarf zu erfüllen, der durch einen oder mehrere Product Backlog Items beschrieben wird. Es ist ein greifbarer Schritt zur Erreichung des Sprint Goals. Wenn mehr als eines in einem Sprint geliefert wird, beinhaltet jedes Product Increment das vorherige. Die Verpflichtung besteht darin, die "Definition of Done" für das Product Increment zu erreichen. Diese "Definition of Done" ist eine formelle Beschreibung der notwendigen Qualitätsstandards, die das Produkt erfüllen muss.

Wir wissen aus dem Agile Manifesto , dass Praktiker der Agilität Individuen und Interaktionen über Prozesse und Werkzeuge stellen – das bedeutet, dass es zwar einen Platz für Prozesse und Werkzeuge gibt – und seien wir ganz klar, Scrum beinhaltet ein erhebliches Prozesselement – wir schätzen Menschen und die Art, wie sie zusammenarbeiten, jedoch mehr. Die Rollen und Verantwortlichkeiten, die mit diesen Rollen verbunden sind, sowie die kollaborativen Interaktionen zwischen den Individuen, die diese Rollen innehaben, sind grundlegend für die effektive Anwendung von Scrum.

Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und typischerweise zwischen 5 und 9 Entwicklern. Das Team muss funktionsübergreifend sein – gemeinsam über alle Kompetenzen verfügen, die zur Lieferung des gewünschten Produkts erforderlich sind, und die Fähigkeit besitzen, zusammenzuarbeiten, um dieses Ziel zu erreichen. Das Team ist selbstorganisiert – erkennt keine hierarchische Struktur an und lässt Führung für spezifische Arbeiten je nach Bedarf entstehen.

Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren, das aus der Arbeit des Scrum Teams entsteht. Der Product Owner ist eine Einzelperson, kein Komitee, und vertritt typischerweise die Bedürfnisse vieler Stakeholder, einschließlich der Kunden, für die der Wert geschaffen wird. Bei seinem Beitrag zur Arbeit des Scrum Teams ist er für das effektive Product Backlog Management verantwortlich, was Folgendes umfasst:

• Entwicklung und explizite Kommunikation des Product Goals.
• Erstellung und klare Kommunikation von Product Backlog Items.
• Priorisierung von Product Backlog Items.
• Sicherstellung, dass das Product Backlog transparent, sichtbar und verständlich ist.

Jeder Stakeholder, der das Product Backlog ändern möchte, kann dies nur über den Product Owner tun.

Developer

Die Developer-Rolle im Scrum Team gilt für jeden, der aktiv mit anderen im Team zusammenarbeitet, um das Produkt zu entwickeln – sogar jemand, der auch eine der anderen Rollen innehat, kann ein Developer sein. Die von einem Developer benötigten Fähigkeiten variieren je nach Art der ausgeführten Arbeit und dem, was produziert wird. Developer, die in einem Scrum Team arbeiten, um einen Garten zu gestalten, benötigen völlig andere Fähigkeiten als die, die eine aufwendige Dinnerparty vorbereiten oder ein neues Spiel für ein Smartphone entwickeln. Scrum kann in all diesen Entwicklungsumgebungen angewendet werden.

In Scrum sind Developer immer verantwortlich für:

• Erstellung eines Plans für den Sprint, das Sprint Backlog;
• Gewährleistung von Qualität durch Einhaltung einer Definition of Done;
• Anpassung ihres Plans jeden Tag in Richtung Sprint Goal; und
• Gegenseitige Verantwortlichkeit als Fachkräfte.

Scrum Master

Der Scrum Master ist dafür verantwortlich, Scrum so zu etablieren, wie es im Scrum Guide definiert ist. Dies tun sie, indem sie allen helfen, die Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.

Oft als dienende Führungskraft bezeichnet, besitzt der Scrum Master keine Befehlsgewalt – er sagt den Menschen nicht, was sie tun und wie sie sich verhalten sollen, sondern hilft ihnen zu verstehen, wie Scrum funktionieren sollte, und tut alles, um dessen Einführung zu erleichtern. Er bietet einen Service für:

• Das Scrum Team – Coaching ihrer Scrum-Einführung, Unterstützung beim Finden von Wegen zur kontinuierlichen Verbesserung der Art, wie sie Wert liefern, und Beseitigung von allem, was dem im Weg steht.
• Den Product Owner – Unterstützung beim Product Backlog Management und Hilfe dabei sicherzustellen, dass Product Goals und Product Backlog Items richtig geformt, ausgedrückt und verstanden werden.
• Die breitere Organisation, in der das Scrum Team existiert – Unterstützung beim Verständnis der Scrum-Arbeitsweise und wie sie arbeiten und sich verhalten müssen, damit Scrum Teams optimal effektiv sein können.

Das Scrum-Framework basiert auf der Theorie der empirischen Prozesskontrolle oder dem Empirismus, der besagt, dass Wissen aus Erfahrung entsteht und Entscheidungsfindung auf dem beruht, was beobachtet werden kann. Die Säulen der empirischen Prozesskontrolle sind Transparenz von Prozess und Fortschritt, Inspektion von Prozess und Fortschritt und Anpassung sowohl des entstehenden Produkts (es mit jeder Iteration und jedem Inkrement besser machen) als auch der Arbeitsweise (kontinuierliche Verbesserung der Teameffektivität und -leistung).

Es ist wichtig zu verstehen, wie man den empirischen Prozess effektiv gestaltet. Transparenz ermöglicht Inspektion, Inspektion ermöglicht Anpassung und Anpassungen müssen transparent sein. Inspektion ohne Transparenz ist irreführend und verschwenderisch, Inspektion ohne Absicht zur Anpassung ist sinnlos und Anpassung ohne Transparenz zur Inspektion ihrer Auswirkungen macht Anpassung riskant.

Effektive Scrum-Teams leben und atmen eine Reihe von fünf Werten. Diese Werte sind nicht einzigartig für ein Scrum-Team, aber indem sie explizit gemacht werden, fördern sie eine effektive, kollaborative teambasierte Arbeitsweise. Die Werte sind Commitment, Focus, Openness, Respect und Courage.

• Commitment: Scrum-Teammitglieder sind dem Erreichen von Sprint-Zielen und der Lieferung hochwertiger Arbeit durch iterative Entwicklung und inkrementelle Auslieferung verpflichtet. Dies fördert Verantwortung und Rechenschaftspflicht unter den Teammitgliedern.
• Courage: Scrum-Teammitglieder haben den Mut, Herausforderungen und Hindernisse offen anzugehen. Sie sind bereit, Risiken einzugehen und sich zu Problemen zu äußern, die den Erfolg des Teams beeinträchtigen könnten.
• Openness: Scrum-Teammitglieder teilen Informationen, Fortschritte und Bedenken untereinander, wodurch Vertrauen und Zusammenarbeit innerhalb des Teams gefördert werden.
• Focus: Scrum-Teammitglieder bewahren einen kollektiven Fokus auf Produkt- und Sprint-Ziele und priorisieren ihre Arbeit, um ihre Wertschöpfung zu optimieren.
• Respect: Scrum-Teammitglieder respektieren einander als Fachkräfte und erkennen die Fähigkeiten, Perspektiven und Beiträge der anderen bei der Produktentwicklung an. Dies schafft ein positives Arbeitsumfeld und verstärkt die Zusammenarbeit unter den Teammitgliedern.

Diese Werte können und sollten angewendet werden, um jede agile Arbeitsweise effektiv zu gestalten.

Die Scrum-Werte tragen gemeinsam zur Fähigkeit des Scrum-Teams bei:

• Sich an Veränderungen anzupassen: Scrum reagiert sehr flexibel auf sich ändernde Anforderungen. Es berücksichtigt sich entwickelnde Kundenbedürfnisse, indem es Anpassungen am Ende jedes Sprints ermöglicht und dadurch Flexibilität und größere Kundenzufriedenheit fördert.
• Gemeinsam Entscheidungen zu treffen: Die selbstorganisierende Natur des Scrum-Teams und die empirische Grundlage der Scrum-Arbeitsweise fördern die Zusammenarbeit. Das Leben der Scrum-Werte erweckt kollaboratives Arbeiten zum Leben.  
• Sich kontinuierlich zu verbessern: Scrum beinhaltet regelmäßige Retrospektiven – deren Zweck es ist, dem Scrum-Team regelmäßige Gelegenheiten zu bieten, die Effektivität ihrer Arbeitsweise zu überprüfen und Verbesserungsbereiche zu identifizieren. Das ist kontinuierliche Verbesserung in Aktion.
• Einen kundenorientierten Ansatz zu verfolgen: Scrum legt großen Wert auf die Wertschöpfung für den Kunden. Der Product Owner, der die Kundeninteressen vertritt, priorisiert Features und stellt sicher, dass das Produkt während seiner gesamten Entwicklung den Kundenbedürfnissen und -erwartungen entspricht.

Scrum bietet zahlreiche Vorteile für die Produktentwicklung und verbessert Effizienz, Zusammenarbeit und Anpassungsfähigkeit:

• Flexibilität
• Schnellere Markteinführung
• Verbesserte Zusammenarbeit
• Erhöhte Produktqualität
• Gesteigerte Kundenzufriedenheit
• Höhere Produktivität
• Besseres Risikomanagement
• Transparenz
• Gestärkte Teams
• Kontinuierliche Verbesserung.

Erfahren Sie mehr über die 10 wichtigsten Vorteile von Scrum, die in diesem Blog ausführlich erläutert werden.

Scrum kann verschiedene Herausforderungen und Nachteile mit sich bringen. Bei der Einführung von Scrum kann es, wie bei allen neuen Arbeitsweisen, zu Widerstand gegen Veränderungen kommen. Teams können mit dem Maß an Zusammenarbeit und Kommunikation kämpfen, das erforderlich ist, damit Scrum effektiv funktioniert. Rollen wie der Scrum Master haben auch spezifische Verantwortlichkeiten, die sich von traditionellen Rollen unterscheiden, und das Missverständnis dieser Rollen kann zu Verwirrung und Ineffizienz führen. Sobald Scrum implementiert ist, müssen noch immer Herausforderungen bewältigt werden. Häufige Risiken oder Nachteile sind:-

1. Unzureichende Unterstützung durch das Management: Wie bei jeder Veränderungsinitiative ohne starke Unterstützung durch das Management innerhalb der Organisation wird die Einführung von Scrum auf Widerstand stoßen oder Schwierigkeiten bei der Überwindung organisatorischer Barrieren haben. Mangelndes Verständnis für den notwendigen kulturellen Wandel und schwache Verpflichtung dazu auf höheren Ebenen können den Wert, den Scrum als Arbeitsweise liefern kann, erheblich begrenzen.
2. Lernkurve: Anfängliche Störungen und Anpassungen können die Produktivität beeinträchtigen, während sich Teammitglieder an die neuen Rollen, Ereignisse und kollaborativen Prozesse gewöhnen, die Scrum einführt. Der Spruch, dass die Dinge schlechter werden können, bevor sie besser werden, trifft oft zu. Der Schlüssel liegt darin, Zeit zum Lernen einzuräumen und Menschen zu identifizieren, die nachweislich Erfolg damit hatten, dies anderswo umzusetzen und helfen können.
3. Selbstüberschätzung:  Teams können dem Risiko ausgesetzt sein, sich während der Sprint-Planung zu viel Arbeit vorzunehmen, was zu Burnout oder Qualitätseinbußen bei den Ergebnissen führt. Das Gleichgewicht zwischen dem Wunsch nach schnellem Fortschritt und realistischer Zielsetzung ist entscheidend für die Aufrechterhaltung nachhaltiger Entwicklungspraktiken. Es ist wichtig, ein nachhaltiges Tempo zu etablieren – erwarten Sie Misserfolge beim Erreichen der Sprint-Ziele, während das Team herausfindet, was erreicht werden kann.
4. Überbetonung kurzfristiger Ziele: Der Fokus auf kurze, festlänge Sprints in Scrum kann manchmal zu einer kurzsichtigen Sichtweise führen, bei der Teams unmittelbare Ziele über langfristige strategische Ziele stellen. In einer reinen Produktumgebung sollte ein guter Product Owner in der Lage sein, einen angemessenen langfristigen Fokus zu kommunizieren und aufrechtzuerhalten. Wenn die Komplexität eine Herausforderung darstellt, könnte mehr erforderlich sein...
5. Probleme bei der Integration der Arbeit mehrerer Teams für größere, komplexere Vorhaben: Scrum ist stark, wenn es auf einzelne Teams angewendet wird, aber extrem schwach, wenn die zu erledigende Arbeit die Kapazität der „10 oder weniger" Personen im Team übersteigt, um sie zu bewältigen. In diesem Fall wird ein breiteres Framework zur Bewältigung von Größe und/oder Komplexität empfohlen.

Für extreme Größenordnungen in einem Produktkontext – wo Hunderte von Entwicklern benötigt werden – könnte ein skaliertes Framework wie SAFe ratsam sein. Für kleinere Probleme – bis zu 100 Entwickler zum Beispiel – und/oder wo die Komplexität der gesamten Geschäftslösung mehrere Produkte, Services und andere Aktivitäten umfasst, wird ein agiles Projekt-Framework wie AgilePM den Bedarf decken.  

Aufbauend auf dem oben erwähnten Skalierungsproblem beantworten in dieser Folge von APMGs „Level Up"-Serie Experten für agiles Projektmanagement Fragen zu agilem Projektmanagement und Scrum. Eine der wichtigsten Fragen, die behandelt wird, ist der Unterschied zwischen diesen Ansätzen.  Themen wie Sprint-Planung, die ideale Länge eines Sprints und der Wert von täglichen Stand-ups werden diskutiert.

Das Agile Business Consortium hat seinen weltführenden Agile Project Management-Ansatz (AgilePM) weiterentwickelt, um eine Version anzubieten, die speziell für die Zusammenarbeit mit Scrum konzipiert wurde. AgilePM for Scrum bietet ein einheitliches Framework für die Bereitstellung vollständiger Geschäftslösungen. Es behandelt explizit Lösungen, die mehrere Produkte oder Dienstleistungen umfassen und die kombinierte Entwicklungsarbeit mehrerer Scrum-Teams oder eine Kombination aus Scrum- und Nicht-Scrum-Teams erfordern. Mit Techniken für die agile teamübergreifende Planung und Koordination, Führung aus den Blickwinkeln der Geschäftsvision, Lösungsarchitektur und Projektmanagement, Governance, Risiko und mehr ist dies durchaus überlegenswert für komplexere Projektsituationen.

In diesem Video diskutieren Richard Pharro, CEO von APMG International, und ich über 'AgilePM for Scrum.' Dieses neue Framework vereint die Stärken zweier führender Agile-Frameworks. Richard stellt wichtige Fragen mit dem Ziel, Einblicke in das Framework zu geben, einschließlich seines Umfangs, der Begründung für seine Entwicklung und wer am meisten von dem Framework profitiert. Zusätzlich erkunden wir das akkreditierte Schulungs- und Zertifizierungsprogramm, das dieses Framework unterstützt.

Scrum hat einen bedeutsamen Weg für Agilität in der Softwareproduktentwicklung geebnet und ist aus gutem Grund ein sehr beliebter und vielseitiger Ansatz, da er perfekt dafür geeignet ist, Produkte zu liefern, die Kunden angesichts komplexer und sich entwickelnder Anforderungen begeistern. Es nutzt die Vorteile von funktionsübergreifenden, kollaborativen Teams, um Wert schneller und effizienter zu liefern als ihre weniger agilen Gegenstücke.

Es ist jedoch nicht ohne Herausforderungen... Ken Schwaber und Jeff Sutherland stellen in ihrem Scrum Guide 2020 fest, dass „Das hier beschriebene Scrum-Framework ist unveränderlich. Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis kein Scrum. Scrum existiert nur in seiner Gesamtheit…"

Scrum ist ein einfaches, elegantes, effektives agiles Framework für die Produktlieferung. Dies wurde immer wieder auf der ganzen Welt in vielen verschiedenen Anwendungen in vielen verschiedenen Branchen bewiesen, aber nur, wenn es in seiner Gesamtheit verwendet wird. Wenn Sie ein Element von Scrum weglassen, wird es einfach nicht richtig funktionieren. Scrum funktioniert, ScrumBut birgt das Risiko des Scheiterns. ScrumBut beschreibt eine Situation, in der „wir verwenden Scrum, aber wir machen das nicht".  Für „wir machen das nicht" setzen Sie ein, was Sie möchten… „Wir machen kein tägliches Scrum", „wir arbeiten nicht zusammen", „wir haben keinen Scrum Master, wir haben einen Manager", „wir haben kein Product Backlog, wir haben eine Spezifikation", „wir definieren kein Sprint Goal" usw. Schwaber und Sutherland haben Scrum entwickelt, haben seine schrittweise und sorgfältige Entwicklung seit Mitte der 1990er Jahre überwacht – akzeptieren Sie ihre Weisheit und machen Sie es richtig.  

Wenn Ihr Geschäft die Produktentwicklung ist, dann ist es leicht zu sehen, wie das Einbringen von Agilität in dieses Geschäft durch die Anwendung und kontinuierliche Verbesserung der Anwendung von Scrum enormen Nutzen bringen könnte. Aber wenn Ihre Sorge über die reine Produktentwicklung hinausgeht, dann könnte sich Scrum allein als unzureichend erweisen.

Schulungen, Bildung und kontinuierliche Ermutigung und Unterstützung von Scrum Teams sind nötig, um den Erfolg von Scrum zu nutzen. APMG bietet die folgenden Zertifizierungen für die Schlüsselrollen an.

Dieser Kurs lehrt Sie, als Scrum Master zu glänzen und die Produkt- und Lösungsentwicklung mit Scrum zu verbessern. Zu den wichtigsten Lerninhalten gehören ein umfassendes Verständnis des Scrum-Frameworks, der Scrum-Prinzipien und der Rolle des Scrum Masters. Sie lernen auch, wie Sie effektive Entwicklungsteams aufbauen, als dienende Führungskraft agieren, Scrum-Events moderieren, Product Owner bei der Backlog-Verwaltung unterstützen und die Einführung von Scrum vorantreiben.

In diesem Kurs lernen Sie, wie Sie den Wert von Produkten maximieren, die von Scrum Teams geliefert werden. Gewinnen Sie ein tiefes Verständnis des Scrum Frameworks und der Rolle des Scrum Product Owners. Meistern Sie die Scrum-Prinzipien und lernen Sie, wie Sie ein wertorientiertes Product Backlog aufbauen und priorisieren, indem Sie Epics und Themes in umsetzbare User Stories aufteilen.

Der erste Tag sowohl des Scrum Master- als auch des Product Owner-Kurses ist identisch – sprechen Sie mit Ihrem APMG-Schulungsanbieter über die Durchführung dieses Tages als eigenständigen Kurs, der ideal für Teammitglieder und Stakeholder ist. Er deckt alles im Scrum Guide ab – und sie müssen alles wissen.   

AgilePM for Scrum kombiniert Scrum mit dem weltweit führenden agilen Projektmanagement-Ansatz (AgilePM) und bietet ein einheitliches Framework für die Bereitstellung vollständiger Geschäftslösungen, bei denen iterative und inkrementelle Entwicklung erforderlich ist. Diese Zertifizierung vermittelt Ihnen die Fähigkeiten, Scrum in das Agile Project Management zu integrieren. Die Kurse behandeln die Prinzipien und die Theorie, die dem Scrum-Framework zugrunde liegen – durchgeführt von APMG- und Agile Business Consortium-akkreditierten Anbietern.

Das Bild des 'Scrum Framework' wurde vom Agile Business Consortium erstellt. Copyright © 2024, Agile Business Consortium. Alle Rechte vorbehalten.