13 Leute, 5 Firmen, 3 Standorte. Unmöglich! Oder?

September 18, 2009 at 2:30 pm 1 comment


“Unser Team besteht aus 13 Leuten, die aus 5 Unternehmen stammen und an drei Standorten (inkl. Offshore) arbeiten. Die Teammitglieder sind deutlich erkennbar spezialisert: Neben Java-Entwicklern gibt es Web-Entwickler, Leute für den Content und Qualitätssicherer. Wir haben nicht einen PO, sondern zwei. Und ein Teil der Leute ist auch nur Teilzeit verfügbar. Ach ja: Wir haben übrigens das Product Backlog direkt vor dem Sprint nochmal ordentlich umgekrempelt.”
Wenn man mich vor drei Wochen gefragt hätte, wie groß ich die Erfolgswahrscheinlichkeit für dieses Team einschätzen würde, hätte ich wahrscheinlich “sehr niedrig” gesagt. Und das ist wahrscheinlich auch die korrekte Antwort. Aber “sehr niedrig” ist eben doch etwas mehr als 0, sprich: Das Team hat wirklich sehr gut als Team gearbeitet und ein sehr schönes Ergebnis produziert.

Sehen wir uns dazu einmal ein paar Eckdaten an:

  • Es wurde nach Scrum gearbeitet.
  • Es gab zwei Product Owner, aber es war klar, wer von den beiden im Zeifel die Hosen anhat.
  • Je Standort gab es Colocation inkl. der Product Owner.
  • Der Sprint hatte ein klares, ziemlich wichtiges Ziel: Das System geht für einen definierten Anwenderkreis live.
  • In der Sprint-Planung wurde ein Task-Breakdown durchgeführt. Die Tasks wurden nicht in Stunden geschätzt. Stattdessen gab es die Regel, dass ein Task maximal einen Tag dauern darf und dann wurden die Tasks einfach gezählt.
  • Der ScrumMaster hat bei der Sprint-Planung und während des Sprints dafür gesorgt, dass in Bezug auf dieses Ziel Minimalismus galt. Es wurden nur die Stories aufgenommen, die unbedingt für das Sprintziel notwendig waren.
  • Die Anforderungen wurden als sehr kleine User-Stories formuliert. Noch während der Sprint-Planung wurden die User-Stories weiter in kleinere User-Stories aufgeteilt, so dass die User-Stories danach nur jeweils einen Umfang von wenigen Tagen hatten.
  • Es gab jeden Tag zwei Daily Scrums. Zuerst eines über Skype mit den Standorten und danach noch eines am Hauptstandort.
  • Der ScrumMaster hat insbesondere beim Daily Skype Scrum dafür gesorgt, dass Probleme auch sichtbar und bearbeitet wurden.
  • Am Hauptstandort stand auch das Taskboards und die Sprint-Burndowns (geführt nach Anzahl Tasks und nach Anzahl Story Points).
  • Die Burndowns wurden von Hand auf Flipchart-großem Papier erstellt und gepflegt. Die Stories waren natürlich auch elektronisch vorhanden, aber das elektronisch generierte Burndown war nie wirklich korrekt – die Ursachen dafür zu erklären, führt hier zu weit. Auf jeden Fall waren die händisch erstellten Burndowns die führenden Burndowns.
  • Es gab einen ständig aktiven Skype-Chat für alle Team-Mitglieder.
  • Das Sprint-Review nach dem Sprint war öffentlich im Unternehmen. Die Anzahl der zusätzlichen Teilnehmer war sehr überschaubar. Da aber der zuständige Fachbereichsleiter auch anwesend war, wurde die große Bedeutung des Sprints explizit. Außerdem war damit klar, dass man im Sprint-Review nicht mit einem zufälligen Herumgeclicke durch die Tür kommt.
  • Das Team hat es genau geschafft, das Sprintziel zu erreichen und das System termingerecht live zu stellen. Das Team ist sehr stolz auf seine Leistung und die Product Owner sind sehr zufrieden mit dem Erreichten.

    Damit hier kein falscher Eindruck entsteht. Das war kein einfacher Sprint, den man mal so runterarbeitet. Es gab einen ganz Zoo von Problemen während des Sprints. Die Qualitätssicherer waren zunächst nicht so verfügbar, wie geplant, so dass dort ein Bottleneck entstand. Die Build-Infrastruktur ist bezogen auf automatisierte UI-Akzeptanztests faktisch zusammengebrochen (und während des Sprints auch nicht wieder auferstanden), etc. Aber das Team hat pragmatische und gangbare Lösungen gefunden. Und die bestanden nicht einfach darin, Qualität zu opfern. In dem Projekt wurden sehr viele automatisierte Akzeptanztests geschrieben und die entstandenen Code- und Teststrukturen können sich sehen lassen.

    Meine ganze persönliche Bewertung der Geschichte: Ich glaube, dass Fokussierung ausschlaggebend für den Erfolg des Teams war. Dazu hat es z.B. sehr geholfen, nur die Stories einzuplanen, die unbedingt für das Sprintziel notwendig waren. Das Team hätte sich während des Sprints zusätzliche Stories geben lassen, wenn es schneller gewesen wäre als geplant. Dazu ist es aber nur in ganz kleinem Umfang gekommen. Stattdessen gab es auch keine “Versuchung” schnell noch ein paar optionale Stories umzusetzen. Stattdessen wurde mehr Wert auf Qualität und Tests gelegt.

    Und einen wesentlichen Anteil an der Fokussierung hatte der ScrumMaster. Das Projekt ist ein schönes Beispiel dafür, wieviel Unterschied ein guter ScrumMaster machen kann.

    P.S.: Ich schreibe das hier nicht, um mich selbst zu loben. Ich habe den ScrumMaster nicht ausgebildet und für das Team kein Scrum-Coaching gemacht – ich war für ein anderes Thema als Coach im Team und bezogen auf Scrum hier nur staunender Beobachter.

    Entry filed under: #. Tags: .

XP-Days Germany am 26-28.11.09 in Karlsruhe Überstunden: Go oder No-Go?

1 Comment Add your own

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: