69er - Projektende

Heute, nach nunmehr 4 Sprints à 2 Wochen ist das 69er Projekt zu Ende.

In Ruby gibt ein Prinzip: DRY - Don't repeat yourselves - und gemäss DRY möchte ich die Dokumentation vom 69er Projekt hiermit beenden, ich würde mich nur wiederholen. Trotzdem möchte ich noch ein Resümee ziehen und ein paar Zahlen zeigen, z.B. das Product Burndown Chart:

Im 69er Projekt wurden total 88 Story Points realisiert, im Schnitt 22 Story Points pro Sprint. Geplant war zu Beginn eine Velocity von 20 SP's pro Sprint. Das Team hat geliefert - das Backlog ist leer und wir haben noch ca. 20% Budget.

Heute, am Demo Day von Sprint 4 löst sich das Team auf, die Entwicklungen sind eigentlich abgeschlossen. Der Product Owner war anwesend und letztendlich haben wir heute ein Abnahme gemacht. Es wurden noch ein paar Dinge aufgenommen, die nachgebessert werden sollten ... Klingt nach einem neuen Sprint? Hm.

Bislang habe ich im Projekt ein bischen die Kappe des Scrum Masters aufgehabt und das Team "geführt", sobald man vom agilen Vorgehen abgekommen war. Mühsam, aber unter dem Strich sehr wichtig. Da ich bisher davon überzeugt war, dass neben mir auch andere im Team den agilen Prozess verinnerlicht haben und durchaus gewillt sind, so zu arbeiten, habe ich mich heute in der Retrospective als "Moderator" zurückgehalten und das Team machen lassen.

Kurz gesagt: ich war entäuscht. Niemand hat die Funktionalität gezeigt, die im Sprint 4 entwickelt wurde. Stattdessen war "hm, was haben wir denn alles so gemacht" rum-geklicke angesagt. Viel unötige Diskussionen, Fragen zur Spezifikation und Feedback bzw. Änderungswünsche. Darüber hinaus wurde keine Retrospective gemacht.
Die anstehenden Arbeiten wurden nicht genauer besprochen, in Tasks zerlegt, geschätzt, priorisiert - eben all das, was wir nunmehr 3 Sprints durchgezogen haben. Ich hätte erwartet, dass man eine Sprint 5 Planung macht und dem agilem Vorgehen weiter folgt. Naja.

Da kommt mir die einleitender Aussage von der Projektleitung zu Beginn des Projektes in den Sinn - sie ist zieht sich durch das gesamte Projekt:

"Wie ihr das macht, ist egal. Es muss am Ende nur funktionieren."

69er - Sprint 3 Retrospective

Gestern, 09. September war erneut eine Retrospective im 69er Projekt, nunmehr in der dritten Iteration.

Summary:
Auch in diesem Sprint war das Team schneller, aber leider auch schlechter. Der agile Arbeitsturnus hat sich so langsam eingespielt und das Team lebt Scrum. Trotzdem ist die Stimmung nicht gut. Der fehlende ScrumMaster ist für das Team spürbar. Viele Hindernisse die sich zu Blocking entwickeln, ohne Aussicht auf Behebung!

Das Ergebnis:
Geplant waren 20 Story Points bei einer verfügbaren Zeit von 78h, sportlich! Von den geplanten User Stories konnten 4 nicht fertig gestellt werden! Warum? 

Es gibt bei diesen Stories ein externes Partner-Unternehmen, auf dessen Service die Applikation angewiesen ist. Die Integration des Services ist zunächst trivial, trotzdem klemmt es. Das Partner-Unternehmen lässt uns hängen - das Team kommt nicht voran. Andere User Stories wurden einfach nicht gut genug getestet und vielen schlichtweg durch, als sie dem Product Owner präsentiert wurden. 

Und so sieht es aus:


Retrospective:

Was war nicht gut?

1. Die Rails Entwickler machen viele Tasks, die nicht Rails related sind - das ist langsam und macht kein Spass
2. Design ist noch immer nicht abgeschlossen, muss ständig neu angefasst werden - wird nie fertig
3. "Springende" Ressourcen sind nicht im agilen Prozess, sie leben ihn nicht
4. Viele externe Hindernisse, die das Team nicht lösen kann und sich "niemand" drum kümmert
5. Stimmung schlecht, Ergebnis stimmt nicht - wir erreichen unsere Ziele nicht

Uhhpf! Nicht gut ...

