Puzzled Kitty © David K
Agile Teams leben in der Grauzone: Skills und Aufgaben sind keine Frage von Schwarz oder Weiß, ich oder Du.
Wenn die Testerin zum «Bottleneck» wird, weil Entwickler nicht wissen
(wollen), wie man ein Testskript anwirft:
schlecht fürs Ziel. Wenn der Product Owner (PO) keinen Sinn darin sieht,
von Anfang an mit der Testerin an brauchbaren Akzeptanzkriterien zu
feilen: schlecht fürs Ziel. Wenn die Testerin zwar programmieren könnte, aber sich sträubt, auch mal Unittests zu erweitern: schlecht fürs Ziel.
Der Scrum Guide sagt:
Unabhängig von der verrichteten Arbeit werden die Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Scrum sieht keine anderen Titel für die Mitglieder eines Entwicklungs-Teams vor; es gibt keine Ausnahme von dieser Regel
Das bedeutet für das interdisziplinäre Team eben nicht, dass jeder wirklich alles und noch dazu gleich gut können muss. Es bedeutet, dass jeder zu jedem Zeitpunkt Meister, Geselle und Azubi zugleich ist, nur eben auf unterschiedlichen Gebieten - und immer wieder von neuem.
Agiles Teamwork lebt von dieser Grauzone. Davon, dass nicht danach gefragt wird, wer für das Erreichen des Ziels verantwortlich ist, weil die Antwort ohnehin klar ist: das gesamte Team.
Wann immer das Schwarz-oder-Weiß-Spiel («Was soll ich denn noch alles können?», «Das ist nicht mein Job!», …) gespielt wird, um letztlich gar nichts außerhalb der eigenen Expertise kennen lernen zu müssen: schlecht fürs Ziel. Eine meiner wichtigsten Fragen an jedes Team ist deshalb: wie spielt Ihr denn statt dessen das Meister-Geselle-Azubi-Spiel, so dass es funktioniert?
Shu-Ha-Ri-Sprints: lernen, verstehen, vermitteln
Ein interessanter Weg neben z.B. Workshops, Schulungen und Communities of Practice (CoPs): das Team erklärt jeden Sprint zu einem Shu-, Ha- oder Ri-Sprint, rotierend.
