Scrum - Von A bis Z [Mit Profi-Tipps]

Scrum ist eines der beliebtesten Frameworks für agiles Projektmanagement und so zählt Scrum im Bereich Softwareentwicklung und Programmierung zum de-factor Standard unter den agile Frameworks. Dabei ist Scrum bzw. die Scrum Methode zunächst recht einfach, da es nur wenig Scrum Meetings gibt und die Rollen Scrum Master, Product Owner und das Team selbst sehr übersichtlich sind. Aus meinem Scrum Traning habe ich diese Übersicht entnommen um auch Dir Scrum und agile Entwicklung näherzubringen. Dabei ist es egal ob Du schon Erfahrung in Scrum hast, oder das Wort Daily Scrum bzw. Scrum Daily, Product Backlog, Retrospektive, Scrumpoker und weitere für dich komplett neu sind. Ich zeige Dir Scrum, wie und wo Du Scrum einsetzt und welche Gefahren es dabei in der Praxis gibt. Dieses Video richtet sich sowohl an Einsteiger, als auch an all diejenigen, die schon seit langem als Scrum Master, Product Owner oder in irgendeiner anderen Rolle im Scrum Prozess beteiligt sind. Am Ende zeige ich Dir aus meiner Erfahrung von über 100 Scrum Einführungen auf was Du bei Scrum unbedingt achten solltest, damit alles auch wirklich ein Erfolg wird.

## Kapitel
[00:00] Start
[04:02] Was ist agil in Scrum?
[06:22] Agiles Framework
[08:16] Was ist Scrum?
[09:47] Sprint und Artefakte in Scrum
[13:13] Meetings in Scrum
[16:38] Die Rollen in Scrum
[20:55] Profi Tipp für Scrum

## Links

## Videos

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[DavidTielke]

WIe immer interessiert mich, wie Ihr zu dem Thema Scrum steht und besonders "Was ist für Euch das wichtigste bei Scrum?" Die Verlosung des DWX Tickets geht bis zum 21.6. - Viel Erfolg. Und das *Abo* nicht vergessen, zu Scrum machen wir noch mehr in der Zukunft :)

[franzwinter]

Vorab. Ich halt nichts von Scrum. Mein Background: Fast 10 Jahre Erfahrung als Softwareentwickler und jetzt bald 2 Jahre Product Owner in einem Unternehmen mit > 5000 MA das eigene Produkte entwickelt, fertigt und vertreibt.
Wie fast in jedem Unternehmen das SW entwickelt, strauchelt es im SW Bereich. Backlog ist laut Jira für die nächsten 10 Jahr randvoll, ca. 50% der täglichen Arbeit wird mit Bugfixen verbracht und das Management schimpft weil die Zeitpläne nicht eingehalten werden.
Ich geh mal in die Vergangenheit. Vor ca. 8 Jahren haben bei uns einige Teams mit Scrum angefangen. Sie hatten das Problem, dass sie ständig während der Entwicklung von Sachen unterbrochen wurden und nichts fertig machen konnten, weil sie wieder wo anderes was neues implementieren sollten. Idee: Wir führen Scrum ein, damit transparent festgehalten wird, an was die nächsten 2 Wochen (fokussiert) gearbeitet wird. Ein Entwickler aus einem anderen Team wurde Scrum Master und ein Projektleiter wurde PO. Aber so richtig funktioniert hat das nicht. Hier muss ich noch anmerken, dass das Team Scrum eingeführt hat, ohne dem Wissen des Top Managements. Die wussten zum dem Zeitpunkt vermutlich nicht mal was Scrum und Agil bedeutet. Wenig überraschend ist es immer wieder dazugekommen, dass Sprints von der Geschäftsleitung gecrasht wurden. OK das kann passieren, dass man mal was sehr wichtiges vorziehen muss, aber es kam irgendwie zu oft vor. Natürlich war der Frust bei den Entwicklern dementsprechend groß und das Team hat schon darüber nachgedacht das mit Scrum wieder zu lassen.