Was können wir besser machen?

1. Niemand arbeitet allein auf dem Projekt (auf täglicher Basis). Wir arbeiten nur, wenn mindestens 2 Teammitglieder arbeiten, bessere Resourcenplanung ausserhalb des Teams.
2. Reviews schneller(früher) machen, Arbeit (früher) abschliessen
   
3. Product Owner ist zwingend anwesend beim Planning und Demo Meeting

Nun steht der letzte Sprint vor der Tür. Das Product Backlog ist noch immer gut gefüllt und das Projektende ist absehbar. Werden wir es schaffen?

Zurück zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 3 Planning & Estimation Meeting

Der 3. Sprint im 69er Projekt steht an und es gilt erneut: Team, let's plan!, ABER bei diesem Planning & Estimation Meeting gibt es eine Besonderheit, die ich in meinem agilen Dasein bisher auch noch nicht erlebt habe - der Product Owner ist nicht anwesend.

Wir haben vom PO mit auf dem Weg bekommen, dass auch im kommenden Sprint der Schwerpunkt auf dem User Interface liegen soll, denn nach nunmehr etlichen Iterationen beim Design haben wir eine finale Version, endlich.

Ok, wie sieht es mit den Ressourcen aus?


Plannning & Estimation

Da wir in diesem Sprint nicht so viel verfügbare Ressourcen haben, geht das Team mit weniger geplanter Arbeit in den Sprint. Nimmt man den Durchschnitt aus Sprint 1 und Sprint 2 beträgt die Velocity bisher 23 Story Points/Sprint. Um den limitierten Ressourcen Rechnung zu tragen, wollen wir 20 Story Points annehmen.

Das Team geht Story für Story aus dem Backlog durch und fragt zunächst, ob alle Fragen benantwortet sind, oder anders gesagt, wissen wir, was hier die Aufgabe ist. Wenn nicht, wird das an der Story vermerkt und diese zurückgelegt. Der interim ScrumMaster geht diesen Stories im Sprint nach und klärt die Fragen.

Gut, nachdem alle Stories im Backlog sortiert wurden nach klar und unklar, beginnt das Team die Arbeit zu schätzen. Dabei werden pro User Story kurz die Task herausgebrochen (nur grob) und überschlagen. Am Ende kommt man auf die Story Points pro User Story.

Und so sieht Sprint 3 aus:

Das Team hat 20 Story Points angenommen. Diese 20 SP's entsprechen ca. 81h Arbeitsaufwand. Verfügbare Arbeit ist 78h, d.h. wir haben ein kleines over commitment.

[Update]

Weiter zur Sprint 3 Retrospective

Zurück zur Sprint 2 Retrospective

69er - Wir brauchen einen ScrumMaster

Im der letzten Retrospective von Sprint 2 hat das Team bemängelt, dass es viele Hindernisse gibt, die offensichtlich viel Engagement benötigen und im Team keine Zeit dafür besteht. Jedes Teammitglied steht unter Druck, denn man hat sich auf eine Ziel committed und man möchte das Spiel gewinnen. Treten Hindernisse auf, geht man diesen nach, soweit es möglich ist. Werden die Hindernissse zu gross, geht dem Team die Luft aus.

Bei einem der Posts zum 69er Projekt habe ich einen Kommentar bekommen, der auf die Pitfalls von Scrum eingeht. Es geht im wesentlichen um die Frage, ob man ohne ScrumMaster ein Scrum Projekt führen kann und was unsere Erfahrungen sind.

"In addition to the disengaged ScrumMaster, there is the team where a worker bee also tries to be ScrumMaster. This works fine as long as the team does not encounter too many impediments. If the team does encounter impediments, however, either the impediments will not be resolved (because the worker bee role is consuming too much time) or the work will not be completed (because the worker bee is now running around trying to eliminate impediments). For this reason, I no longer have team members perform the ScrumMaster role while actually doing work on a sprint (unless it is a very small amount of work)." Boris Gloger, Pitfalls in Scrum

Nun ja, genau diese Erfahrungen kann ich bestätigen. Kleine Hindernisse kann das Team selbst lösen. Werden diese zu Blocking oder mengenmässig grösseren Hindernissen, leidet das Team und damit das Ergebnis.

Beim 69er Projekt wurde das offen in der Retrospective Sprint 2 diskutiert. Das Team bat um einen ScrumMaster. Da man sich allerdings bereits im 3. von 4. Sprints befindet und eine Einarbeitung Zeit und Aufwand bedeutet, hat das Team davon abgesehen.


