auf der ISS ist die Toilette kaputt.
http://www.spiegel.de/wissenschaft/weltall/0,1518,556203,00.html
vielleicht sollte die Scrum Alliance so ein Szenario als CSM Test aufnehmen
another comment to a post from Boris – I hope it’s ok for him beeing my primary comment-target 
this time in english – cause the original post is in english (hope that someone will understand me).
So instead of having four teams:
- one in PL
- one in HUN
- one in AUT
- one in DE
You have 4 Teams:
- one in PL, HUN, AUT, DE
- one in PL, HUN, AUT, DE
- one in PL, HUN, AUT, DE
- one in PL, HUN, AUT, DE
I mentioned this in my CSM Training in Frankfurt. I think this structure is very useful for “cross department” teams in companies too! Sometimes it is much harder to bring two departments to work together within a single location than two developers on different continents. I think this setup is the way to scale projects over a company too (within a single location).
So when Department 1,2 and 3 shall do a project together, don’t go for:
go for Boris style (Jeff Sutherland recommends this too):
This is very helpful when you are confronted with strong classical department structures.
Heiko
Ein Projektleiter will von mir, dass er kontinuierlich über den Stand seiner Story im Sprint informiert wird, insbesondere, da seine Story zu Beginn des Sprints bearbeitet werden muss. Da wir für sehr viele Projekte gleichzeitig arbeiten (Impediment), hab ich ihn gebeten, dass er doch z.B. in den Dailies vorbei kommt und sich ein Bild macht.
Die Antwort: Das ist in Scrum nicht so vorgesehen, denn das Team muss schließlich aktiv über den Stand und Verzögerungen berichten. Um der Antwort noch mehr Gewicht zu geben, war das Ganze mit einem anderen Scrum Master abgesprochen.
Für mich ist das ein typischen Zeichen für Scrum im Verteidigungsmodus. Also die Art von Scrum, die zwar beim Organisieren der Arbeit hilft, aber nicht den Geist von Agiler Software Entwicklung trifft.
Kommunikation als einseitige Bringschuld kann nicht funktionieren! Scrum als Regelset kann nicht funktionieren. Scrum ist ein Mindset – eine Einstellung. Und zu dieser Einstellung gehört für mich, dass man aus allen Richtungen aktiv an der Lösung einer Aufgabe arbeitet.
…
hey – meine Posts werden immer pathetischer – hmmm
“Eine Story nach der anderen!”,
“Macht keine Dinge nebenher, sondern fokussiert Euch auf die Stories”,
“Zulieferung zu Sprint Beginn nicht vorhanden -> Story kommt nicht in den Sprint”
“Unit-Testabdeckung < 100% -> Story nicht fertig”
“Story nicht fertig -> keine Velocity”
Sätze in der Art würde und könnte ich jeden Tag loswerden – und es handelt sich nur um die Themen, auf die ich Einfluss habe. Nur… obwohl Disziplinarvorgesetzter und… obwohl es in meiner “Macht” stehen würde, diese Dinge einzuforden… es geht nicht. Die Teams würden Scrum sehr bald ablehnen.
Scrum ist ein täglicher Kampf, ein tägliches Abwegen zwischen richtig und machbar. Scrum ist ein Prozess mit einem sehr hohen Energiepotential. Und wir wissen aus der Physik, dass die Grundrichtung potentiell in die andere Richtung geht.
Mit stellt sich immer mehr die Frage ob dieses Energieniveau durch stetiges Wachstum zu erreichen ist, oder ob es doch nur über einen Sprung abläuft?
Für alle Scrum Master da draußen: wir brauchen keine Angst zu haben, dass wir überflüssig werden (manchmal ließt man das). Unsere Aufgabe ist durch die Physik festgeschrieben. Unsere Energie ist dafür da, das Potential von Scrum zu erreichen oder zu halten!
“Raus aus den functional silos” , “bildet heterogene Teams” – das sind Aufforderungen, die man so in der Scrum Community ließt. Ich kann ihnen nur zustimmen, allerdings werfen heterogene Teams auch Probleme in der täglichen Arbeit auf.
Das Problem ist: heterogene Teams brauchen heterogene Aufgaben. Also Aufgaben, die das Team möglichst gleichmäßig auslasten. Schließlich will man nicht, dass Teammitglieder “Däumchen” drehen. Das ist in der Praxis aber nicht immer ganz einfach.
Ein verlockender Weg ist, dass man das Team an verschiedenen Stories mit unterschiedlichen Themen arbeiten lässt. In den Sprintplanning Sitzungen muss man darauf achten, dass Stories, die alle Teammitglieder auslasten in die Planung aufgenommen werden.
Dieser Weg geht aber aus meiner Sicht in die falsche Richtung. Das Problem ist, dass der Fokus verloren geht, die Teammitglieder arbeiten an unterschiedlichen Themen und man muss bei Auswahl der Sprintthemen auf die Auslastung des Teams achten (-> der Business Value bekommt Konkurrenz).
Der andere Weg bildet die Teammitglieder zu Generalisten aus, die auch andere Rollen im Team einnehmen können. Also nicht nur crossfunctional Teams, sondern crossfunctional Teammember . Allerdings ist das ein schwieriger und zeitaufwändiger Weg. Letztendlich zahlt er sich aber sowohl für das Team, als auch für das einelne Mitglied aus. Für den Scrum Master stellt er aber hohe Anforderungen an seine Fähigkeiten, die Mitarbeiter zu entwickeln!
Fazit: Funktionierende Heterogene Teams stellen das große Ziel im Scrum Prozess dar. Allerdings muss man diese Teams entwickeln. Heterogene Teams brauchen Teammitglieder, die verschiedene Aufgaben im Team übernehmen können! Allein das Zusammenstellen von verschiedenen Rollen zu einem Team reicht nicht aus!