Aber das Top Management wurde rund um die Probleme in der SW Entwicklung „aktiv“. Angefangen wurde damit einen Softwareentwicklungsprozess auszuarbeiten. Weil hier wurde vermutlich ein bisschen die Idee von Lean aufgeschnappt. Entwicklung ist ein Prozess der immer die gleichen Schritte hat und somit kann man Features wie am Fließband produzieren. „Haha“ Dieser Prozess wurde in ein PDF mit ca. 50 Seiten gegossen und in Form von Schulungen ausgerollt. Dieses Dokument enthält Definitionen für Rollen, Artefakte (wie Lasten- und Pflichtenheft ;-) ) usw., basierend auf dem V-Modell XT, Arc 42, Scrum, Kanban, SAFe usw. An dieser Stelle könnte man mal Bingo sagen. In dem Zusammenhang wurde dann noch Jira eingeführt, damit der Prozess mit über 20 Issue Typen und 100 Zuständen transparent ist. Währendes wurden auch noch andere Prozesse wie Anforderungs, Ideen, Änderungsmanagements ausgearbeitet und eingeführt. Mein Fazit: Klingt toll, aber diese Dokumente haben eigentlich mehr Fragen aufgeworfen als sie beantworten hätte sollen. Ist auch klar. Diese Dokumente wurden zum Teil von Leuten geschrieben die vielleicht mal in der Schule ein „Hello World“ programmiert haben. Natürlich wurde für diese ganzen Themen externe Hilfe herbei gezogen, Aber zum Ende dieser Phase wurde die Zusammenarbeit mit dem ersten externen Beratungsunternehmen beendet.
Vor ca. 3 Jahren hat das Top Management hat Wort „Agil“ (in einer Buchstabensuppe) entdeckt. Vermutlich in dem Zusammenhang - Mit agil werden die Software Entwickler schneller. Nein. Ein weiteres großes Beratungsunternehmen wurde engagiert mit dem Ziel eine agile Transformation im Unternehmen einzuläuten. Eine große Veranstaltung wurde gemacht wo alle vom agilen Arbeiten überzeugt werden sollen. Gefolgt von 100erten super teuren Beratungsstunden. Dieses Beratungsunternehmen hat es aber glaube ich geschafft dem Top Management klar zu machen, dass wenn man eine agile Transformation durchführt werden soll, das Top Management auch agil sein muss.
Wenn man eine agile Transformation macht will wird natürlich gerne Scrum eingeführt – ist ja (gerade) modern. Darum wurden ca. 5 Vollzeit Scrum Master eingestellt und Product Owner installiert.
Jedoch hat dieses Beratungsunternehmen einen Zwist in das Unternehmen gebracht. Dieses Beratungsunternehmen hat ihr eigenes agiles Framework entwickelt und dieses wollte bzw. hat es zum Teil mittels Musterprojekten eingeführt. Jedoch ist dieses nicht mit firmeneigenem Softwareentwicklungsstandard konform, mit dem der Großteil entwickelt wurde. Schlussendlich haben einige interne Leute gesagt: „Wie sollen wir jetzt arbeiten?“ und das Management hat sich dazu entschieden die Zusammenarbeit mit diesem Beratungsunternehmen zu beenden bzw. nicht weiter verlängert und diese eingeführten Sachen wurden über Bord geworfen.
Man kann sich jetzt Fragen wieso schreib ich das jetzt alles? Naja vielleicht habe ich einen Schaden von dem ganzen agilen Zeugs davon getragen und bin deswegen kein Fan von Scrum. Aber vielleicht kommt (bzw. kam) auch der Schaden von diesen hardcore Scrum Mastern, die versucht haben in jedem kleinen Fleck im Unternehmen Scrum zu machen. Angefangen von der Softwareentwicklung bis hin zum Support. Kein Scherz. Auch im Support soll ein Mitarbeitern schätzen, wie langer er für die Lösung von einem Problem braucht. Naja ich halte davon nichts.
Hier muss ich mal festhalten, dass ich vom agilen Arbeiten natürlich schon was halte. Aber ich verdrehe halt die Augen wenn man dazu „agil“ sagt. Für mich ist das intuitiv wenn Software in kleine funktionale Teile runter bricht. Wer will schon ein Jahr Anforderungen schreiben ohne eine echte Funktionalität zu sehen? Also ich würde das nicht aushalten.
Zurück zu Scrum. Ich habe da jetzt zwei Sichtweisen drauf. Ich fange mal von der Sicht des Dev Teams an. Würde ich in einem Scrum Team sein, würde mich das Schätzen von User Stories stören. Man bekommt ja oft Sachen vorgelegt die man machen soll, zum Teil nicht klar ist was gemacht werden soll, die User Story sehr groß ist, bzw. man keine Expertise auf dem Gebiet hat. Und dann soll man das Schätzen und ein commitment machen. *bäh* Wenn man jetzt eine Person ist, die gut SW schreiben will, immer sein Wort halten möchte und kein Zeit gefühlt hat, dann kommt da bei mir ein innerlicher Stress auf, dass sich negativ auf die Arbeitsleistung auswirkt. Hier kann man einhacken. Ja aber man schätzt ja eh im Team. Sollte so sein, ist aber oft nicht so. Weil oft ist es so, dass sich nur einer in der Software auskennt.
Bei uns im Unternehmen kommt mir vor, dass Scrum Master überall dort eingesetzt werden, wo „Babysitter“ benötigt werden. Ich schlage oft innerlich die Hände über dem Kopf zusammen, was mir die Scrum Master von ihrer täglichen Arbeit erzählen. Beispiel: Mitarbeiter A kennst sich wo nicht aus und weiß das Mitarbeiter B ihm da weiterhelfen kann. Jedoch will Mitarbeiter A nicht Mitarbeiter B bei seiner Arbeit stören und kommt deswegen bei seiner Arbeit weiter und das obwohl sie Tisch an Tisch sitzen. Und um solche Fälle müssen sich bei uns Scrum Master kümmern. Ich nenne das „betreutes programmieren“. Anderes gesagt es ist traurig wenn ein Scrum Master benötigt wird das ein Daily gemacht wird oder man sich kontinuierlich verbessern will. Sicher immer weiter zu verbessern sollte ja selbstverständlich sein.
Aus der Sicht des Product Owners sehe ich da wieder andere Herausforderungen. Ziel von agiler Softwareentwicklung ist ja „Value“ dem Kunden zu liefern. In Scrum soll ja nach jedem Sprint ein „potentielles“ Release geliefert werden können. Sprich in Scrum müssen die Stories dementsprechend klein sein, dass sie innerhalb von z.B. 2 Wochen implementiert werden kann. Und wenn zu groß dann muss man sich kleiner bekommen. Und dieses „zermahlen“ von Sachen ist echt schwierig und würde mich nerven.
Zum Beispiel habe ich jetzt gerade ein Software Projekt. Drei Entwickler sollen eine Datenbank aufsetzen, mit einem Webfrontend bestehend aus einer Seite. Diese Seite enthält ca 5 Suchfelder und die Suchergebenisse werden beim Drücken einer Schaltfläche aufgelistet (sehr einfache Anwendung). Das ganze habe ich in eine User Stories gepackt, weil es den Stakeholder einen Mehrwert bietet. Ich dachte auch, würden wir Scrum machen würde sich das durchaus in 2 Wochen ausgehen. Angefangen wurde damit Anfang 2021 und nach 6 Monaten sind die 3 Entwickler damit fertig geworden. Warum? Weil diese drei Entwickler eigentlich immer Embedded Software in C++ entwickelt haben und dieses Mal zum ersten Mal in C#.

