„Geschichten vom Scrum“ (Holger Koschek)

Wer Scrum noch nicht kennt und Märchen liebt, dem kann man die „Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten“  von Holger Koschek ans Herz legen.

Im Wieimmerland werden das Großväterchen, Aschenputtel, Hexe, Geist und Ritter Magnolius vom König beauftragt, die „beste und flexibelste Drachenfalle aller Zeiten“ zu bauen. Unterstützt werden Sie dabei vom Prinz (als Scrum Master). Auch wenn es sich um ein altes Königreich handelt, so sind die genutzten Methoden fortschrittlich, weil agil.

Mittels dem Einhorn Bumaraia (Scrum Coach) lernt das Team die wichtigsten Scrum-Artefakte kennen (einen festen Zeitrahmen, gemeinsame Scrum-Meetings und Selbstorganisation). Über den Zeitraum von 7 Sprints (1 Sprint entspricht einem Monat) soll laut König die gewünschte Drachenfalle gebaut werden.

Da es sich um ein praktisches Beispiel handelt, werden die entwickelten Inkremente am Ende des Sprints sogar am lebenden Drachen getestet und die Ergebnisse fließen entsprechend wiederum in die nachfolgenden Backlog Items ein. Das Team arbeitet in einem eingespielten Rhythmus. Um es mit den Worten des Einhorns auszudrücken:

„Eines der Grundprinzipien von Scrum ist die Etablierung eines Taktes, nach dem das Projekt seine Sprints plant und durchführt. Wie in der Musik bildet der Takt die Grundstruktur, auf dem der Rhythmus und die Harmonie aufbauen. […] Einem Orchester fehlte in einer Taktlosen Welt die Grundlage für das gemeinsame Spiel.“

Selbst im Märchen klappt nicht alles reibungslos, so dass neben zwischenmenschlichen Problemen vor allem auf die Schwierigkeiten eingegangen wird, die bei der Einführung von Scrum auftreten können. Als Scrum Master ist unser Prinz hier stark gefordert (z.B. bei der Einhaltung der Zeiten fürs Daily Scrum, bei der Planung der Backlog Items für kommende Sprints).

Das Einhorn Bumaraia gibt weiterführende Informationen zum Thema Scrum (was hat es mit der Definition von „fertig“ auf sich; warum es wichtig ist den Kunden frühzeitig einzubeziehen; wie geht man mit Fehlern um? etc.) und eignet sich damit als Einsteiger-Buch für alle Scrum-Neulinge und alle, die Ihr Wissen über Scrum auffrischen wollen.

Die knapp 230 Seiten „Geschichten vom Scrum“ lesen sich wie im Flug und bleiben aufgrund der Anschaulichkeit der Erzählung länger im Gedächtnis als ein Scrum-Lehrwerk.

Auf dem nächsten Agile Breakfast werde ich einen Vortrag zum Thema “Definition of Ready – wann kann’s endlich losgehen?” halten. Den meisten ist die “Definition of Done”, kurz “DoD” bekannt, während die “Definition of Ready” (“DoR”) noch relativ wenig diskutiert wird. Dies hat verschiedene Gründe, je nach organisatorischem Umfeld birgt die DoR auch einiges an Konfliktpotential.

In meinem Vortrag werde ich die Motivation für die DoR erläutern und auf das existierende Spannungsfeld (Vorteile, Probleme) eingehen.

Das nächste Agile Breakfast in Konstanz findet am 5. Juli im Wasserturm Stromeyersdorf/Konstanz statt. Organisiert durch die Scrum User Group Lake Constance (SUGLC). Gesponsert von der Firma Sybit.

Es gibt einen Flyer – den könnt ihr bei euch im Unternehmen aushängen.

Anmeldung

Bitte vergesst nicht euch rechtzeitig anzumelden. Die Teilnahme ist kostenlos.

http://securerespond.com/thoughtworks/offshorewebinar/

Ansehen lohnt sich auf jeden Fall!

Zunächst geht er auf die grundlegenden Herausforderungen bei verteilten Projekten ein: Kommunikation, Beziehungen, Vertrauen. Um diese Herausforderungen meistern zu können, müssen entsprechende organisatorische Maßnahmen ergriffen werden. Ich möchte hier jedoch einen kommentierten Auszug aus der Liste der empfohlenen Tools geben, die helfen verteilte Projekte erfolgreich durchführen zu können.

Communication Tools

Instant Messaging (IM)

