Heinz’s posterous

SCRUM

Agile Management

3 Rollen
-> product owner
-> team
-> scrum master
3 Artefakte
-> product backlog
-> sprint backlog
-> release plan

ein Sprint dauert 2-4 Wochen

Je kürzer desto besser. Aber: Teams brauchen Zeit, bis sie in ihrem Thema sind.

Am Anfang ist der Plan ein Wille. Mit der Scrum-Methode wird daraus ein Fakt.

Zu empfehlen: Roman Pichler: Scrum

Daily: findet alle 24 Stunden statt, am vesten vormittags.

Scrum = Gedränge

15min: Was habe ich gestern getan?
Was mache ich heute überhaupt?
Habe ich Probleme?

Team. 5-9 Leute, interdsiziplinär, keine Hierarchie

Bei mehr als 9 Mitgliedern funktioniert das System meist nicht mehr
(Führungsskalierung)

Generalisten - Wie kommt es dazu, dass jeder alles können kann?

Scrum board:

Todo - progress - done

Knallt die Aufgaben herein, schiebt sie dann weiter

Bearbeitungsachse/Prioritätenachse

Zettel werden im Ideal von oben links nach unten rechts verschoben.

Keine digitaen Mittel.

Jeden Tag ein Burndown Chart.

Arbeitslast (in Points) vs. Time

Zu Anfang Sprint Planning; Liste wird zusammengestellt.

Scrumboard wird täglich aktualisiert (alles innerhalb der 5 Minuten)

Außerdem: Impediments List: Impediments sind Probleme, die ein
Team-Mitglied hat.

Der Scrum Master hilft dabei, die Impediments aus dem Weg zu schaffen.
"Servant Leadership"

2 Weitere Meetings am ende eines Sprints: Review und Retrospektive, je
1 Stunde, 2 Stunden maximal.

Am Ende: Prodct Owner, das ist unser Ergebnis.

Beii der Retro ist der PO nicht dabei, nur fürs Team -
Verbesserungsmeeting (kontinuierlicher Verbesserungsprozess)

(Nach jedem Sprint habe ich etwas Lauffähiges. Potentially shipable Product)

Kunde merkt automatisch nach der Zeit, wie das System funktioniert.
Einen Kunden, der nach Pflichtenheft denkt, wird man zu Anfang nicht
überzeugen kann.

Iteratives Modell.

Sprint Planning: Am Anfang, dauert relativ lange. Meeting, in dem
gesagt wird, brauche ich alles. Was brauche ich, um das FEature von
dem Product Backlog abzuarbeiten. Einen Tag investiert man in die
Planung. 2 Phasen, vormittags und nachmittags. In der ersten Phase ist
der Owner dabei. Man quetscht den Product Owner aus bis zum geht nicht
mehr. 2. Phase: Wie kann ich dieses Ding impementieren.

1. Phase: Was?
2. Phase: Wie?

Ein klasischer Entwickler wird sich am Anfang schwer tun, alles für
zwei Wochen durchzuplanen. Granularität: 2-3 Tage.

Board-Bewegung soll täglich da sein.

Es gibt neben der Punkt auch eine Tages- oder Stundenmetrik.

Priorisierung: Was ist ganz oben in der Product Backlog-Liste.

Story Points

Grundmotivation: Kann das Team schätzen, was es in einem Sprint
erledigen kann? Tasks werden granular aufgeteilt, möglichst so, dass
sich Tagesaufgaben ergeben (?).

Product Owner sitzt normalerweise in der Organisation. Z.B.
Vertriebler, Person mit Kundenkontakt.

Wenn das team nur aus 5 Leuten besteht ist es sinn, den Product Owner
nach außen zu reflektieren.

Scrum wird generell eher in größereb Organisationen eingesetzt.

Story Points. Am Anfang muss das Team eine Referenz haben. Wieviel
Aufwand hat eine verwandte Aufgabe?

Wieviel Punkte gibt man der Aufgabe? Punkte sind eine relative Größe,
eine Schätzgröße. "Planning Poker" Dafür gibt es auch
iPhone-Anwendungen. Scrun´m master muss fragen, warum es große
Unterschiede in der Einschätzung gibt. Dabei geht es jeweisl um einen
product Backlog-Eintrag, also ein Feature des fertigen Produkts.

Warum führt man Story Points ein und zählt nicht einfach die Tage? Man
will das Management verbessern. Man will die Verbindung von Zeit und
Aufwand abkoppeln. Denn Zeit ist immer relativ, z.B wegen
Unterbrechungen, Email, Meetings usw. In der klassischen
Projektplanung verschiebt sich dann anders. die klassischen Modelle
sind zeitorientiert, Scrum ist aufwandsorientiert.

"Velocity" lässt sich mit einiger Erfahrung einschätzen.

Benefit des Managements: Empirisches, bes Modell: Wie schnell ist
meine Entwicklung?
Dann wirkt sich aus, wie man bestimmte Methoden anwendet, z.B. XP,
Test driven development.

"Level of Done" ist entscheidend. Denn jeder hat zu Anfang ein anderes
Qualitätsbewusstsein. Qualitätsdefinition ist "Level of Done". wird am
Anfang definiert. Z.B. Tsk ist erledigt, wenn es Unit Tests gegeben
hat, Akzeptanztests gegeben hat, wenn es dokumentiert ist ... So bald
das Level of Done gebrochen wird, ist die Aufgabe nicht erfüllt.
(Bedeutung vn Tests, Reviews)

Stetig ein Qualitätsstandard.

Management gewöhnt sich an Feature-Durchatz. Das darf nicht
unterbrchen werden, durch Review-Sprints. Besser weniger, aber
konstanter Feature-Durchsatz.
Management wird interessiert sein an groben Daten. Wichtig ist die
Burndown-Trend-Analyse. Aosnt werden Sprints und Velocity in relation
gesetzt. Stunden ode Tagesdurchsatz gibt es hier nicht mehr, es werden
Punkte gemessen, es wird ausgerechnet: Wieviel kostet ein Punkt?

Scrum Master macht kein Reporting. Wird sich um das Team kümmern.
Bring das Team dazu, das Board immer upzudaten. Team muss realisieren,
dass ihm Management-Aufgaben aufgebürdet werden.

Bestes Prinzip immer noch Boards und Postits. Weil sonst vieles nach
hinten geschoben wird. Bei mehreren Teams gibt es mehrere scrum
boards.

Skalierung gechieht durch mehrere Scrum teams. Koordination in einem
SoS - Scrum of Scrum