[marcusschone]

Wir haben auch (leider erst vor ca 1 Jahr) angefangen, unsere Projektplanung agil mit Scrum zu gestalten. Am Anfang klingt alles so einfach, aber die Umsetzung hat an vielen Ecken dann doch seine Herausforderungen.
Besonders die Rollen des Product Owners und Scrum Masters gut zu besetzen hat sehr lange gedauert. Es ist leider nicht jeder dazu geschaffen.

Ich finde auch die Daily Meetings mit am wichtigsten. Sie geben jedem einen klaren Überblick was getan wurde und was getan werden soll.
Allerdings machen wir dieses aktuell Corona bedingt in Microsoft Teams als Chat - was finde ich, eine geniale Lösung ist. So können auch Kollegen die Urlaub haben oder krank sind, später nachschauen, was getan wurde und wo es vielleicht Probleme gab.

Ich danke dir David für dieses wirklich gute Video was eigentlich den perfekten Überblick zu dem Thema liefert. Und die Folien sind ebenfalls sehr passend und auf den Punkt gebracht.

Liebe Grüße aus Bremen und bis zum nächsten Video!

[buecherlstefan]

Hallo David, danke für deinen Überblick über den Prozess und die Tipps am Ende. Die sind meiner Meinung nach sehr wertvoll.