IM Tools dienen zum schnellen (synchronen) Austausch von Informationen. Man sieht, wann jemand verfügbar ist und schnelle – oft informelle – Chats sind möglich. Sehr gut geeignet auch als Fallback bei Telefonkonferenzen. Ausgesprochene Empfehlung: Camp Fire.

• Anmerkung: Ich persönlich nutze gerne Google Talk, da hier keine Installation nötig ist, weil ein einfaches Web-Interface existiert. Zudem ist ein GMail-Account weit verbreitet.

Screen-Sharing

Werkzeuge für Screen-Sharing werden vor allem bei Projektmeetings eingesetzt, um die gleichen Dokumente zu sehen, darüber zu diskutieren und direkt gemeinsamt Änderungen daran vorzunehmen. Desweitere interessant für Reviews und beim Pairing über die Distanz. Ausgesprochene Empfehlung: YuuGuu.

• Anmerkung: Wir machen seit Jahren sehr gute Erfahrungen mit dem Werkzeug eines Karlsruher Herstellers: “Netviewer”. So gut wie gibt es Probleme mit Netwerkrestriktionen (Firewall).

Voice over IP / VOIP

Wichtigstes Tool bei internationalen Projekten, da es sehr einfach die (nahezu) kostenlose Kommunikation zwischen den Projektbeteiligten erlaubt. Ausgesprochene Empfehlung: Skype

• Anmerkung: Teilweise wird Skype bewusst ersetzt durch eine Lösung, in dem die VoIP nur über unternehmensinterne Infrastruktur geleitet wird und offene Protokolle zum Einsatz kommen.

Wiki & Collaboration

Informationen festhalten und austauschen. Ausgesprochene Empfehlung: MediaWiki & Confluence

• Anmerkung: Sehr gute Erfahrungen habe ich mit Confluence gemacht. Vor allem wenn Jira als Werkzeug für Issue-Tracking, bieten sich sehr interessante Integrationsmöglichkeiten. Ein Dash-Board für ein Projekt oder eine Team-Seite ist damit schnell erstellt – inkl. dynamischer Daten (Issues, Stories) aus Jira.

Issue/Task Tracking

Um Aufgaben, Fehler und Risiken verwalten und allen Teammitgliedern zugänglich zu machen wird ein Issue/Task Tracker benötigt. Ausgesprochene Empfehlung: Mingel, Jira, BaseCamp.

• Anmerkung: Ich habe sehr gute Erfahrungen mit Jira gemacht. Hierbei spielt gerade die Nutzung von zusätzlichen Issue-Attributen und Filtern eine wichtige Rolle, um z.B. Team-Backlogs zu erstellen, die sich aus mehreren Projekten zusammensetzen (Multi-Projekt-Multi-Team). Hilft, v.a. wenn die Ergebnisse dann in Excel exportiert und ausgewertet/aufbereitet werden. Greenhopper (Jira Plugin für Scrum) scheint aktuell noch auf einzelne Jira-Projekte beschränkt zu sein.

Zusammenfassung

Meiner Meinung nach sind die genannten Werkzeuge sehr wichtig, um verteilten Projekten sinnvoll koordinieren/durchführen zu können. Zusätzlich muss auch die gesamte Entwicklungsumgebung so aufgestellt sein, dass verteiltes Arbeiten möglich ist: Continuous Integration, Testabdeckungen, Standardisierung, direkt verfügbares Repository, Werkzeuge zur AUswertung von Code-Qualität – aber dies ist Inhalt eines eigenen Artikels.

Quelle: Channel9 MSDN

Ken erläutert die Motivation hinter PSD, Sam vermarktet die Werkzeugkette von Microsoft. Wenn man sich nicht dadurch stören lässt, dann sehr sehenswert.

Im Juni wird Ken Schwaber übrigends in Karlsruhe sein: Er hält die Keynote für den Agile Day beim diesjährigen Entwicklertag.

In seinem sehr interessanten Blog finden sich immer wieder interessante Artikel. Jetzt hat er dort die “Scrum Checklist 2.0” veröffentlich. Ähnlich wie beim Nokia Test werden wichtige Kriterien einer Scrum-Umsetzung abgeprüft, was dabei helfen kann Optimierungspotential zu erkennen.

Ein Beispiel, wie die Checkliste NICHT eingesetzt werden sollte, wird gleich mitgeliefert ;-)

Big Boss: "Well it says here that you should do it, so don’t let me catch you cheating again, or I’ll call in the Scrum Police!"

http://www.crisp.se/scrum/checklist

