SLM: JAOO: Slides verfügbar

Die Folien zu den Vorträgen der JAOO Conference 2008 können heruntergeladen werden:

http://jaoo.dk/aarhus-2008/schedule/wednesday.jsp

Es sind einige interessante Vorträge zu agilen Themen dabei:

  • Henrik Kniberg: What’s Hard About Becoming an Agile Software Developer?
  • Guido Schoonheim & Jeff Sutherland: Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams. (Hinweis zu Video – s.u.- beachten)
  • Petri Haapio: Can a global company of 60 000 people with strong legacy culture change its habits?
  • Dave Thomas: Lean and Agile In the Large – Principles, Practices and Experiences for Large Scale Software Development

Zusätzlich gibt es einige Videos:

http://jaoo.blip.tv/posts?view=archive&nsfw=dc

Das Video “Offshoring Agile Projects” hatte ich bereits vor ein paar Tagen empfohlen.

SLM: Agile Offshoring – With Success!

YOU NEED TO COMMUNICATE!

Ein sehr lehrreiches Interview mit Jeff Sutherland & Serge Beaumont in dem die Geheimnisse erfolgreicher agiler Softwareentwicklung mit verteilten (offshore) Team besprochen wird.

Obwohl Offshoring auf den ersten Blick dafür geschaffen zu sein schein, um Kosten zu sparen wird in vielen Projekten eine andere Erfahrung gemacht: Nur wenn die indischen Entwickler so produktiv sind wie die lokalen Entwickler rentiert sich Offshoring unter Kostengesichtspunkten. Jeff spricht ein Beispiel an, in dem die Kosten für einen indischen Entwickler lediglich 1/3 so hoch waren wie die für einen Entwickler im lokalen (US) Team. Trotzdem hat sich das Offshoring  nicht gelohnt. Diese Erfahrung wurde genutzt, um die Kostentreiber zu identifizieren und Praktiken zu entwickeln, welche die Probleme verringern. Kommunikation und Vertrauen stehen seitdem im Fokus.

Die Herausforderung ist es, bei einem verteilten Team eine funktionierende Kommunikation zu etablieren und ein echtes Team zu formen. Es gilt technische und psychologische Hürden zu überwinden.

Einige Best Practices:

  • Kommuniziert! Sorgt dafür, dass die Kommunikation zur gleichen Zeit von allen Seiten vorangetrieben wird, damit der “Kommunikationsgraben” überwunden wird.
    • Hier ist v.a. der Scrum Master gefragt alle möglichen Hindernisse so schnell wie möglich aus dem Weg zu räumen.
  • Lernt euch kennen! Bei verteilten Teams ist es wichtig, dass gegenseitige Besuche von Teammitgliedern stattfinden. So entsteht Vertrauen.
  • Daily Standup so organisieren, dass alle Teammitglieder teilnehmen können! Konkret bedeutet dies den Einsatz von Telefon- und Videokonferenzen und Screensharing. Wenn möglich elektronische Whiteboards einsetzen.
  • Moderne Kommunikationsmittel nutzen! Alles nutzen das irgendwie helfen kann! Videowalls, elektronische Whiteboards, Screensharing, IM, …
  • Velocity des lokales Teams muss bekannt sein bevor Mitglieder am entfernten Standort hinzugezogen werden! Nur so kann gemessen werden, ob die Produktivität steigt oder sinkt.
  • Scrum Master nach Indien/Russland/Hindukusch. Ja, der SM wird verschickt ;-)

Leider habe ich es bisher selbst nur zu einem einzigen REMOTE DAILY gebracht – und davon habe ich mangels Equipment auch nicht sonderlich viel mitbekommen.

Im zweiten Teil wird noch über die Herausforderungen der Rolle “Product Owner” gesprochen, v.a. dass diese Rolle meist unterschätzt wird.

SLM: Übersichtsfolie zu Scrum

Bei Slideshare gefunden, eine hilfreiche Übersicht über die Aspekte von Scrum:

A Scrum Tool condensed in a foldable A5 sheet (front-back). It’s easy to inspect and adapt the scrum process by checking a smell during an event.

http://www.slideshare.net/fmondora/scrum-tool

Die Aufteilung

  • who/wer
  • when/wann
  • what/was
  • how/wie
  • smells/Gerüche

ist sehr hilfreich, gerade wenn man Scrum erklären möchte.

SLM: Scrum Haka!

SLM: Scrum Learning Material – Scrum Haka!

Die Sammlung der besonders wertvollen Trainingsvideos zu Scrum wird um ein weiteres Meisterwerk ergänzt.

Seht selbst und staunt, lernt und erschreckt mit dem Scrum Haka den letzten ollen Vertriebler der sich in euere Scrum-Gründe (Team-Zimmer) wagt!

Hintergrund: “Traditionell ist er ein integraler Teil der Willkommens- und Unterhaltungszeremonie für Gäste. Er war außerdem ein Mittel, um für einen bevorstehenden Kampf Mut zu machen und Angst bei den Gegnern hervorzurufen.” (Quelle: Wikipedia)