Ich finde gerade zu Beginn ist es sehr wichtig, dass man so startet wie es Scrum vorgibt. Einfach Teile / Rollen / Events davon im voraus bereits wegzulassen, ohne dem ganzen die Chance zu geben sich zu entwickeln, halte ich für sehr kritisch. Man braucht Menschen, die sich darauf einlassen und daran gefallen finden.

Zusätzlich muss man sich wirklich bewusst sein, dass Scrum immer Probleme hochkochen lässt. Jeder kann Probleme lösen, wenn z.B der Buildprozess nicht läuft oder Anforderung verbessert werden müssen. Der, der es aber schafft eine Athmosphäre zu schaffen, wo man ehrlich, kritisch und offen über alles reden kann, egal was es ist, hat meiner Meinung nach schon gewonnen, denn dann kannst du alles aus der Welt schaffen.

[domeplsffs]

Vielen Dank für den Upload. Bin gerade dabei mich für meine Scrum-Master Zerti vorzubereiten und deine Erfahrung ist hilfreich um noch mal über meine eigenen Ansätze und Vorgehensweisen zu reflektieren.

[SUPERSONIC_ARCHERY]

Hi David, dieses Video ist sooo geil! Alles passt. Ich bin auch enorm am verzweifeln und komme kaum noch weiter. Ich bin PO und soll in meinem Unternehmen als PO agieren. Ich nutze SCRUM in der Tat als Rahmen für die Projekte, jedoch stelle ich SCRUM nicht als "Gottes-Gesetzte" über alles. Mein Problem ist, dass KEINER in meinem Unternehmen kapiert was ein PO macht, sie verstehen SCRUM als Anfeindung und sie verstehen es nicht on-point Anforderungen zu erstellen (selbst das Wort "Userstory" ist mir verboten worden...) Dabei geht es mir nur darum, dass die Anforderungen so geschrieben werden, dass alle beteiligten genau wissen und verstehen a) welchen Prozess sie beschreiben, b) welche Herausforderungen die Userstorys ausmachen usw. Ich will das Entwicklerteam mit gezielten Infos versorgen und mit ihnen agil arbeiten, denn wenn sie keine sauberen Infos bekommen, dann kommt am Ende nur Kacke raus. Aber mein Kollegenteam boykottiert einfach alles. Kannst Du mir irgendwie helfen oder nen Tipp geben. Grüße

[meinekleinestimme]

Vielen Dank für das tolle Video und der tollen Erklärungen. Ein "Like" hätte es vielleicht auch getan, aber in meinen Augen bräuchte es dafür eine gesonderte Erwähnung mit Kommentar 😊

[carstenvogelsang]

Hi, allerseits, ich glaube, ich bleibe lieber, bei meiner guten alte Mindmap Methode, da mache ich nichts falsch, aber danke für die Aufklärung.

[ministerstein]

Danke für Erklärung. Für mich eine Auffrischung, weil wir vor Jahren mal ein Scrum-Training hatten, mit der Zeit und Betriebsblindheit sich Scrum dann vielleicht auch mal verselbstständigt und man so manche Regeln nicht mehr eingehalten werden, weil sie nervig sind oder zu viel Zeit in Anspruch nehmen. Dann macht man doch wieder sein eigenes Scrum, was nach gewisser Zeit kein wirkliches Scrum mehr ist, wie du ja im Video sagst.

[Palladin]

Den für mich wichtigsten Punkt in Scrum erwähnst Du erst ganz am Ende oder indirekt durch andere Punkte:

"Das Team - eine Gruppe [...] die gemeinsam Sprint für Sprint auf ein Ziel hinarbeiten"
Das wichtige sind die zwei Worte "EIN Ziel".

