Die Reihe “SLM: Scrum Learning Material” kann um ein weiteres Trainingsvideo ergänzt werden:
Leider wird das Konzept der Retros nicht erklärt, ansonsten eine gute Zusammenfassung.
Die Reihe “SLM: Scrum Learning Material” kann um ein weiteres Trainingsvideo ergänzt werden:
Leider wird das Konzept der Retros nicht erklärt, ansonsten eine gute Zusammenfassung.
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:
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.
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:
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.
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.
Die Aufteilung
ist sehr hilfreich, gerade wenn man Scrum erklären möchte.
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 …
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
Scrum als “silver bullet”
Jetzt aber!
Hey, wie sieht bei euch der IMPEDIMENT MONKEY aus?
Wer noch nicht verstanden hat, warum in Scrum von Pig und Chicken die Rede ist, der darf sich gerne folgendes Video ansehen. In diesem wird es nochmals schön anschaulich verdeutlicht (Ham and Eggs).
Beim schmökern im PM-Blog bin ich mal wieder fündig geworden:
Eine schöne Präsentation, die die Ansätze und Philosophie hinter agiler Softwareentwicklung / Scrum erläutert. Ergänzt die Reihe “Scrum Einführungs Videos/Präsentationen” recht gut!
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:
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):