Bei IT’lern sieht das ungefähr so aus:

Verbesserungspotential erkennt man, wenn man sich die Profis anschaut:

Video mit einigen Erläuterungen:

Muss ich echt bei mit dem Team ausprobieren, nachdem wir brav online trainiert haben. Da sollen sie doch noch mal kommen – die Vertriebler …

SLM: Überwindung des Impediment Monkeys!

Ha!

Hat ja mal wieder einige Zeit gedauert. Aber nun ist es soweit:

Die Sammlung der besonders wertvollen Trainingsvideos zu Scrum wird um ein weiteres Meisterwerk ergänzt.

Seht selbst und staunt, lernt und jagt den Impediement Monkey (yessss!)!

Kurze Zusammenfassung:

Wasserfall

  • Knechtschaft und stundenlange Statusreports

Scrum als “silver bullet”

  • Juhu!
  • Team is Happy
  • Implediment Monkey is on the loose!
  • .. und kommt wieder zurück um eine Ressource eine Entwicklerin zu stehlen
  • .. wird aber schliesslicht überwältigt
  • Scrum makes obvious the impediments that people must solve

Jetzt aber!

Hey, wie sieht bei euch der IMPEDIMENT MONKEY aus?

SLM: Ein paar Gedanken zu Scrum

In der typischen Interpretation der Scrum-Methodik ist die Rolle eines Projektmanagers nicht mehr vorgesehen. Die fachliche Projektleitung obliegt dem Product Owner, die technischen Entscheidungen werden durch das Team getroffen. Der Scrum Master sorgt für Einhaltung der Regeln, coacht das Team (und den Product Owner) und kümmert sich um Blocker/Hindernisse.

Für mich stellen sich hierbei zwei Fragestellungen bei der organisatorischen Restrukturierung:

  • Wie können mehrere Projekte in einem Team bearbeitet werden?
  • Was geschieht mit der Linienorganisation?
  • Scrum und Architektur?

Mehrere Projekte pro Team
Im „ein-Projekte-Scrum“ gibt es typischerweise den klassischen Projektmanager nicht mehr. Wenn jedoch mehrere Projekte in einem Team bearbeitet werden sollen, so hat ein PM wieder eine gewisse Berechtigung. Er stimmt sich mit dem PO des Team ab, damit der PO die Prioritäten richtig setzen kann. Er muss auch bei Rückfragen des Teams verfügbar sein. Die Hauptaufgabe des PM ist in dieser Konstellation jedoch die Kommunikation mit dem Kunden und die Einlastung von Aufgaben (Stories) in verschiedene Scrum-Teams. Die Zusammenarbeit mit verschiedenen Scrum-Teams wird gerade in komplexen Projekten nötig, in denen viele unterschiedliche Aufgaben anfallen und unterschiedlichste Experten (gibt es ja laut reinem Scrum in dieser Form auch nicht) benötigt werden.

Kunde > PM > PO > Team

Zu kritisieren sind hier die vielen Zwischenstation vom Kunden zum Team. Im Rahmen von Rückfragen muss es daher immer gestattet sein, dass das Team direkt mit dem Kunden redet, um Unklarheiten zu beseitigen. Wenn möglich sollte hierbei PM und PO involviert sein.

Linienorganisation und Vorgesetzte
Ich beobachte, wie die Linienvorgesetzten zunehmen als Scrum Master agieren. Je nach Firmenkultur und Persönlichkeit des SM kann dies jedoch problematisch werden – genau dann, wenn der SM nicht mehr coacht sondern Anweisungen erteilt. Grundsätzlich sollte über eine Vereinfachung der Linienorganisation nachgedacht werden, d.h. kleinere Abteilungen könnten zusammen gelegt werden, da viele Aufgaben des klassischen Vorgesetzten zurück an das Team delegiert werden und weil Hindernisse durch Scrum Master beseitigt werden sollten. Was bleibt ist die reine Personal- und Budgetverwaltung.

Scrum und Architektur
Laut Scrum soll das Team alle Entscheidungen hinsichtlich Umsetzung treffen. Es kommt jedoch relativ häufig vor, dass das Team nicht zu allen Themen die benötigte Expertise besitzt. In diesem Fall muss darauf geachtet werden, dass das Team mit Experten zusammen arbeitet und somit ganz bewusst externe Hilfe in Anspruch nimmt. Dies muss das Team auch rechtzeitig kommunizieren. In anderen Fällen, dominiert ein einzelnes Team-Mitglied das Team in wichtigen Fragestellungen. Da das ganze Team jedoch für den Erfolg einer Aufgabe verantwortlich ist, muss sichergestellt werden, dass alle Team-Mitglieder ausreichende Kenntnisse haben um eine Alternative richtig bewerten zu können. Sollte ein Mitglieds des Teams zu dominant werden, dann muss der Scrum Master eingreifen.

Noch eine Einführung in Scrum
So, und jetzt mal wieder ein Video zur Einführung in Scrum (für alle die immer noch nicht genug haben):