On Saturday I gave a short lightening talk about “Definition of READY”. I didn’t like my performance on the stage but I got some positive feedback from Oleksiy Rezchykov in his blog post where he recommends my lightening  talk.

Another article with positive feedback for my Lightening Talk can be found at ConfRadar:

Felix Russel did a good job reminding about the “definition of ready” and the time each product owner should spend on preparing stories before the team can actually swarm around them. It was one of the lighting talks during the second day, that I attended.

The slides are available via Slideshare:

Die PDF-Version kann hier herunter geladen werden:

Viel Spaß beim lesen. Über Feedback freue ich mich natürlich!

Meinen nächsten Vortrag mit dem Titel "Traditionelles Projektmanagement und Scrum – Wie Feuer und Wasser?" halte ich auf dem diesjährigen Scrum Day.

„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.

Herausgegeben von Roman Pichler und Stefan Roock mit Beiträgen von Andreas Havenstein, Johannes Link, Bernd Schiffer, Martin Lippert, Alex Bepple, Jens Coldewey, Henning Wolf, Peter Friese und Jutta Eckstein.

“Agile Entwicklungspraktiken mit Scrum”, geschrieben von einigen der bekanntesten deutschen Verfechter agiler Entwicklungsprozesse, ist ein kompakter Überblick über wichtige Entwicklungspraktiken, die eine erfolgreich agile Projektdurchführung erst ermöglichen.

Einige der Praktiken empfinde ich als essentiell (Architekturvision, Continuous Integration) oder sehr wichtig (Refactoring, Inkrementeller Entwurf, Pair Programming und Collective Ownership), für andere empfinde ich lediglich eine gewisse Neugier (Dojos und Kata), was daran liegen mag, dass ich nicht mehr aktiv programmiere. In Summe enthält der vorgestellte Katalog für agile Entwickler wichtige Anregungen zur weiteren Professionalisierung. Dies ist wichtig, da nur mit professionellen und stets nach Verbesserung strebenden Entwicklern agile Prozesse funktionieren können.

Überblick über die besprochenen Themen:

• Architekturvision
• Inkrementeller Entwurf
• Continuous Integration
• Testgetriebene Entwicklung
• Refactoring
• Automatisierte Refactorings
• Automatisierte Akzeptanztests
• Pair Programming und Collective Ownership
• Dojos und Katas
• Modellgetriebene Entwicklung
• Verteilte Entwicklung

Mein Fazit: Das Buch ist eine Empfehlung, vor allem, wenn moderne (agile) Entwicklungspraktiken im eigenen Unternehmen noch nicht stark verbreitet sind. Es gibt einen guten Überblick und eine Menge Anregungen. Zur Vertiefung greift man dann zu der entsprechenden Spezialliteratur.

Ähnlich sieht es auch mein aktueller Projektkollege Fabian Kiss:

“Die im Buch vorgestellten Praktiken mögen größtenteils zum alten Eisen der agilen Softwareentwicklung gehören. So könnte man meinen, es handle sich um die übliche aufgewärmte Agile-Literatur, die kaum neues an inhaltlicher Substanz bietet und dabei inflationsgemäß Scrum mit agiler Entwicklung im Allgemeinen gleichsetzt. Auch wenn der methodische Bezug einzelner Praktiken zu Scrum tatsächlich manchmal etwas beliebig und eher didaktisch motiviert erscheint, überzeugen die Autoren mit einer klaren Botschaft: Scrum allein reicht nicht aus. Es kommt von Haus aus nicht mit einer Anleitung zum Einsatz konkreter softwaretechnischer Praktiken daher. Projekte, die mit Scrum als Projektmanagement-Framework ausgeführt werden, schlagen ohne ein maßgeschneidertes Komplement aus solchen Praktiken früher oder später fehl. Neben den von XP bekannten Verdächtigen wie Pair Programming, Refactoring und Test-First-Ansätzen schlagen die Autoren hierfür auch Praktiken wie Katas oder Modelgetriebene Entwicklung vor, welche im agilen Milieu (noch) eher selten vorzufinden sind. Insgesamt ist das Buch als knapp gehaltene, dafür aber relativ umfassende Übersicht über Scrum-konforme technische Praktiken zu empfehlen. Zum einen enthält es behutsam ausgewählte Verweise zu weiter ins Detail gehender “Pflichtlektüre”, zum anderen werden aber auch jede Menge aktuelle Tools besprochen, mit welchen die Praktiken erfolgversprechend umgesetzt werden können. Also nicht nur was für Scrum-Novizen!”

.. its designed by a software engineer who has no emotions. I think he is a robot …

High Moon Studios: A Portrait – Scrum

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.

(Oft habe ich mich gefragt, wer den CSMs diesen Unsinn erzählt hat… )

Wahnsinn, wie innovativ ich schon vor Jahren war ;-) – damals mit einem Kollegen (Wolfgang for president!) ein Excel-Spielzeug ähnlich wie es Jeff Sutherland jetzt promotet erstellt und dann Aussagen wie “It’s Effort, Not Complexity” von Mike Cohn.

Wirklich befriedigend, diese Bestätigung zu bekommen. Schade nur, dass wir gerade zurechtgestutzt werden, nachdem wir die Probleme transparent gemacht haben. Ist die Gegenreaktion der Linie, vgl. auch “Die dunkle Seite von Scrum”.