Die Erkenntis:
Im nächsten Scrum Projekt nur noch mit ScrumMaster.

69er - Sprint 2 Retrospective

Am Dienstag vergangene Woche war erneut ein Sprint im 69er Projekt vorüber und es wurde präsentiert, was wir hatten.

Summary:
Das Team war erneut schnell, schneller als geplant und schneller als selbst eingeschätzt, aber es häuften sich auch die Probleme ...

Das Ergebnis:
Geplant waren für Sprint 2 total 25 Story Points (SP's), bei einer verfügbaren Zeit von 144h Stunden. Von den geplanten User Stories wurden nur 18 SP's umgesetzt, 7 SP's waren Not Done. Trotzdem hat das Team während des Sprints zusätzliche User Stories angenommen und somit insgesamt 28 Story Points verdient.

Interpretation, Sprint Burndown:
Das Team hat in der Retrospective das Burndown Chart analysiert und kam zu folgenden Erkenntnissen:

• Wir sind schnell, aber ...
• Viele offene Pendenzen, Hindernisse - daher kein Progress bei 4 Stories (Blocking)
  
• Aufgrund der Blockaden musste das Team andere User Stories vorziehen, da sonst keine Arbeit
  
• Vorgezogene User Stories waren oft nicht abgeklärt- viele offene Fragen, Unklarheiten
  

Retrospective:

Was war gut?

• User Story of Taskboard, quasi manuell, nach wie vor gut
  
• Resourcen konnten arbeiten, wie geplant

Was können wir besser machen?

• Vorgezogenen User Stories oft unklar, Plannig Phase fehlte, viel Input vom PO während des Sprints notwendig
• Es gab eine Demo vom System mitten im Sprint, nicht zum Demo Day wie geplant
• Administrative Arbeiten inkl. Aufwände fallen an, gehören aber nicht zu einer Story und tauchen nicht in der Sprint-Planung auf, was machen wir damit?
• Code Freeze vor dem Deployment wurde nicht für alle Teammitglieder kommuniziert, daher gab es anschliessend viele Merge-Konflikte im Subversion
• Release-Umgebung zur Demo nicht up-and-running, ungeplanter Aufwand im Sprint
• Es gibt keine Release Notes, was haben wir bisher gemacht?
• kein ScrumMaster zum Hindernisse lösen
• Sprint Übersicht ist gut, aber Gesamtperspektive fehlt - wo stehen wir? Werden wir das schaffen?
• Anwesenheit beim Daily Scrum nur sporadisch

Nun, wenn wir die Stimmungbaromether ablesen sieht es nicht mehr so gut aus - wir müssen handeln!

Zurück zum 69er - Sprint 2 Planning & Estimation Meeting
[Update]
Weiter zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 2 Planning & Estimation Meeting

Nach erfolgreichem Sprint 1 im 69er Projekt hat das Team nun ein Sprint 2 Planning Meeting durchgeführt.

Aufgrund der Erkenntnisse aus der Sprint 1 Retrospective soll der Fokus im kommenden Sprint auf dem User Interface liegen. Daher wurden solche User Stories vom Product Owner hoch gewichtet, die darauf einen Einfluss haben. Wichtig ist, dass am Ende des Sprints die bisherige Arbeit über den Product Owner hinaus noch anderen Stakeholders des Auftraggebers präsentiert werden soll.

Ok, was werden wir machen?

Wir haben eine andere Verteilung bei den Kompetenzen in diesem Sprint, eher User Interface lastig, und kommen daher insgesamt auf 144h verfügbare Zeit.

Vom Team angenommen wurden 25 Story Points.

Weiter zur Sprint 2 Retrospective

Zurück zur Sprint 1 Retrospective

69er - Sprint 1 Retrospective

Am Dienstag war beim 69er Projekt Sprint 1 Demo Day und Retrospective. Team: Safe!

Dashboard?
Originally uploaded by Jürg

Summary:
Alles in allem kann man sagen, dass das Team unglaublich viele Arbeitspakete bewältigen konnte, mehr als erwartet.

Das Ergebnis:
Geplant waren 12 Story Points, 132h verfügbare Zeit
Realisiert wurden 19 Story Points in 143h. 31 geplante Stunden konnten nicht bezogen werden. Eine User Story wurde vom Product Owner nicht abgenommen, also 18 Story Points insgesamt.

Interpretation, Sprint Burndown:
In der Retrospective hat das Team das Burndown Chart und die Zahlen interpretiert und ein Fazit gezogen. Dabei kam heraus, dass man

• zu pessimistisch geschätzt hat
• Arbeit geplant hatte, die man (noch) nicht machen konnte, daher zu "schnell" war

Hintergrund: Look&Feel der Anwendung sind noch nicht final definiert. Interaction-Designer und Usability Experten arbeiten noch daran, trotzdem hat das Team im Sprint 1 bereits Funktionalitäten entwickeln könnnen, allerdings ohne visuellen Aspekt. Strenggenommen sind diese User Stories nicht DONE. Daher hat das Team eine virtuelle Persona konzipiert (Design-Checker) und eine User Story angehängt, die zur GUI Implementierung in einem späteren Sprint genutzt werden soll. Geplante und verschobene Aufwände/Tasks aus Sprint 1 wurden dort angehängt. Dieser Umstand erklärt den schnell Fortschritt.

Desweitern wurde durchleuchtet, warum das Team mit 31h Restguthaben in der verfügbaren Zeit mit 142h abrechnen konnte, obwohl nur 132h geplant waren. Ein Grund liegt auf der Hand: wir haben mit einem 6h-Tag geplant und kommen daher bei den verfügbaren Ressourcen auf 132h, worst case Szenario quasi. Ein anderer Grund war, dass die geplanten Ressourcen im Verlauf des Sprints nicht eingesetzt werden konnten. Eine Rahmenbedingung, deren man sich bewusst war, daher die 6h-Tag Planung.

Retrospective:

Was war gut?

• Vorbereitende Arbeiten waren sehr gut , z.B. Infrastrukur war bereits da, als das Projekt im Sprint 1 begonnen hat
• Dokumentation im Wiki ist sehr gut, so findet man das verteilte Projekt Know-How
• ein Biergarten Besuch ;-)
  
