Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: epubli
- Kategorie: Fachliteratur
- Sprache: Deutsch
Was passiert, wenn ein Autor Team Scrum nicht nur beschreibt, sondern selbst erlebt? Dieses Buch ist mehr als ein Theorieband – es ist ein Praxisexperiment. Acht Menschen, ein Ziel: Ein Buch über Scrum schreiben – mit Scrum als Methode. Kapitel für Kapitel entstehen Reflexionen, Erfahrungen, Fehler und echte Fortschritte. MetaScrum dokumentiert diesen Weg: ehrlich, selbstorganisiert, iterativ. Das Ergebnis ist ein Buch, das den Scrum Guide nicht nur zitiert – sondern ihn lebt. Theorie trifft auf gelebte Praxis, Rollen auf echte Menschen, Artefakte auf kollaborative Entscheidungsprozesse. Für Scrum-Beginner, agile Teams, Lehrende, Studierende und alle, die Scrum nicht nur verstehen, sondern erleben möchten.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 281
Veröffentlichungsjahr: 2025
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Hinweis zur gendergerechten Formulierung
Im folgenden Sachbuch wird aus Gründen der besseren Lesbarkeit das generische Maskulinum verwendet. Dies impliziert keine Benachteiligung des weiblichen Geschlechts, sondern soll im Sinne der sprachlichen Vereinfachung als geschlechtsneutral zu verstehen sein. Weibliche und anderweitige Geschlechteridentitäten werden dabei ausdrücklich mitgemeint, soweit es für die Aussage erforderlich ist.
Vorwort
1Einstieg in Scrum
1.1Einführung in Scrum
1.1.1Die Entstehung von Scrum
1.1.2Scrum als Antwort auf gescheiterte Planungsmodelle
1.1.3Ein Framework, keine Methode
1.1.4Die Werte von Scrum: Haltung als Fundament
1.1.5Das Scrum-Framework im Überblick
1.1.6Vergleich: Agile vs. Traditionelle Entwicklung
1.2Unsere Umsetzung: So sind wir gestartet
1.2.1Teambildung und unsere ersten Schritte als Scrum Team
1.2.2Rollenverteilung im Team
1.2.3Unsere Werkzeuge: Tools & Dokumentation
1.2.4Rahmenbedingungen & Kommunikation
1.2.5Herausforderungen und Lernprozesse
1.2.6Zusammenfassung der Startphase
1.3Persönliche Eindrücke zum Scrum & Projektstart
1.3.1Product Owner: Gagan
1.3.2Scrum Master: Trang
1.3.3Developer: Daniel
1.3.4Developer: Olivera
1.3.5Developer: Jonathan
1.3.6Developer: Paul
1.3.7Developer: Dilara
1.3.8Developer: Christos
2Scrum-Rollen
2.1Theorie der Scrum-Rollen
2.1.1Scrum Team
2.1.2Product Owner
2.1.3Scrum Master
2.1.4Developer
2.2Unsere Umsetzung: Rollenverteilung, Verantwortung und Teamstruktur
2.2.1Abweichungen vom Scrum Guide
2.2.2Teamgröße, Rollenauswahl & Interdisziplinarität
2.2.3Die Rollen in Aktion: Unsere 5 Learnings
2.3Persönliche Reflexionen: Scrum-Rollen
2.3.1Product Owner: Gagan
2.3.2Scrum Master: Trang
2.3.3Developer: Daniel
2.3.4Developer: Olivera
2.3.5Developer: Jonathan
2.3.6Developer: Paul
2.3.7Developer: Dilara
2.3.8Developer: Christos
3Scrum Events
3.1Theorie der Scrum Events
3.1.1Sprint
3.1.2Sprint Planning
3.1.3Daily Scrum
3.1.4Sprint Review
3.1.5Sprint Retrospective
3.2Unsere Umsetzung: Meeting-Praxis und Abweichungen
3.2.1Abweichungen vom Scrum-Standard
3.2.2Scrum-Events in unserem Projektalltag
3.3Persönliche Reflexionen: Scrum Events
3.3.1Product Owner: Gagan
3.3.2Scrum Master: Trang
3.3.3Developer: Daniel
3.3.4Developer: Olivera
3.3.5Developer: Jonathan
3.3.6Developer: Paul
3.3.7Developer: Dilara
3.3.8Developer: Christos
4Scrum-Artefakte
4.1Theorie der Scrum-Artefakte
4.1.1Produkt Backlog
4.1.2Sprint Backlog
4.1.3Increment
4.1.4Zusammenhänge und Wechselwirkungen des Scrum-Frameworks
4.2Unsere Umsetzung: Scrum-Artefakte in der Praxis
4.2.1Produkt Backlog & Produkt-Ziel
4.2.2Sprint Backlog & Sprint-Ziel
4.2.3Increment & Definition of Done
4.3Persönliche Reflexionen: Scrum-Artefakte
4.3.1Product Owner: Gagan
4.3.2Scrum Master: Trang
4.3.3Developer: Daniel
4.3.4Developer: Olivera
4.3.5Developer: Jonathan
4.3.6Developer: Paul
4.3.7Developer: Dilara
4.3.8Developer: Christos
5Scrum in der Praxis: Best Practices
5.1Theoretischer Überblick: Schätzung, Velocity und Teamarbeit
5.1.1Story Points
5.1.2Schätzung: Methoden und Herausforderungen
5.1.3Burndown Chart & Burnup Chart
5.1.4Velocity: Planung und Steuerung der Teamleistung
5.1.5Teamarbeit und Selbstorganisation
5.1.6Kommunikation als Grundlage erfolgreicher Zusammenarbeit
5.2Unsere Umsetzung: Anwendung der Best Practices
5.2.1Story Points im Projektalltag
5.2.2Schätzen in der Praxis: Erfahrungswissen vs. Planning Poker
5.2.3Burndown Chart & Burnup Chart: Sprint 8 als Beispiel
5.2.4Velocity in der Realität: Schwankungen und Stabilisierung
5.2.5Teamarbeit unter Remote-Bedingungen
5.2.6Abweichungen vom Scrum Guide
6Zukünftige Entwicklungen
6.1Aktuelle Trends im Scrum & Agile Umfeld
6.1.1Trends in Agilität
6.1.2Tech-Integration
6.1.3Remote Work
6.1.4Hype, Realität und Grenzen von Scrum
6.2Unsere Zusammenarbeit: Chancen & Herausforderungen
6.2.1Stärken moderner Zusammenarbeit im Projekt
6.2.2Herausforderungen und Potenziale zur Optimierung
6.2.3Auf dem Weg zu agiler Reife
7Künstliche Intelligenz in Scrum-Projekten
7.1KI-Unterstützung in Scrum
7.1.1Aktuelle KI-Tools im Scrum-Umfeld
7.1.2KI-Anwendungsfelder für den Product Owner
7.1.3KI-Anwendungsfelder für den Scrum Master
7.1.4KI-Anwendungsfelder für die Developer
7.1.5Vorteile und Risiken der KI-Unterstützung je Rolle
7.1.6Veränderung der Rollenverteilung im Scrum-Team durch KI
7.1.7Spezialisierte Scrum KI-Modelle in der Praxis
7.2Unsere Anwendung von KI im Buchprojekt nach Rollen
7.2.1Einsatz von KI für Product Owner
7.2.2Einsatz von KI für Scrum Master
7.2.3Einsatz von KI für Developer
7.3Erkenntnisse und Empfehlungen für den KI-Einsatz im Scrum-Kontext
7.3.1Die Rolle von gutem Prompt Engineering
7.3.2Fallstricke vermeiden
7.3.3Lernschleifen und Fazit zur KI-Nutzung
8Rückblick & Lernerfahrungen
8.1Projektrückblick aus Team-Perspektive
8.2Theorie trifft Praxis: Abweichungen, Gründe, Wirkungen
8.3Drei größte Learnings als Gruppe zusammengefasst
8.4Empfehlungen für zukünftige Teams
Literaturverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Glossar (alphabetisch sortiert)
Abkürzungsverzeichnis
Über die Autoren
Vorwort
Dieses Buch stellt einen bemerkenswerten Beitrag zur wissenschaftlichen und praktischen Auseinandersetzung mit agilen Arbeitsweisen dar. Es verbindet in einzigartiger Weise theoretische Fundierung mit praktischer Umsetzung, indem Scrum nicht nur als Forschungsgegenstand behandelt, sondern zugleich als Organisationsrahmen für die Entstehung des Werkes selbst angewandt wurde. Damit ist es nicht nur ein Buch über Scrum, sondern auch ein Beispiel für Scrum in Aktion – ein Ansatz, der seine eigene Methodik kritisch überprüft und erlebbar macht.
Besonders hervorzuheben ist die methodische Strenge, mit der zentrale Konzepte des Frameworks analysiert und in den Kontext aktueller wissenschaftlicher Diskussionen gestellt werden. Beginnend mit einer fundierten Darstellung der Entstehungsgeschichte von Scrum und seiner Abgrenzung zu klassischen Projektmanagement-Modellen, über die differenzierte Betrachtung der Rollen, Ereignisse und Artefakte, bis hin zu Best Practices, Herausforderungen und Fehlerkulturen, liefert das Werk eine umfassende und zugleich kritische Analyse. Zahlreiche Bezüge zu empirischen Studien, relevanter Fachliteratur und praxisnahen Fallbeispielen unterstreichen den wissenschaftlichen Anspruch.
Darüber hinaus öffnet das Buch den Blick für die Zukunft agiler Arbeitsweisen. Besonders hervorzuheben ist das Kapitel zu Künstlicher Intelligenz in Scrum-Projekten, das nicht nur die Chancen, sondern auch die Risiken neuer Technologien reflektiert. Damit wird deutlich: Agilität ist kein statisches Konzept, sondern ein dynamisches Feld, das in engem Wechselspiel mit technologischen, gesellschaftlichen und kulturellen Entwicklungen steht. Dieses Werk leistet somit einen wichtigen Beitrag zu einer Debatte, die in den kommenden Jahren an Relevanz weiter zunehmen wird.
Seine Stärke liegt nicht zuletzt in der Reflexion der Teammitglieder selbst. Die zahlreichen persönlichen Eindrücke und Lernprozesse machen die theoretischen Ausführungen greifbar und verdeutlichen, dass Scrum mehr als ein Prozessmodell ist – es ist ein kulturelles Transformationsinstrument. Gerade diese Verbindung von Wissenschaft, Praxis und persönlicher Erfahrung macht das Buch wertvoll für ein breites Publikum: für Forschende, die die Weiterentwicklung agiler Ansätze untersuchen, ebenso wie für Praktiker, die konkrete Orientierung für ihre Arbeit suchen.
Ich bin überzeugt, dass dieses Buch nicht nur eine solide Einführung in Scrum bietet, sondern auch neue Impulse für die Weiterentwicklung agiler Methoden setzt. Es zeigt, wie wissenschaftliche Strenge, praktische Relevanz und gesellschaftliche Verantwortung in einem Werk zusammengeführt werden können.
Leser gewinnen dadurch nicht nur ein tieferes Verständnis für die Mechanismen agiler Zusammenarbeit, sondern auch Inspiration für die Gestaltung zukünftiger Projekte in einer zunehmend komplexen Welt.
Frankfurt am Main, den 26.08.2025
Dr. Joerg Storm
Über den Autor des Vorworts
Dr. Joerg Storm ist CEO von Digital STORM, einem führenden Unternehmen im Bereich digitaler Transformation und KI-Kommunikation. Zuvor verantwortete er als CIO der Mercedes-Benz After-Sales-Geschäfte in China sowie für Taiwan und Hongkong den Aufbau und Betrieb sämtlicher globaler und lokaler Sales- & After-Sales-Anwendungen. In dieser Rolle leitete er zahlreiche digitale Innovationsinitiativen in der Region und war später als Global Head IT Infrastructure bei Mercedes-Benz Mobility tätig.
Mit über 25 Jahren internationaler Erfahrung in den Bereichen IT, Strategie, Sales, Audit und Innovation – unter anderem mit Auslandseinsätzen in Japan, den USA und China – zählt Dr. Storm zu den profiliertesten Digitalisierungsexperten seiner Branche. Als promovierter Ökonom, PMP-zertifizierter Projektmanager und Intercultural Management Professional unterstützt er Unternehmen weltweit dabei, ihre digitale Zukunft zu gestalten.
Neben seiner Tätigkeit als Executive und Berater ist Dr. Storm auch einer der größten Tech-Influencer im deutschsprachigen Raum: Er erreicht über 1,3 Millionen Follower auf LinkedIn sowie mehr als 540.000 Abonnenten seines wöchentlichen KI-Newsletters „Digital STORM“. Seine Beiträge werden regelmäßig von Entscheidungsträgern führender Unternehmen wie Apple, Meta, Google und Microsoft gelesen.
Wir freuen uns besonders, dass Dr. Joerg Storm unser Buchprojekt unterstützt und mit seinem Vorwort die Brücke zwischen Theorie, Praxis und Zukunft der digitalen Transformation schlägt.
Hinweis zum Projektkontext und Aufbau des Buches
Dieses Buch ist im Rahmen des Moduls Agile Projektarbeit an der Provadis School of International Management and Technology entstanden. Das Projekt lief vom 24. April bis zum 20. September 2025 und hatte das Ziel, Scrum nicht nur theoretisch zu erlernen, sondern in einem realen Team-Setup praktisch umzusetzen und die Erfahrungen in Form eines Buches zu dokumentieren.
Unser Team bestand aus acht berufstätigen Teilzeitstudierenden, die parallel zu diesem Projekt einer durchschnittlichen Arbeitsbelastung von rund 32 Stunden pro Woche und weiteren Studienmodulen nachgingen. Diese Rahmenbedingungen haben unsere Arbeitsweise maßgeblich geprägt. Wir haben Scrum als Fundament und verbindliches Rahmenwerk genutzt und gleichzeitig dort pragmatische Anpassungen vorgenommen, wo es die Situation erforderlich machte. Alle Abweichungen sind in diesem Buch transparent beschrieben und begründet.
Das Werk folgt einer klaren Struktur:
Theorieabschnitte stellen die zentralen Elemente von Scrum vor – Rollen, Artefakte, Events, Prinzipien und Praktiken.
Praxisabschnitte beschreiben, wie wir diese Elemente im Rahmen unseres Projekts umgesetzt haben, wo wir vom Standard abgewichen sind und welche Erfahrungen wir dabei gemacht haben.
Reflexionen und Lessons Learned bieten persönliche Einblicke der Teammitglieder, zeigen individuelle Lernkurven und leiten Handlungsempfehlungen für künftige Projekte ab.
Neben der fachlichen Tiefe lebt dieses Buch vor allem von seiner Authentizität. Es verbindet die klare Struktur des Scrum-Frameworks mit unseren ganz persönlichen Erfahrungen im Projektalltag. Leserinnen und Leser erhalten dadurch nicht nur theoretisches Wissen, sondern auch ehrliche Einblicke in Herausforderungen, Umwege und Lösungsansätze, die so in keinem Lehrbuch stehen. Die theoretischen Abschnitte liefern dabei eine fundierte Einführung in Scrum und greifen zugleich aktuelle Trends in Agilität sowie den Einsatz von Künstlicher Intelligenz in agilen Projekten auf. Gerade diese Kombination aus Praxisnähe, Reflexion und Transparenz macht das Werk besonders spannend und wertvoll – sowohl für Einsteiger in Scrum als auch für erfahrene Praktiker, die Lust auf frische Perspektiven haben.
Damit möchten wir sowohl einen Beitrag zur wissenschaftlichen Auseinandersetzung mit Scrum leisten als auch praktische Orientierung für Studierende, Teams und Organisationen bieten, die selbst mit agilen Methoden arbeiten oder beginnen möchten.
Im ersten Kapitel geben wir einen Überblick über Scrum: seine Entstehung, Werte und Prinzipien sowie die Abgrenzung zum klassischen Wasserfallmodell. Außerdem berichten wir, wie wir als Team gestartet sind, welche Tools und Rahmenbedingungen wir wählten und welche ersten Eindrücke uns geprägt haben.
Scrum ist heute eines der bekanntesten agilen Frameworks für Projektmanagement, besonders in der Softwareentwicklung. Seine Ursprünge reichen zurück in die frühen 1990er-Jahre, als klassische Methoden wie das Wasserfallmodell zunehmend an ihre Grenzen gerieten. In dieser Zeit suchten Jeff Sutherland und Ken Schwaber nach einem neuen Ansatz, um den Herausforderungen moderner, komplexer und dynamischer Entwicklungsprojekte besser begegnen zu können. Ziel war ein agiles Framework, das mehr Flexibilität, Transparenz und kontinuierliche Verbesserung ermöglicht (Schwaber & Sutherland, 2020).
Jeff Sutherland entwickelte erste Scrum-Ansätze gemeinsam mit seinem Team bei der Firma Easel Corporation. Parallel dazu arbeitete Ken Schwaber mit seinem Unternehmen Advanced Development Methods an vergleichbaren Konzepten. Beide verfolgten zunächst unabhängige Entwicklungen, kamen jedoch im Rahmen von Fachkonferenzen und durch den zunehmenden Austausch über agile Methoden in Kontakt. Dabei stellten sie fest, dass ihre Ansätze viele Gemeinsamkeiten aufwiesen, insbesondere in Bezug auf iterative Zyklen, selbstorganisierte Teams und empirische Prozesssteuerung. Aus dieser inhaltlichen Nähe entwickelte sich eine Zusammenarbeit, die schließlich zur gemeinsamen Entwicklung des Scrum-Frameworks führte (Rigby, Sutherland & Takeuchi, 2016).
1995 präsentierten Sutherland und Schwaber ihr gemeinsames Modell erstmals auf der OOPSLA-Konferenz in Texas in ihrem Paper The Scrum Software Development Process (Sutherland & Schwaber, 1995). Im Zentrum stand ein Ansatz, der sich deutlich von traditionellen Planungsmodellen unterschied. Der Scrum Guide bezeichnet Scrum daher auch als ein „leichtgewichtiges Rahmenwerk“ (lightweight framework), das Teams hilft, „wertvolle Produkte durch adaptive Lösungen für komplexe Probleme“ zu liefern (Schwaber & Sutherland, 2020). Mit „leichtgewichtig“ ist gemeint, dass Scrum bewusst nur das unbedingt Notwendige vorgibt wie beispielsweise Rollen, Ereignisse und Artefakte, um gleichzeitig hohe Anpassungsfähigkeit und Klarheit zu schaffen (Kniberg, 2010).
Die theoretische Grundlage von Scrum reicht jedoch noch weiter zurück: Bereits im Jahr 1986 beschrieben die japanischen Managementtheoretiker Hirotaka Takeuchi und Ikujirō Nonaka in ihrem Artikel The New New Product Development Game ein neues Verständnis von Teamarbeit in innovationsgetriebenen Prozessen (Takeuchi & Nonaka, 1986). Sie prägten den Begriff „Scrum“ in Anlehnung an das gleichnamige Element im Rugby, bei dem das Team koordiniert und geschlossen agiert – ein Sinnbild für interdisziplinäre Zusammenarbeit, Eigenverantwortung und kontinuierliche Verbesserung.
In den Jahren nach der ersten Veröffentlichung entwickelten Sutherland und Schwaber das Framework kontinuierlich weiter. Seit 2010 veröffentlichen sie den Scrum Guide, der die offiziellen Definitionen, Rollen, Events und Artefakte von Scrum enthält (Schwaber & Sutherland, 2010). Der Guide wird nicht regelmäßig im Sinne eines festen Rhythmus veröffentlicht, sondern bei Bedarf aktualisiert. In der Regel im Abstand von mehreren Jahren, wenn die Praxis neue Anforderungen oder Erkenntnisse liefert (Marquardt, 2023). Wesentliche Versionen erschienen in den Jahren 2011, 2013, 2017 und zuletzt 2020. Besonders die Überarbeitung von 2020 betont die Reduktion auf das Wesentliche, die Vereinfachung der Sprache sowie die Einführung der sogenannten Commitments zu den Artefakten: Product Goal, Sprint Goal und Definition of Done (Schwaber & Sutherland, 2020).
Die Entwicklung von Scrum war nicht nur theoretisch motiviert, sondern vor allem eine praktische Antwort auf die weitverbreiteten Probleme klassischer Projektmethoden. Besonders das Wasserfallmodell, das auf umfassender Vorabplanung und linearer Abarbeitung basiert, zeigte in dynamischen Projektumgebungen wie der Softwareentwicklung erhebliche Schwächen (Royce, 1970). Anforderungen änderten sich oft während der Umsetzung, doch das Modell ließ nur begrenzte Reaktion darauf zu. Die Folge: verspätete Lieferungen, überschrittene Budgets und Ergebnisse, die häufig nicht den Erwartungen entsprachen.
Studien belegen die Dimension dieses Problems. Der Chaos Report der Standish Group (1994) sprach von Kostenüberschreitungen von bis zu 189 Prozent. Auch wenn diese Zahl heute kritisch gesehen wird, zeigen aktuellere Analysen konstante Abweichungen zwischen 30 und 60 Prozent bei Zeit- und Budgetplanung (Bloch, Blumberg & Laartz, 2012). McConnell (1996) schätzt, dass nur rund ein Viertel der IT-Projekte annähernd im Rahmen bleibt. Besonders große Vorhaben sind stark von Unsicherheit betroffen: Jones (2007) stellt fest, dass mit jeder Steigerung um tausend Personenmonate die Kosten im Schnitt um acht Prozent zunehmen.
Auch aus der Praxis gibt es zahlreiche Hinweise auf systematisches Scheitern. Viele Softwareprojekte kämpfen mit weiten Kosten- und Terminüberschreitungen. Oft ist dies das Merkmal von Projektfehlerfolgen (Jones, 2007).
Vor diesem Hintergrund ist Scrum nicht als Alternative im Sinn eines besser geplanten Modells entstanden, sondern als bewusst anderes Vorgehen. Anstatt Kontrolle durch Detailplanung zu erzeugen, setzt Scrum auf kurze, klar strukturierte Zyklen mit regelmäßiger Überprüfung und Anpassung. Diese empirische Prozesssteuerung erlaubt es Teams, flexibel auf neue Erkenntnisse zu reagieren, Verantwortung selbst zu übernehmen und kontinuierlich zu lernen (Schwaber & Sutherland, 2020).
Scrum versteht sich nicht als umfassende Methodik, sondern als Framework – ein bewusst schlanker, strukturierter Rahmen, der Teams Orientierung gibt, ohne konkrete Werkzeuge oder Arbeitspraktiken vorzuschreiben (Schwaber & Sutherland, 2020). Vorgaben bestehen in Form von definierten Rollen, Ereignissen und Artefakten, doch wie diese konkret gefüllt werden, liegt in der Verantwortung des Teams. Dieser offene Charakter macht Scrum flexibel und in unterschiedlichen Kontexten einsetzbar und das nicht nur in der Softwareentwicklung, sondern auch im Marketing, Bildungsbereich oder in der Organisationsentwicklung.
Die Prinzipien von Scrum lassen sich nicht losgelöst vom Agilen Manifest verstehen, das im Jahr 2001 von siebzehn Expertinnen und Experten formuliert wurde, darunter auch Ken Schwaber (Beck et al., 2001). Das Manifest bildet die ideelle Grundlage agiler Frameworks und betont folgende Werte:
Abbildung 1: Die vier Agile Prinzipien
Eigene Darstellung, basiert auf Scrum Guide
Scrum setzt diese Leitlinien operativ um, indem es Strukturen und Rituale etabliert, die diese Werte im Alltag erfahrbar machen. Es bietet keine Anleitung im Detail, aber einen verlässlichen Rahmen, um flexibel und zielgerichtet zusammenzuarbeiten.
Im Zentrum von Scrum steht das Prinzip des Empirismus: Wissen entsteht aus Erfahrung, nicht aus theoretischer Vorhersage. Entscheidungen beruhen auf dem, was tatsächlich beobachtet werden kann und nicht auf Annahmen. Die empirische Prozesssteuerung in Scrum ruht auf drei Säulen:
Transparenz
: Alle relevanten Informationen zum Produkt und zur Arbeit sollen sichtbar und nachvollziehbar sein
Überprüfung
: Regelmäßige Reviews und Besprechungen, etwa das Daily Scrum oder die Sprint-Retrospektive, schaffen Raum für kritische Reflexion
Anpassung
: Wenn Abweichungen oder Verbesserungspotenziale erkannt werden, wird das Vorgehen unmittelbar angepasst (Schwaber & Sutherland, 2020
)
Abbildung 2: Die drei Scrum Säulen
Eigene Darstellung, basiert auf Scrum Guide
Dieses Vorgehen ermöglicht es, mit Unsicherheit produktiv umzugehen, ein entscheidender Vorteil gegenüber linearen Modellen.
Scrum basiert auf einem iterativen und inkrementellen Vorgehen. Produkte entstehen in kleinen, funktionsfähigen Schritten. Jeder Sprint liefert ein neues Produkt-Increment, ein Baustein, der echten Wert stiften kann. Diese regelmäßigen Auslieferungen ermöglichen frühes Feedback und stellen sicher, dass das Produkt nicht nur kontinuierlich wächst, sondern auch am tatsächlichen Bedarf orientiert bleibt (Schwaber & Sutherland, 2020).
Scrum-Teams arbeiten selbstorganisiert. Sie entscheiden eigenverantwortlich, wie sie Ziele erreichen. Diese Autonomie stärkt das Engagement der Teammitglieder und ermöglicht schnelle Reaktionen auf Veränderungen. Verantwortung wird dabei als kollektive Teamverantwortung verstanden. Ziel ist nicht die Schuldzuweisung bei Fehlern, sondern die gemeinsame Weiterentwicklung von Lösungskompetenz und Produktqualität.
Scrum dient auch der Risikoreduktion. Durch kurze Entwicklungszyklen und häufiges Feedback lassen sich Fehlentwicklungen frühzeitig erkennen. Risiken werden nicht am Ende eines langen Projektverlaufs sichtbar, sondern kontinuierlich adressiert. Retrospektiven fördern das bewusste Lernen aus Fehlern und tragen dazu bei, systematische Schwächen im Prozess aufzudecken und zu beheben (Schwaber & Sutherland, 2020).
Interessant ist, dass Scrum bereits vor der offiziellen Veröffentlichung des Agilen Manifests viele seiner Prinzipien praktisch umsetzte. Das Framework entstand also aus der Praxis heraus und fand später seine theoretische Fundierung im Manifest. Diese Nähe erklärt, warum Scrum nach 2001 rasch zu einem der einflussreichsten agilen Ansätze wurde (Sutherland, 2014).
Der Scrum Guide benennt fünf zentrale Werte, die als Grundlage jeder Zusammenarbeit im Scrum-Team gelten. Sie definieren nicht nur ein Ideal, sondern ein konkretes verhaltensorientiertes Leitbild. Ohne diese gemeinsame Haltung kann Scrum seine Wirkung nicht entfalten. Die Werte lauten: Commitment, Courage, Focus, Openness und Respect (Schwaber und Sutherland, 2020).
Commitment
bedeutet, dass sich alle Mitglieder dem gemeinsamen Ziel verpflichtet fühlen. Es geht dabei nicht um individuelle Leistung oder Profilierung, sondern um das kollektive Verantwortungsbewusstsein für die Zielerreichung des gesamten Teams.
Courage
beschreibt den Mut, offen über Herausforderungen und Probleme zu sprechen. Mut bedeutet auch, neue Wege zu beschreiten, Unsicherheiten auszuhalten und unbequeme Themen nicht zu vermeiden.
Focus
fordert die Konzentration auf das Sprint-Ziel und die vereinbarten Prioritäten. Scrum-Teams schützen ihre Aufmerksamkeit vor Ablenkungen und behalten das Wesentliche im Blick.
Openness
verlangt eine transparente Kommunikation über Fortschritte, Hindernisse und Entscheidungen. Diese Offenheit schafft Vertrauen, das wiederum die Voraussetzung für echte Zusammenarbeit ist.
Respect
bedeutet, dass alle Beteiligten einander mit Wertschätzung begegnen. Unterschiedliche Perspektiven, Fähigkeiten und Erfahrungen werden anerkannt und als Stärke verstanden.
Abbildung 3: Die fünf Scrum Werte
Eigene Darstellung, basiert auf Scrum Guide
Diese fünf Werte sind nicht optional. Sie sind wesentliche Voraussetzungen dafür, dass Scrum in der Praxis funktioniert. Ohne Vertrauen, Offenheit und gegenseitige Anerkennung bleibt der Rahmen des Frameworks leer. Scrum setzt eine Kultur voraus, in der diese Werte aktiv gelebt werden. Nicht nur im Team, sondern auch im gesamten organisatorischen Umfeld.
Die bloße Einführung von Scrum-Rollen, Events und Artefakten genügt nicht. Es braucht Zeit, ein gemeinsames Rollenverständnis zu entwickeln, alte Steuerungsmuster zu hinterfragen und ein agiles Mindset aufzubauen. Wie in der Lehre wiederholt betont wurde, ist Scrum ein Auslöser für kulturelle Veränderung. Dieser Prozess ist oft herausfordernd und erfordert Geduld, Lernbereitschaft und Führung durch Vorbild.
Scrum ist damit mehr als ein Prozessmodell. Es ist zugleich ein Lernrahmen, ein Haltungsprogramm und ein Werkzeug für kulturellen Wandel.
Das Scrum-Framework besteht aus drei Rollen, fünf Ereignissen und drei Artefakten. Es wird meist als zyklischer Prozess visualisiert:
Abbildung 4: Der Scrum Framework
Eigene Darstellung, basiert auf Scrum Guide
Rollen:
Product Owner: Verantwortlich für den wirtschaftlichen Erfolg und die Priorisierung der Anforderungen im Product Backlog
Scrum Master: Unterstützt das Team bei der Einhaltung der Scrum-Prinzipien, beseitigt Hindernisse und moderiert die Prozesse
Developer:
interdisziplinär und selbstorganisiert, verantwortlich für die Umsetzung der Sprint-Ziele
Ereignisse (Events):
Sprint (Herzstück, typischerweise 1–4 Wochen)
Sprint Planning (Planung des Sprints)
Daily Scrum (tägliches, kurzes Abstimmungstreffen)
Sprint Review (Vorstellung des Ergebnisses und Einholen von Feedback)
Sprint Retrospective (Reflexion und kontinuierliche Verbesserung)
Artefakte:
Product Backlog (gesamte Aufgaben- und Anforderungsliste)
Sprint Backlog (konkret geplante Aufgaben für den aktuellen Sprint)
Increment (fertiggestelltes, potenziell auslieferbares Produkt)
Abbildung 5: Vergleich Agile vs. Traditionelle Entwicklung (Wasserfall)
Eigene Darstellung, basiert auf Scrum Guide
Die Wahl des richtigen Entwicklungsansatzes hat maßgeblichen Einfluss auf den Projekterfolg. Die Abbildung stellt die zentralen Unterschiede zwischen der traditionellen Wasserfall-Methode und dem agilen Entwicklungsansatz gegenüber. Während das Wasserfall-Modell durch sequenzielle Phasen, umfassende Vorabplanung und begrenzte Flexibilität geprägt ist, setzt die agile Entwicklung auf iterative Zyklen, adaptive Planung und eine enge Zusammenarbeit mit dem Kunden.
Im Wasserfall-Modell wird jede Phase, von der Anforderungsanalyse über das Design bis hin zur Implementierung und dem Testen, strikt nacheinander abgearbeitet. Änderungen während des Entwicklungsprozesses sind schwer umzusetzen, was besonders bei sich wandelnden Anforderungen zu Problemen führen kann. Erst am Ende der Entwicklung erhält der Kunde ein vollständig fertiges Produkt zur Abnahme.
Im Gegensatz dazu basiert agiles Arbeiten auf kurzen, wiederkehrenden Entwicklungszyklen, sogenannten Sprints. In diesen Zyklen werden Planung, Entwicklung, Test und Kundenfeedback eng verzahnt. Anforderungen können flexibel angepasst und regelmäßig überprüft werden, was zu einer höheren Reaktionsfähigkeit gegenüber Veränderungen führt. Durch die kontinuierliche Einbindung des Kunden entsteht ein Produkt, das besser auf dessen Bedürfnisse zugeschnitten ist.
Diese beiden Ansätze stehen exemplarisch für unterschiedliche Denkweisen in der Softwareentwicklung: planorientiert und vorausschauend versus adaptiv und kundenorientiert. Die Wahl zwischen ihnen sollte sich stets an den Anforderungen des Projekts, der Unternehmenskultur und den Erwartungen der Stakeholder orientieren.
Scrum bietet eine agile, empirisch fundierte Alternative zu klassischen Projektmodellen. Es fördert Eigenverantwortung, Transparenz und kontinuierliche Verbesserung. Eigenschaften, die in komplexen Projektumgebungen heute unverzichtbar sind. Es reicht nicht Scrum zu verstehen, man muss es im Projekt leben.
Als wir das Projekt begannen, stand zuerst die Teambildung im Vordergrund. Wir kannten uns teilweise nur flüchtig und mussten zunächst Vertrauen aufbauen. Der Scrum Guide betont, dass ein Scrum-Team aus Product Owner, Scrum Master und Developern besteht, die gleichberechtigt zusammenarbeiten. Für uns war das neu, da wir bisher meist in hierarchischen Strukturen gearbeitet hatten.
Wir entschieden uns bewusst für eine offene Rollenfindung: Trang übernahm die Rolle des Scrum Masters, da sie bereits zertifiziert war, und Gagan meldete sich begeistert als Product Owner. Alle anderen wurden Developer. Diese Entscheidung war pragmatisch und half uns, schnell ins Arbeiten zu kommen. Gleichzeitig merkten wir, dass damit Erwartungen verknüpft waren. Die „besonderen“ Rollen schienen anfangs wichtiger, was eigentlich nicht dem Scrum Guide entspricht. Rückblickend war das eine wertvolle Lektion, denn alle Rollen sind gleich wichtig und erst als wir das verstanden hatten, entstand echtes Commitment.
Die ersten Schritte bestanden darin, das Projektziel zu klären und ein grobes Backlog anzulegen. Hierbei fehlte uns noch die Erfahrung, wie detailliert User Stories sein sollten. Statt klarer Items standen eher Kapitelüberschriften im Backlog. Das führte später zu Diskussionen, machte uns aber auch deutlich, warum der Scrum Guide so sehr auf Transparenz pocht.
Nachdem die Rollen verteilt waren, mussten wir lernen, sie auch mit Leben zu füllen. Für uns war es ungewohnt, dass Scrum keine Hierarchien kennt. Stattdessen mussten wir akzeptieren, dass Verantwortung geteilt wird.
In der Praxis hielten wir uns nicht immer streng an die Rollengrenzen. So griff der Product Owner manchmal in die inhaltliche Arbeit ein, und der Scrum Master übernahm organisatorische Aufgaben, die eigentlich nicht zu seinem Kernbereich gehörten. Diese Abweichungen waren pragmatisch, weil wir unter Zeitdruck standen und unterschiedliche Erfahrungen mitbrachten. Gleichzeitig führte es zu Reibungsverlusten, weil unklar war, wer in bestimmten Situationen entscheidet.
Wir haben daraus gelernt, dass Respekt vor den Rollen wichtig ist. Erst als wir das stärker beachteten, entstand mehr Klarheit im Prozess. Heute würden wir Rollen von Beginn an konsequenter trennen. Nicht dogmatisch, sondern um Diskussionen zu vermeiden und den Fokus auf die Inhalte zu lenken.
Ein zentrales Thema in unserem Projekt war die Wahl der richtigen Werkzeuge. Der Scrum Guide schreibt keine Tools vor, betont aber, dass Transparenz, Nachvollziehbarkeit und Zusammenarbeit jederzeit gewährleistet sein müssen. Um diesen Anforderungen gerecht zu werden, entschieden wir uns für eine Kombination verschiedener Plattformen: Jira für das Backlog-Management, Confluence für Inhalte und Dokumentation, Mural für kreative Zusammenarbeit, Microsoft Teams und Outlook für Meetings und Organisation sowie WhatsApp für schnelle Abstimmungen.
Jira wurde unser zentrales Tool für die Arbeit mit dem Product und Sprint Backlog. Anfangs war es für viele von uns neu und wir empfanden es als komplex und unübersichtlich. Manche Einträge waren doppelt, andere zu allgemein formuliert. Dadurch entstand Frustration, weil Fortschritte schwer messbar waren.
Abbildung 6: Jira als Projektmanagement-Tool
Screenshot aus Jira, Projektteam, 2025
Mit der Zeit lernten wir, kleinere und präzisere User Stories zu formulieren und Akzeptanzkriterien direkt in Jira zu dokumentieren. Das führte zu mehr Fokus und Transparenz. Hier wurde für uns deutlich, warum der Scrum Guide so sehr auf ein gepflegtes Backlog setzt: Ohne klare Items verliert das Team Orientierung.
Confluence nutzten wir zunächst als zentrale Plattform, um Texte, Notizen und die Buchstruktur systematisch zu dokumentieren. Jede Textseite wurde mit einem Subtask in Jira verknüpft und direkt an die zuständige Person zugewiesen. Damit verbanden wir Aufgabenplanung und inhaltliche Arbeit eng miteinander.
Abbildung 7: Confluence als Dokumentation-Tool
Screenshot aus Confluence, Projektteam, 2025
Anfangs funktionierte dieses Setup gut, doch mit zunehmender Textmenge stießen wir auf technische Grenzen, insbesondere beim Export und der Formatierung. Deshalb stiegen wir im Projektverlauf auf Microsoft Word um. Diese Entscheidung war eine bewusste Abweichung vom ursprünglichen Plan und brachte mehr Kontrolle über Layout und Kompatibilität, bedeutete aber zusätzlichen Aufwand. Rückblickend hätten wir diesen Schritt früher machen sollen.
Für unsere Retrospektiven und kreative Reflexionen nutzten wir Mural. Das Whiteboard ermöglichte es uns, Gedanken parallel einzutragen und visuell zu strukturieren. Gerade in Retrospektiven half es, dass alle gleichzeitig Ideen sammeln konnten und das unabhängig davon, wer gerade spricht.
Abbildung 8: Mural Board für Sprint Retrospective und Weekly
Screenshot aus Mural, Projektteam, 2025
Mit dem Mural Board unterstützten wir besonders den Scrum-Wert Openness: Jeder konnte seine Sicht transparent machen, was Vertrauen im Team förderte.
Die meisten Meetings hielten wir über Microsoft Teams ab. Besonders hilfreich war ein von unserer Scrum Masterin erstelltes Loop-Dokument, das als Einstiegspunkt diente. Es enthielt Links zur Buchstruktur, zu Jira, Confluence und allen weiteren Tools. Dadurch behielten wir Fokus, weil alle Informationen an einem Ort gebündelt und jederzeit zugänglich waren.
Abbildung 9: Loop-Komponente im MS Teams als zentrale Informationsquelle
Screenshot aus MS Teams, Projektteam, 2025
Unsere Scrum-Events planten wir zusätzlich über Microsoft Outlook. Sprint Planning, Weeklys, Reviews und Retrospektiven wurden als Serientermine eingetragen. Diese feste Struktur half uns, auch in stressigen Phasen Verbindlichkeit zu schaffen. Gleichzeitig zeigte sich, wie wichtig Respekt ist, denn wir achteten auf die Zeitpläne der Teammitglieder und versuchten, Termine so zu legen, dass alle teilnehmen konnten.
Über Teams und Outlook organisierten wir außerdem den Austausch mit externen Beteiligten, darunter die Redaktion und unser Dozent als Stakeholder. Unser Product Owner übernahm hier die Schnittstellenrolle. Er hatte den direkten Kontakt, sammelte Feedback von außen und brachte es strukturiert ins Team ein. So konnten wir sicherstellen, dass externe Rückmeldungen respektvoll aufgenommen, diskutiert und in Reviews gezielt eingebaut wurden.
WhatsApp nutzten wir als informellen Kanal für schnelle Abstimmungen. Es erwies sich als praktisch, um asynchrone Standups durchzuführen. Auch wenn diese Lösung nicht dem Scrum Guide entsprach, half sie uns, trotz unterschiedlicher Zeitpläne den Kontakt zu halten.
Abbildung 10: WhatsApp für Daily Scrum
Screenshot aus Whatsapp, Projektteam, 2025
Unsere Toolauswahl war gut durchdacht, verlief aber nicht ohne Schwierigkeiten. Der späte Umstieg von Confluence auf Word hätte früher erfolgen können, und die Vielzahl an Kommunikationskanälen führte gelegentlich zu Verwirrung. Besonders zwischen Teams, Outlook, WhatsApp und Jira war es wichtig, klare Konventionen zu vereinbaren.
Trotz dieser Herausforderungen boten uns die Werkzeuge die nötige Flexibilität und Struktur, um als Team effektiv zusammenzuarbeiten. Wir haben gelernt, dass Tools allein keine Transparenz schaffen. Sie müssen konsequent gepflegt werden. Verbindlichkeit (Commitment) und Offenheit (Openness) im Umgang mit unseren Werkzeugen waren entscheidend, um den Überblick zu behalten. Die Anpassung unserer Arbeitsweise an technische Grenzen zeigte uns, wie wichtig Mut (Courage) ist, pragmatische Entscheidungen zu treffen, auch wenn sie vom ursprünglichen Plan abweichen. Genau dieses ständige Hinterfragen und Anpassen entsprach dem agilen Gedanken, den wir mit Scrum umsetzen wollten.
Wir arbeiteten überwiegend remote und trafen uns nur gelegentlich an der Universität. Diese Mischung stellte besondere Anforderungen an unsere Kommunikation, sowohl technisch wie auch zwischenmenschlich. Um dem gerecht zu werden, legten wir zu Beginn gemeinsame Rahmenbedingungen fest. Der Scrum Guide betont, dass Transparenz und Kommunikation entscheidend sind, doch für uns war es zunächst schwierig, dies konsequent umzusetzen.
Unsere Sprints dauerten jeweils zwei Wochen. Ein klares Sprint Goal, wie es der Scrum Guide fordert, fehlte anfangs. Das war keine bewusste Abweichung, sondern schlicht der Tatsache geschuldet, dass uns die Erfahrung fehlte. Wir merkten bald, dass ohne Ziel der Fokus fehlte: Manche arbeiteten an verschiedenen Dingen, ohne dass ein roter Faden erkennbar war. Erst später lernten wir, Sprint-Ziele zu formulieren, und bemerkten sofort, wie sehr dies den Teamfokus stärkte.
Bei den Events wichen wir bewusst ab. Statt Dailys führten wir Weeklys ein, aus Zeitgründen, denn wir alle studieren dual und haben neben dem Studium nicht nur eine mindestens vier Tage Arbeitswoche, sondern auch andere Module und Abgaben zu bewältigen. Diese Entscheidung erschien uns im Alltag praktikabler. Nach einigen Sprints stellten wir jedoch fest, dass uns dadurch Transparenz und kontinuierlicher Informationsfluss fehlten. Blocker wurden zu spät erkannt, Fortschritte zu selten geteilt. Um dem entgegenzuwirken, führten wir asynchrone Dailys über WhatsApp ein. Von Montag bis Freitag schrieb jeder kurz, woran er arbeitet, was er geschafft hat und ob es Hindernisse gibt. Das war zwar nicht gleichwertig mit echten Dailys, half uns aber, trotz unterschiedlicher Zeitpläne verbunden zu bleiben. Diese Anpassung zeigte uns, wie wichtig Courage und Openness sind. Wir mussten ehrlich zugeben, dass unser Weekly-Ansatz nicht ausreichte, und mutig genug sein, etwas Neues auszuprobieren.
Für unsere Meetings nutzten wir Microsoft Teams. Um den Austausch effizient zu gestalten, bereiteten wir oft Agenden vor und versuchten, uns an feste Zeitrahmen zu halten. Doch das Timeboxing, im Scrum Guide ein zentrales Prinzip, gelang uns nicht immer. Besonders nach Feedback zogen sich Termine oft in die Länge, weil zusätzlicher Abstimmungsbedarf entstand. Das war einerseits positiv, weil wir uns intensiv mit den Inhalten auseinandersetzten, andererseits zeigte es uns, dass Fokus und Disziplin im Zeitmanagement nicht verhandelbar sind.
Ein weiterer wichtiger Punkt war die Rollenklarheit. Anfangs verschwammen die Grenzen, sodass der Product Owner mischte sich in die Moderation ein, der Scrum Master übernahm organisatorische Aufgaben, die eher an klassische Projektleitung erinnerten. Das führte zu Verwirrung und Reibungen. Mit der Zeit achteten wir jedoch bewusster auf klare Trennung: Die Moderation lag verbindlich beim Scrum Master, der Product Owner konzentrierte sich auf das Backlog und die Priorisierung, und die Developer organisierten ihre Arbeit selbst. Dieses Learning war entscheidend, denn Respekt vor den Rollen bedeutete, dass wir Verantwortung klarer verteilten und effizienter zusammenarbeiten konnten.
Rückblickend haben wir verstanden, dass jede Abweichung vom Scrum Guide einen Grund hatte, sei es Zeitmangel oder fehlende Erfahrung, aber auch Folgen. Manche Lösungen, wie die WhatsApp-Dailys, halfen uns pragmatisch weiter, andere zeigten uns, dass wir uns künftig konsequenter an die Vorgaben halten sollten. Besonders gelernt haben wir, dass klare Rollen, kurze Abstimmungen und eingehaltene Timeboxen nicht bürokratische Regeln sind, sondern echte Unterstützung für die Zusammenarbeit.
Wie bei vielen neuen Scrum-Teams traten auch bei uns typische Anfangsschwierigkeiten auf, die sich im Rückblick als wertvolle Lernerfahrungen erwiesen.
Ein zentrales Problem lag in der Formulierung der Backlog-Einträge. Viele Items waren zu allgemein gehalten, ein typisches Beispiel war „Theorieteil anfangen“. Diese Unschärfe erschwerte sowohl die Planung als auch die Umsetzung, weil Fortschritt kaum messbar war und Aufgaben unterschiedlich interpretiert wurden. Der Scrum Guide betont die Notwendigkeit klarer und transparenter Product Backlog Items. Nach einigen Sprints lernten wir, präzisere Einträge zu formulieren, wie etwa „Einleitung Theorie-Teil finalisieren“. Dadurch wurde der Fortschritt nachvollziehbarer, und wir konnten unsere Arbeit klarer strukturieren.
Auch unsere Planungssitzungen waren anfangs schwierig. Sie begannen oft verspätet oder waren unzureichend vorbereitet, sodass Meetings regelmäßig überzogen wurden. Das führte zu Frust und ineffizienter Zusammenarbeit. Diese Erfahrung machte uns bewusst, dass Timeboxing nicht nur eine formale Regel ist, sondern eine echte Hilfe, um den Fokus zu behalten. Mit besserer Vorbereitung und mehr Disziplin gelang es uns nach und nach, die Meetings kürzer und zielgerichteter zu halten.
Ein weiteres zentrales Learning war die Definition of Done (DoD). In den ersten Sprints hatten wir keine klare oder einheitliche DoD, was dazu führte, dass jedes Teammitglied ein anderes Verständnis von „fertig“ hatte. Das erzeugte Missverständnisse und Uneinigkeit. Nach etwa vier Sprints führten wir schließlich eine verbindliche Definition ein: Ein Kapitel gilt als „done“, wenn es vom Autor geschrieben, von einem anderen Developer gegengelesen, in Word strukturiert abgelegt und abschließend vom Product Owner abgenommen wurde. Dieses 6-Augen-Prinzip brachte Klarheit und Sicherheit in den Workflow. Zwar bedeutete es zusätzlichen Aufwand, aber der Nutzen war klar erkennbar durch höhere Qualität und weniger Diskussionen über den Status von Arbeitsergebnissen.
Im Laufe dieser Herausforderungen wurden die Scrum-Werte für uns zu einer praktischen Orientierung. Vertrauen wuchs, als wir uns gegenseitig Verantwortung zutrauten. Mut brauchten wir, um Fehler offen anzusprechen und neue Wege auszuprobieren. Respekt zeigte sich darin, dass wir Meinungsverschiedenheiten konstruktiv austrugen. Fokus half uns, auch bei Überlastung durch Studium und Beruf das gemeinsame Ziel nicht aus den Augen zu verlieren. Und Offenheit war die Grundlage, um unsere Prozesse kritisch zu hinterfragen und gemeinsam bessere Lösungen zu entwickeln. Diese Werte waren der Schlüssel, dass wir trotz Unsicherheiten weiterkamen und als Team zusammenwuchsen.
Rückblickend war unsere Startphase stark von Ausprobieren, Unsicherheiten und Lernen geprägt. Wir haben erlebt, dass Scrum nicht einfach „nebenbei“ funktioniert, sondern Disziplin, klare Strukturen und ein gemeinsames Verständnis erfordert. Jede kleine Abweichung vom Scrum Guide, sei es ein zu vages Backlog, fehlende Sprint Goals oder unklare Definition of Done, hatte spürbare Folgen. Manche Effekte zeigten sich erst nach mehreren Sprints, machten uns aber deutlich, wie wichtig es ist, die Prinzipien von Scrum konsequent zu leben.
Gleichzeitig haben wir gesehen, dass Pragmatismus manchmal notwendig war. Mit Weeklys und später WhatsApp-Dailys fanden wir einen Weg, trotz voller Terminkalender im Austausch zu bleiben. Auch wenn diese Lösung nicht dem Scrum Guide entsprach, half sie uns, arbeitsfähig zu bleiben und trotzdem ein gewisses Maß an Transparenz zu wahren.
