Scrum Usergroup: Nachbetrachtung vom 22.06.2011
Das Treffen am 22.06. der Scrum Usergroup an gewohnter Stelle im Restaurant
Zucker gestaltete sich erneut als sehr spannend. Die folgenden Themen wurden
in lockerer Runde diskutiert:
* Notwendigkeit eines Erfahrungsaustauschs in einer Art "Scrum of Scrums" in dem
sich Projektteilnehmer in ihren unterschiedlichen Rollen austauschen können
und so den gedanklichen Horizont erweitern können. Hier bestand Einigkeit darin,
das solche Treffen sehr sinnvoll sind und sich hier natürlich auch die
Scrum Usergroup selbst als Plattform anbietet.
Weiterhin kam der Gedanke auf die Entwicklerteams nach einigen Sprints zu
mischen um so unterschiedliche Sichtweisen und Erfahrungsstände verteilen
zu können.
* Das Thema Tools für das Konfigurations- und Change-Management und der Umgang
mit Branching und Integration von Features wurde besprochen. Insbesondere
die Tatsache, dass Tools oft von der Unternehmensseite her vorgegeben werden
führt dazu, dass die Entwickler unterschiedliche Vorangehensweisen entwickeln
(müssen) um mit bestimmten Restriktionen in der Praxis gut zurecht zu kommen.
Ein klassischer Fall von Impediments die immer wieder in der Praxis auftauchen.
Sofern machbar sollte hier von Fall zu Fall die Möglichkeit der Unternehmens-
leitung geschaffen werden, dass ein höherer Grad an Flexibilität für
Entwicklerteams geschaffen werden kann um z.B. State-of-the-art Tools wie
z.B. Git oder Subversion nutzen zu können, die nicht umsonst im Open-Source-
Umfeld eine hohe Verbreitung erfahren.
* Die Tool-Frage mündete weiterhin in die Diskussion über die notwendige
"Rückendeckung" die durch die Geschäftsleitung und Management-Ebene erforderlich
ist, um Scrum richtig erfolgreich zu machen. Es zeigt sich, das oftmals
eine zumindest offizielle Rückendeckung und der Wunsch nach Scrum seitens
des Managements exisitert, jedoch im Falle von Impediments öfter vor den
Lösungen die das Team ermittelt zurückschreckt.
Konkrete Fälle die hier aufkamen waren: Support der durch Entwicklerteams
geleistet wird und das Team in der Arbeit stört. Die gefundenen Lösungen
(z.B. ein Indikator für Dritte der anzeigt das man momentan ungestört
arbeiten möchte -> USB-Ampel) funktionieren in der Praxis jedoch oftmals
nicht. Das Telefon klingelt trotz einer roten Ampel und der Projektleiter
der ein dringendes Anliegen hat, spricht den Entwickler trotzdem an obwohl
die Ampel auf rot steht.
Hier wurde darauf hingewiesen, das getroffene Vereinbarungen im Team nicht
notwendigerweise direkt auf die Umwelt übertragen werden können. Das eine
rote Ampel bedeutet das man nicht gestört werden möchte bedeutet für den
Projektleiter nicht automatisch, das sein Anliegen auch auf anderen Kanälen
erhört und umgesetzt wird.
Auch ein klingelndes Telefon welches den Arbeitsfluss stört, erfordert
bestimmte Lösungsansätze. Eine Möglichkeit besteht darin, im Team festzulegen
wer den Telefondienst übernimmt. Dieser muss natürlich instruiert sein, wie
genau er mit den entstehenden Anfragen umgehen kann.
Die Frage der Störung in der konzentrierten Tätigkeit war insbesondere
auf Entwicklerebene eine brennende. Der entstehende "Sägezahneffekt"
stellt sich entsprechend als Impediment heraus und erfordert Fingerspitzen-
gefühl insbesondere auch für den Scrum Master.
Als Tipp für das Selbstmanagement sei hier nochmals die Pomodoro Technique
genannt, die auf Detailebene eine gute Unterstützung in der täglichen
Planung gibt. www.pomodorotechnique.com
* Notwendige Kompetenzen eines Scrum Masters waren ebenfalls von Interesse:
Sinnvollerweise hat der Scrum Master über das Maß der Zertifizierung
entpsrechende Soft Skills und kommunikative, sowie auch diplomatische
Fähigkeiten die man nicht im Zertifizierungskurs erwirbt.
Gleichzeitig wurde noch auf die Tatsache hingewisesen, dass
der Scrum Master das Team und dadurch die Organisation anleitet Probleme
selbststänig zu beseitigen um den maximalen Effekt zu haben. Oft wird in der
Praxis aus kostengründen und der Einfachheit halber dazu übergegangen
jemanden aus dem Team zu bestimmen der den Scrum Master macht. In der Praxis
steht diesem dann meistens ein Interessenskonflikt bevor, da er selbst auch
im Team ist. Fehlt dann noch die notwendige Rückendeckung der Führungsriege
kann der Scrum Master seine Effektivität nicht voll ausspielen.
Sinnvoll ist hier der Einsatz eines externen Scrum Masters um insbesondere
auch den sich einstellenden "Tunnelblick" zu verhindern und jemanden in
die Organisation zu holen der sich "die Hände schmutzig machen kann".
Ziel ist es letztendlich, das sich der Scrum Master selbst "wegrationalisiert".
* Der Umgang mit Änderungen während des Sprints war ein weiteres Thema. Die
Grundidee des Scrum Frameworks besteht darin dynamische Änderungen im Projekt-
ablauf zu unterstützen und ist eines der Kernelemente. Daher sollte die
Tatsache das sich auch in einem laufenden Sprint noch etwas ändern kann vom
Team immer wieder berücksichtigt werden. In der Praxis stellt dies für das
Team oft eine Schwierigkeit dar. Es kann auch dazu kommen das sich durch
ständige Änderungen ein gewisser Frustrationsgrad einstellt. Hier ist
insbesondere auch von Seiten des Product Owners Fingerspitzengefühl gefragt
und er sollte außerdem Feedback vom Team in dieser Richtung ernst nehmen.
Es ist oft so, dass vom Team sehr sinnvolle Ideen für die Weiterentwicklung
bestehen die ein enstprechendes Forum benötigen. Es bietet sich daher an,
das der Product Owner bei den Daily Standups teilnimmt um eine schnelle
Reaktion zu ermöglichen.
In der Praxis ist es oft so, dass der Product Owner nicht immer zu greifen
ist, oder sogar manchmal nur halbtags oder örtlich getrennt arbeitet (Off-Shore).
Über den Einfluss von räumlicher Trennung wurde ebenfalls gesprochen und
es bestand Einigkeit darin, dass bereits eine Hürde besteht, wenn das
Entwicklerteam z.B. über einen Flur in unterschiedliche Räume "verteilt wird".
Der Einfluss erstreckt sich natürlich auch auf den Product Owner. Er sollte
für das Team permanent greifbar sein. Daher ist diese Rolle auch als
Full Time Job definiert (anders als z.B. beim Scrum Master, der durchaus
mehrere Teams parallel betreuen kann)
Alles in Allem war es wieder mal ein sehr interessantes Treffen bei dem viele
neue Ideen entstanden. Ich möchte mich an dieser Stelle bei allen Teilnehmern
für die interessanten Themen und offene Teilnahme an den Diskussionen bedanken.
Weiterhin hoffe ich, dass ich alle Themengebiete entsprechend hier wiedergegeben
habe.
Die nächste Usergroup wird voraussichtlich im September statt finden, nachdem
der wohlverdiente Jahresurlaub bei den meisten von uns leider schon wieder
hinter uns liegen wird ;)