• sehr guter Austausch im Team- man weiss praktisch immer, woran alle arbeiten
• Review ist sehr gut, verteilt das Wissen im Team, man lernt viel
• Daily Scrum wird als nüztlich empfunden, er ist kurz gehalten, fokussiert
• Product Owner ist zufrieden mit der Arbeit

Was können wir besser machen?

• Stunden aufschreiben! Am Sprint Ende war nicht ganz klar, wieviel Stunden wir aufgewendet haben
• Einschränkungen, Editierbarkeit im GUI bitte disuktieren, nicht einfach machen - z.b. nach Daily Scrum
• Was haben viele Tasks, die keine Story haben z.B. Testumgebung aufsetzten. Was machen wir damit?

Die Stimmungsbarometer untermauern den aktuellen Befund - alles im grünen Bereich!

Zurück zum Sprint Burndown Chart und Taskboard
Demnächst: Sprint 2 Planning Meeting

69er - Sprint Burndown Chart

Ok, Sprint Burndown Chart! Das Team trifft sich jeden Tag zu einem Daily Scrum, max. 15min. Das gesamte Team ist anwesend, teilweise auch der Product Owner.

Nachdem jedes Teammitglied seinen heutigen Tag am Taskboard geplant hat, nimmt der Scrum Master die Zahlen in das Sprint Burndown Chart auf. Es wird während des Daily Scrum ausgedruckt und an das Taskboard geheftet - und natürlich beurteilt, jeden Tag!


Das Burndown Chart hier zeigt den 4. Tag im Sprint. In der oberen Tabelle werden die heutigen Ressourcen eingetragen, in der unteren die Restzeit.

Man kann erkennen, dass zwar 3 User Stories bereits auf Done sind, aber die verbleibende Zeit per heute knapp wird. Man sieht auch, dass eine Entwickler Ressource am 4. und 5. Tag mit 0 Stunden verfügbar ist, obwohl mit 6h geplant wurde. Ausserdem kann man sehen, dass bei diesem Tempo bald keine Arbeit mehr da ist, trotz Verknappung der Ressourcen. Der Product Owner wurde bereits am 3. Sprint-Tag informiert, ist nun anwesend und kann vorschlagen, was man als nächstes in den Sprint aufnehmen kann.

Zurück zum Taskboard
Demnächst:
Weiter zur Sprint 1 Retrospective

69er - Taskboard

Es sind bereits drei Tage im Sprint 1 des 69er Projekts vergangen. Wo stehen wir?

