.NET Open Space Süd 2009 in Ulm - Tag 1: Scrum

Nachdem Thomas Bandt ja schon erklärt hat, was beim .NET Open Space Süd 2009 so passiert ist, kann ich mich hier ja glücklicherweise auf das Posten meiner Notizen beschränken.

Die erste Session drehte sich um das Thema Scrum:

Einführung

• keine Aussage, wie entwickelt wird - das Team soll dies selbst regeln
• Vorgesetzter kann als Scrummaster problematisch sein, da er "über" den Teammitgliedern steht
• Aufgaben (geforderte Features) für nächsten Sprint werden in Punkten abgeschätzt - NICHT IN STUNDEN
• Länge eines Sprints: 2-4 Wochen, im Web-Bereich häufig nur eine Woche
• keine Belohnungen/Sanktionen, da sonst die Qualität leidet
• Regel: keine neue Karte nehmen, wenn man noch alte hat

Daily Scrum

• Diskussionen abblocken und nach dem Meeting klären
• prägnant erreichte Ziele von heute und geplante Ziele für nächsten Tag nennen, nicht erzählen, was denn so alles über den Tag passiert ist
• Scrummaster muss Probleme heraushören (auch nicht explizit genannte)

Nutzen

• sichtbaren Ergebnis für den Kunden nach jedem Sprint
• starke Kommunikation im Team
• Commitment auf die Aufgabe
• Product owner ist Teil des Teams
  • hat mehr Verantwortung
  • muss während des Sprints zur Verfügung stehen
  • muss klare Vorgaben geben
• mehr Struktur, klare Vorgaben

Gefahren

• Scrum allein enthält keine langfristige Planungskomponente
• evtl. mangelnde Effizienz über Projektlaufzeit
• keine Sicht auf großes übergeordnetes Ziel
• Erfolg steht und fällt mit der Qualität des Backlogs
• keine Basis für Angebotserstellung
  • Lösungsansatz: Spezifikation im ersten Sprint erstellen

Sonstige Themen in der Session

• Release spring: Phase kurz vor einem Release, in der nur noch kosmetische Änderungen durchgeführt werden und parallel relativ zuverlässig getestet werden kann
• Sprint-Burn-Down-Charts zeigen an, wie gut man in der Zeit liegt:

• "Kartenstatus"-Diagramm dient dem gleichen Zweck, spart aber die Malarbeit, durch Zuordnung der Karten zu einem Status:

Fazit
Schöner Rundumschlag zum Thema mit einer guten Mischung aus Theorie und Erfahrungen. Highlight war für mich der Input von Thomas Schissler, der das Konzept seines Unternehmens vorstellte: Dort werden am Anfang zwischen 30 und 60% der Projektlaufzeit für die Erstellung der Oberfläche genutzt. Erst wenn Kunde mit Oberfläche einverstanden ist, wird implementiert. Dies erscheint mir ein sehr sinnvoller Ansatz!

In einer späteren Session erfuhr ich dann auch, was passiert, wenn Scrum falsch eingesetzt wird. In diesem Fall muss SCRUM einfach rückwärts gelesen werden