Ich denke, ein sehr großes Problem, warum bei uns eigentlich nichts wirklich funktioniert, ist, dass wir nicht ein Ziel haben, sondern ungefähr so viele völlig verschiedene Ziele wie Mitarbeiter. Obwohl wir uns Team nennen und jeden Morgen ein sog. „Daily“ machen, arbeitet am Ende wieder jeder für sich, weil jeder sein komplett eigenes Projekt hat.
Wenn mal zwei zusammenarbeiten, dann heißt das meistens „Person XY entlasten“ und sieht meist so aus, dass der Kollege irgendeine Aufgabe von Person XY übernimmt, während der etwas Anderes mit hoher Prio abarbeitet und ggf. Fragen beantwortet.

So kann Scrum mMn. nicht funktionieren, man muss erst dafür sorgen, dass sich ein Team bilden kann, was in unserem Fall bedeutet: Nur ein Projekt gleichzeitig für ein Team.

[chrishh]

Für mich ist das wichtigste in Scrum die Retrospektive, aber sie bringt nur was, wenn man auch kritisieren kann was nicht gut gelaufen ist.

[kevin]

Ist der Scrummaster auch automatisch der Vorgesetzte? Oder wie wird das in der Praxis meist gehandhabt? Vielen Dank für das super Video!

[alexrampp]

Die "Definition of Ready" ist meiner Meinung nach das Wichtigste. Essentieller Bestandteil dieser Definition ist meiner Meinung nach, dass jeder im verstanden hat, worum es in dieser Anforderung geht. So lange das nicht gewährleistet ist, kann man die Anforderung weder schätzen noch irgendwie planen. Leider wird dies in der Praxis meiner Erfahrung zu oft nicht beachtet und es landen aus verschiedenen Gründen sehr vage Anforderungen im Sprint.

Dies ist aber ganz klar eine Aufgabe des Teams. Leider werden zu oft unklare Anforderungen "irgendwie geschätzt" weil sie aufgrund von Zeitbeschränkungen dringend in den nächsten Sprint müssen. Hier sind vor allem wir erfahrenere Entwickler in der Pflicht, den Finger in die Wunde zu legen, Unklarheiten anzusprechen und eine Klärung dieser einzufordern und Notfalls auch mal eine Schätzung oder Planning zu blockieren wenn es nicht anders geht. Das hat nichts mit unkooperativem Arbeiten zu tun - im Gegenteil - es zeigt die Probleme bereits beim Planning auf, die später in der Implementierung sowieso aufgetreten wären.

Auch wenn das Team 100% zu Scrum committed ist, kommt es hin und wieder mal zu solchen Situationen und dann ist es natürlich gut, wenn man das trotzdem "irgendwie schaukelt". Das ist dann aber definitiv ein Thema für die nächste Retrospetkive wo man analysieren muss warum es zu dieser Situation kam und wie man dies in Zukunft vermeiden kann.

[jonab]

Tolles Video David! Hat mir als ausgebildetem Scrum-Master auch weitergeholfen.
Meine Frage aber, planst du Videos zu den einzelnen Rollen? Ich glaube das würde vielen Personen (mich eingeschlossen) helfen ihre Rolle und die damit einhergehenden Aufgaben besser zu verstehen.

Liebe Grüße Jonathan

[jurosworld]

Meine persönliche Meinung zu dem Thema ist, dass man auch nicht nur als Team-Mitglied, PO oder SM, sondern die Abteilung(en) und vor allem das Unternehmen das "Mindset" dafür haben muss. Es muss von allen gewollt und dann auch umgesetzt werden, konsequent. Leider klingt das alles sehr einfach, scheitert aber am Ende genau an diesem wichtigen Element. Scrum selbst konfrontiert einem dann auch noch mit alten Prozessen und Kulturen (bei Einführung), die irgendwie nicht zu Scrum zusammen passen wollen 😉 und man an verschiedenen Stellen nicht in der Lage ist, sich dann entsprechend anzupassen oder aufzustellen. Das kann man auf verschiedene Dinge übertragen. Das finde ich persönlich schade, denn einfach "agil" (weil buzzword, klingt cool und so) zu sein reicht nicht.

Innerhalb eines Scrum-Projektes konnte ich bisher mitwirken und empfand es als super. Alle anderen und bisherigen Projekte habe ich "agil umgesetzt, nur nicht nach dem Schema F (Scrum, Kanban oder ähnlichem). Wasserfall und co habe ich mich schon vor ca. einem Jahrzehnt verabschiedet.
Grundsätzlich finde ich Scrum und andere Frameworks wichtig und sollten konsequent umgesetzt werden, auch wenn es am Anfang ein "Hindernis" ist, profitiert man mittel- und langfristig durch die Verbesserung der Gesamtstruktur.