Im vergangenen Beitrag 'Sprint 1 Planning & Estimation Meeting' habe ich angekündigt, einen Einblick in unseren Daily Scrum zu geben und hier sind wir - unser Task Board:



(Wir wollten das Rad nicht nochmals erfinden, daher haben wir uns beim Taskboad von Mountain Goat Software orientiert.)

Wie läuft der Daily Scrum ab?

Das gesamte Team ist anwesend, inkl. Product Owner. Der Daily Scrum geht maximal 15 Minuten. Jedes Teammitglied geht gedanklich die Tasks durch. Dabei werden:

• überfüssige Task entfernt
• fehlende Tasks hinzugefügt
  
• verbleibende Aufwände pro Task überprüft und gegebenenfalls korrgiert (nach oben oder unten)
  
• Zustand der Tasks überlegt
  

Anschliessend gehen wir User Story für User Story durch jedes Teammitglied beantwortet folgende Fragen:

• Was hab ich gestern gemacht?
• Was mache ich heute?
• Was sind meine Hindernisse?

Untermauert wird die Fragerunde mit dem Verschieben von Tasks oder Korrektur des Aufwands. Hindernisse markiert das Team mit brüllenden Fussballstars! Peter Cech steht für fehlende Informationen, Oliver Kahn für blockierendes Hinderniss. (siehe Taskboard, rot eingerahmt)

Jeder bekommt die Chance, mitzuteilen wo er steht, wie er vorankommt und ob er Hilfe braucht.

Der Daily Scrum wird abgeschlossen mit der Frage, wie der heutige Einsatz am Projekt sein wird. Scrum geht davon aus, dass ein Team fix an einem Projekt arbeitet, quasi den gesamten Tag, die gesamte Sprintdauer und letztendlich das gesamte Projekt. Sehr ideal, aber leider nicht realistisch, denn wir Arbeiten auch noch für andere Projekte. Wir haben Scrum hier adaptiert und eingeführt, dass wir die verbleibende Restzeit im Sprint davon abhänig machen, wieviel jeder am Sprint arbeitet, auf täglicher Basis.

Nach dem Daily Scrum wird das Sprint Burndown Chart generiert und and das Taskboard (rechts oben) gepinnt. Es ist Gegenstand für den kommenden Daily Scrum, am nächsten Morgen - und alle freuen sich auf den kommenden Morgen, wenn es endlich wieder heisst - Gentlemen, Daily Scrum!

[Update]
Weiter zum Sprint Burndown Chart
Zurück zum Sprint 1 Planning & Estimation

69er - Sprint 1 Planning & Estimation Meeting

Heute hat das Team gemeinsam die Aufwandschätzung und Planung vom Sprint 1 für das 69er Projekt absolviert. Für alle ein ganz neue Aufgabe, die mit dem agilen Vorgehen nach Scrum eingeführt wurde. Trotz 4 arbeitsintensiven Stunden kann sich das Ergebnis sehen lassen:

Wie gehen mit vier User Stories und 12 Story Points in den ersten Sprint. Basierend auf dem aktuellen Wissenstand haben wir im schlechtesten Fall 98h Aufwand, den wir 132h unterbringen müssen.

Zurück zu Sprint Zero
[UPDATE]
Weiter zum Taskboard

69er - die Persona bitte

Für das 69er Projekt haben wir in der frühen Konzeptionsphase mit Benutzergruppen die Bedürfnisse der potenziellen Nutzer erarbeitet. Als Ergebnis haben wir viel Anwendungszenarien erhalten. Wir haben das Use Cases genannt - ganz klassisch mit UML dokumentiert.

Schnell wurde klar, dass sich Benutzer der gleichen Benutzergruppe unterscheiden würden, ganz einfach aufgrund ihrer unterschiedlichen Interessen und Bedürfnissen.

Ein Use Case Beispiel (nicht im 69er Kontext):

• Akteur: User
• Aktion: kann Abstimmen

Wenn man diesen Use Case bespielsweise in den Kontext einer Wahl des nächsten Präsidenten betrachtet, könnte man folgendes festellen: User ist nicht gleich User!

Je nach politischer Gesinnung, finanziellem Hintergrund, persöhnlichen Präferenzen, äusserlichen Einflüssen, Anonymität der Mitteilung, etc. kann es User geben, die eben NICHT dafür, sondern dagegen stimmen würden.