Bei der Vorstellungsrunde und Tagging  Martin Fache kennengelernt. Mit ihm die Präsentation noch einmal überarbeitet und zusammen die Session gehalten.

Natürlich ist schwupps etwas schiefgelaufen: Netbook hatte keine Lust mehr ( Powersaving etc)  und Open Office hat dies anscheinend sehr übel genommen (-> Absturz).

Die Folien zum Vortrag findet ihr hier: 090523-1500armerkater-scrum.

Nach der Präsentation gab es wie erhofft Fragen und eine Diskussion zu Scrum:

Termine in Scrum
Wie kann mit Scrum eine Terminaussage gemacht werden?
Ja, kann natürlich. Bei Scrum ist der Termin und die Qualität fixiert. Eine feste Funktionalität kann jedoch nicht zugesagt werden. Wichtig: Es werden jedoch immer die Themen mit der höchsten Priorität geliefert – damit erhält man das beste mögliche Ergebnis.

Einführung von Scrum in Startups
Interessant war auch die Frage, wie Scrum bei einem Startup (= sehr begrenzte Mittel) eingeführt werden kann. Mein Vorschlag: Beschäftigt euch zunächst selbst mit dem Thema, schaut euch Videos an, lest Artikel und Bücher und fangt an, Dinge auszuprobieren. In einem zweiten Schritt solltet ihr ein Training besuchen und euch zertifizieren lassen. Dann setzt das Gelernte um. Letztendlich solltet ihr euch einen Coach leisten, der eure Scrum-Implementierung weiter verbessert.

Insgesamt war die Diskussion natürlich viel spannender als die 0815 Folien ;-)

*UPDATE*

Für alle, die einen Eindruck der Stimmung beim FUcamp gewinnen möchten hier ein nettes Video:

FuCamp 2009 from schwan on Vimeo.

Folgendes Video zeigt die grundsätzliche Funktionsweise von Scrum jedoch innerhalb von 13 Sekunden!

Für Erklärungen bleibt natürlich keine Zeit ;-)

Mike sieht es kritisch, dass in einigen Veröffentlichungen der Eindruck erweckt wird, als ob agile Methoden nur für ein einzelnes kleines Team auf einer einsamen Insel funktionieren würden. Die Beschränkung auf die Beschreibung der Kernkonzepte sei zwar ein guter Ansatz, um die Grundlagen/Konzept zu erklären. Die Wirklichkeit sehe jedoch anderst aus und dies dürfe in Artikeln und Büchern über die agilen Methoden nicht mehr vernachlässigt werden.

Zudem vertritt er die Meinung, dass Agile sehr gut skaliert und deshalb sollte auch mehr darüber veröffentlicht werden.

Beispiel für Skalierbarkeit
Er spricht über ein Projekt mit 700 Personen und wie dieses mit agilen Methoden durchgeführt werden kann.

Zunächst ist es wichtig das übergeordnete Ziel (Vision) durch einen “Chief-Product-Owner” definieren zu lassen. Diese wird dann über eine Hierarchie von Product Ownern in die Teams getragen. Wichtig: Die POs managen das Projekt nicht sondern sind dafür zuständig die Ziele zu formulieren.

Die Teams sind ebenfalls hierarchisch strukturiert, die Koordination der Teams erfolgt durch diese selbst: “… but teams coordinate their work in ways their determine …”.

Mike fasst nochmals zusammen, was nötig ist, damit Teams funktionieren können:

• Geld / Money (Salary, Infrastructure)
• Unterstüzung / Moral Support (Feedback, removing impediments)
• Ziel / Guidance (Vision)

Schätzungen
Im zeiten Teil spricht er Über Abschätzungen und weist darauf hin, dass es für Teams wichtig ist zunächst in relativen Größen zu schätzen. Erst in einem weiteren Schritt können diese Schätzungen dann auf Dauer und Aufwand umgelegt werden.

Seht euch das Video einfach selbst an …

• http://if-blog.de/scrum-plakat/

Eine hilfreiche Zusammenfassung der Basiskonzepte von Scrum:

• Start
• Product Owner (PO)
• Product Backlog (PBL)
• Team (Pigs)
• Sprint
• Sprint Planning Meeting
• Sprint Backlog
• No Changes
• Daily Scrum Meeting
• Burndown Chart (BDC)
• Impedment Backlog (IBL)
• Scrum Master (SM)
• Done
• Sprint Review
• Sprint Retrospective

Zusätzlich enthalten ist das Agile Manifest und eine Übersicht über Prinzipien des “Lean development”.

Macht sich sicherlich gut als (großes) Plakat an der Wand.