[Shabazza]

Ich habe Scrum noch nicht korrekt umgesetzt gesehen.
Die Teams die es bei uns machen verschwenden Zeit mit Daily Scrum das zu Status-Reports verkommt und 10 Leute stehen da und warten nur drauf,
dass sie endlich weiterarbeiten können, nachdem sie ihre 2 Sätze gesagt haben.
Und da wir Komponenten oft wegen Komplexität auf Owner aufteilen und nicht 10 Leute an 1 Feature oder Bug arbeiten (auch keine 5 oder 3),
interessiert es uns nur periphär was die Kollegen gestern getan haben, heute tun, oder morgen tun wollen.
Trotzdem verschwendet man mindestens 15 Minuten * 5 Tage * 10 Leute * 20 Tage = 13 Stunden pro Monat mit nutzlosem verbalen Status-Report,
obwohl jeder selber im Bug- und Anforderungs-Management System bei Bedarf sehen kann, wer was macht oder gemacht hat oder machen wird.
Abstimmung läuft also bei Bedarf und 15 Minuten Händchenhalten in der Kaffeeküche nützt keinem was.
Sicher toll wenn man Scrum korrekt einsetzt. Wir tun's nicht...
"Agil" geht auch ohne Scrum mit weniger Overhead.

[argi]

Ganz ehrlich, Scrum ist der allerletzte Scheiss. Und zwar so richtig

[oliverabrahamhamburg]

Scrum braucht auf jeden Fall das Daily, denn nichts finde ich schlimmer, als Teamkollegen, die nicht informiert sind. Das geht sprachlich im Daily am besten. Besser als im Chat

[ZacharySnow]

Scrum bzw. Agile wird oft davon gesprochen wie es ist ein Produkt was Mann kaufen kann. "Schick mal Tobias los, wir brauchen mehr Agile Spray."

[Palladin]

Eine inhaltliche Frage:

Du hast Scrum jetzt allgemein beschrieben, aber ich frage mich - wo findet die Planung für Architektur/Design Platz? Ganz besonders, wenn es um ein Grüne-Wiese-Projekt geht.
Wo ist der Anfang, arbeitet der Architekt vorher allein und schafft einen Rahmen? Wie wird die Umsetzung der einzelnen Aufgaben geplant, damit man sie verteilen kann und nicht jeder qualitätsrelevante Entscheidungen allein trifft?
Meine ersten Gedanken dazu:
Man bezieht die Detail-Planung mit in den Scrum-Prozess ein, aber nicht als Software-Projekt, sondern als reines Planungs-Projekt.

Vor dem Architektur-Entwurf entwirft der Architekt einen groben Rahmen, dann bekommt jeder Mitarbeiter einen Teil des Rahmens und baut einen kleinen Prototypen, um mögliche Probleme zu finden und Lösungen zu finden. Anstelle des Reviews werden die Erkenntnisse gesammelt und mögliche Lösungen diskutiert, die der Architekt dann mit in den Entwurf einbaut.
Steht der Architektur-Entwurf, muss die Struktur auf Assembly/Klassen-Ebene geplant werden, das könnten in dem Fall je zwei Mitarbeiter machen, die für einen Teilbereich die Struktur entwerfen. Anstelle des Reviews werden die Ergebnisse gesammelt und zu einem großen Konzept zusammengeführt, der Architekt überwacht, begleitet und behält die Hoheit.
Das geht dann so lange, bis jeder klar vor Augen hat, wie das Projekt am Ende strukturiert sein soll und es können für die Sprints konkrete Entwicklungsaufgaben definiert und verteilt werden.

Danach geht dann die normale Entwicklungsarbeit los. Ändern sich zwischen den Sprints Teile der Anforderungen, dann wird das zumindest teilweise so für die geänderten Anforderungen wiederholt, der Rest des Teams arbeitet an den unveränderten Anforderungen weiter, sofern die Änderungen nicht zu großflächig sind.

Meinen wichtigsten Punkt zu Scrum schreibe ich als eigenen Kommentar, Ordnung muss sein ^^