Also haben wir die User unterschieden und pro Charakter eine Persona konzipiert.

Mike, 52, Prof. für Physik
Mike lebt allein, er hat keine Kinder. Mike betreibt gern Outdoor Sport und nutzt dafür jede freie Minute. Es ist ein naturverbundener Mensch, verabscheut Hass und Gewalt.

Dank Mike haben wir eine ganz neue Sicht auf den Anwendungsfall:

• Akteur: User
• Aktion: kann dagegen stimmen

Persona sind also ein wichtiges Mittel, um unterschiedliche Bedürfnisse gleicher Benutzergruppen zu modellieren. In unserem 69er Projekt werden der Persona User Stories zugeordnet. Jede Persona hängt am Task Board, so dass man sich immer das Benutzerverhalten in den Erinnerung bringen kann.

69er - mein neues Scrum Projekt

Ab Montag, den 28. Juli 08, beginnt für mich (endlich) wieder einmal ein Scrum Projekt, das Vierte nunmehr.

Ich möchte meine Erfahrungen und Erkenntnisse auch hier erneut auf meinem Blog dokumentieren. Da es sich um ein Kundenprojekt handelt und keine projektspezifischen Details beschrieben werden können, gebe ich dem Projekt einen fiktiven Namen: 69er

Das 69er Setup sieht momentan so aus:

Team

• 2-3 Entwickler
• 1 Publisher/Flasher
• 1 Designer
• 1 Product Owner
• 1 Scrum Master (wird von einem Team-Mitglied übernommen, abwechselnd)

Technology

• Ruby on Rails
• Flash
  

Zeit

• 9 Wochen à 5 Arbeitstage, d.h. 4 Sprints à 2 Wochen plus 7 Tag

Das Product Backlog

Das Backlog ist gut gefüllt, wir haben an der Zahl 23 User Stories, deren Aufwand und Komplexität bislang noch nicht klar ist. Womöglich werden die User Stories noch zerlegt und somit in der Anzahl vermehrt.

Was ist bisher geschehen?

Der Auftraggeber hat das Team angefragt, seine Vision von einem Kundenportal in einem recht sportlichen Zeitfenster zu realisieren. Nach einer sehr kreativen Konzeptionsphase wurde die Vision zunächst in verdauliche Einheiten heruntergerebrochen und die high-level Rahmenbedinungen festgelegt, z.B. soll es einen Web Applikation entwickelt werden.

Das Team hat, basierend auf der Vision, mögliche Benutzergruppen und deren Nutzungsbedürfnisse erarbeitet mit dem Auftraggeber abgestimmt. Letztendlich wurden einige Persona und deren User Stories in ein Product Backlog aufgenommen und eine grobe Sprintplanung gemacht. Dies, zusammen mit einer groben Aufwandschätzung, Wireframes und der Beschreibung der Vorgehensmethode, wurden dem Auftraggeber als Offerte zugestellt. Nach formalen Anpassungen kam es zur Beauftragung. Was wir haben:

• provisorisches Product Backlog
  
• provisorische Sprint Planung
• provisorische Resourcenplanung

Scrum Adaption

Der Auftraggeber anerkennt unser Vorgehensvorschlag nach Scrum, wird allerdings nicht in seiner Funktion als Product Owner teilnehmen. Daher hat das Team beschlossen, einen Product Owner Proxy einzusetzen - der Key Account Manager auf Unternehmensseite. Er kennt den Auftraggeber, dessen Vorstellungen und Wünsche. Er ist in der Lage, das Projekt erfolgreich abzuwickeln und kann die Aufgaben eines Product Owners nachkommen. Der Scrum Master wird vom Team gestellt. Diese Rolle soll abwechselnd pro Sprint neu vergeben werden.

Wie gehts weiter?

Für das Scrum Team ist dieses Vorgehen bislang unbekannt, zumindest praktisch. Daher ist es jetzt wichtig, alle ins Boot zu holen, um gemeinsam ein akzeptables Vorgehen zu erarbeiten. Zu Begin der nächsten Woche wird es für das Team eine kurze Einführung in Scrum geben. Anschliessend werden wir gemeinsam folgende Punkte angehen:

• DONE Definition erarbeiten
• Setup der Tools und Entwicklungsumgebung
• Offene Punkte und indentifizierte Hindernisse
  

Los gehts mit dem Sprint 1 Planning & Estimation Meeting

Demnächst, hier auf dem Blog!