Agile Minds

„Less is more“ – auch bei Large-Scale Scrum

„Large-Scale Scrum“, kurz LeSS, ist ein möglicher Skalierungsansatz von Scrum. Dabei arbeiten bis zu acht Teams an einem einzigen Produkt. Entsprechend gibt es klarer Weise genau ein Product Backlog und genau einen Product Owner. Wie ist es aber um die Scrum Master bestellt bzw. sind die Teams ein reines „Development Team“ oder ein komplettes „Scrum Team“ inklusive Product Owner und Scrum Master?
Die Erfinder von LeSS sehen die Teams als Scrum Teams. Folglich gehört der eine Product Owner logisch zu den Teams und jedes Team sollte also auch im besten Fall einen eigenen Scrum Master haben. Die Empfehlung ist, dass ein Scrum Master durchaus bis zu drei Teams in LeSS betreuen kann, optimalerweise aber, wie gesagt, genau nur ein Team.

Angenommen, jedes Team hat tatsächlich seinen eigenen Scrum Master, so ist dieser, und tatsächlich nur dieser, in der jeweiligen Team Retrospective anwesend. Dieses Meeting gibt es in LeSS erwartungsgemäß auch und folgt auch den selben Regeln wie im klassischen Scrum, d.h. das Meeting ist nicht öffentlich und damit auch explizit nur für Mitglieder des jeweiligen Teams da. Das Meeting dient bekanntlich dem „inspect and adapt“, also dem kritischen Hinterfragen des Teams, was gut läuft und beibehalten werden sollte und was verbesserungswürdig ist und wie man es konkret verbessern kann. Entsprechend werden Maßnahmen eingeleitet. Kommt ein Team in LeSS dabei zu dem Punkt, dass es etwas ändern möchte, das nicht nur das Team alleine betrifft sondern auch Auswirkungen auf die anderen LeSS Teams hat, so kann es leider nicht selbst die Umsetzung angehen, sondern muss zunächst irgendwie die Fakten mit den anderen Teams besprechen. LeSS kennt dafür die „Overall Retrospective“. Wie der Name schon sagt, werden dort die Themen angegangen, die alle oder zumindest mehrere Teams betreffen. Genau hier sind wir an einer Achillesverse angelangt.

Zunächst ist ein Nachteil schlicht die Verzögerung zu nennen, denn die Overall Retrospective kann natürlich erst nach den Team Retrospectives abgehalten werden. Sie einfach zwischen die Team Retrospectiven und das kommende Sprint Plannning zu quetschen, kann kontraproduktiv sein. Sie findet daher oft erst während des nächsten Sprints statt und entsprechend können Maßnahmen im schlimmsten Fall erst im übernächsten Sprint angegangen werden.
Noch schlimmer wird es, wenn andere Teams eine andere Wahrnehmung oder Meinung zu aufgebrachten Themen in der Overall Retrospective haben. Dann kommt es durch Diskussionen ggf. zu weiteren Verzögerungen oder Maßnahmen müssen so umgesetzt werden, dass es keine Auswirkungen auf andere Teams hat. Letztlich ist dies natürlich kein LeSS-spezifisches Problem sondern eine Konsequenz aus der Größe des Gesamtteams und der damit einhergehenden Gruppendynamik und Meinungsvielfalt, wie sie bei solchen großen Gruppen immer angetroffen werden kann. Dennoch kann dies dazu führen, dass die Overall Retrospectiven sich zu einer Frust-Veranstaltung entwickeln, wenn kein Konsens gefunden wird. Eine Konsequenz daraus kann leider sein, dass die Teams ihre Motivation verlieren, Themen aus den Team Retrospektiven überhaupt in der Overall Retrospective vorzustellen. Sie fangen an die Probleme nur für sich zu lösen und dies dann eben oft nicht optimal, denn es muss ja ggf. so umständlich gemacht werden, dass die anderen Teams davon nicht betroffen sind. Oder, falls dies nicht möglich ist, die Problemlösungen gar nicht mehr anzugehen. Der Scrum Master des jeweiligen Teams bekommt dies natürlich spätestens in der Team Retrospective mit und wird versuchen, dies nicht zu zulassen, aber was, wenn dies nicht gelingt? Entweder trägt er es alleine, also ohne Zustimmung des Teams, in der Overall Retrospective, was sein Team durchaus als Vertrauensbruch werten könnte, oder er muss anfangen, bei jedem dieser Themen irgendwie mit Hilfe der anderen Scrum Master die anderen Teams zur Diskussionsbereitschaft oder bestenfalls zum Einlenken zu bewegen. Dann würde er aber letztlich auch einen Vertrauensbruch begehen und außerdem ist dies sehr sehr aufwendig, manipulativ und letztlich schon politisch. Da sträubt sich jede agile Faser meines Körpers. Umständlich ist einfach das Gegenteil von agil. Es passt nicht. Natürlich ist all dies kein Problem, wenn die Teams transparent, offen und respektvoll miteinander umgehen. Davon wird schlicht ausgegangen denn schließlich sind es Scrum-Werte also auch Werte in LeSS. Dennoch gibt es diese Fälle in der Praxis und meine Meinung ist, dass es auf die folgende Art und Weise gelöst werden kann:

Nur ein einziger Scrum Master für alle LeSS Teams.

In dieser Variante, gibt es das Problem Vertrauensbruch so nicht. Der eine Scrum Master ist in allen Team Retrospectiven. Er muss sich nicht fragen, wie er ein Thema mit anderen Scrum Mastern bespricht. Er kennt es ja einfach. Auch gibt es so keine Indirektionen und damit einhergehende Probleme. Last, but not least, wird er schlicht aus organisatorischen Gründen die Team Retrospectiven nacheinander und nicht parallel abhalten können, wenn er an allen teilnehmen möchte. Dies hat natürlich einen zeitlichen Nachteil für die Teams, aber den ungeheuren Vorteil, dass dadurch auch der Product Owner zeitlich in der Lage ist an allen Team Retrospectiven teilzunehmen. Damit gibt es eine weitere Person, die quasi die Klammer über alle Teams darstellt und die Belange der Teams aus erster Hand hört. Er kann dann dazu beitragen, die Lösungen voranzubringen soweit dies möglich ist.
Ein Scrum Master für alle LeSS Teams hat auch psychologische Vorteile: Die Teams werden schneller zu noch mehr Selbständigkeit und Eigenverantwortlichkeit gebracht, denn sie wissen ja, dass ihr Scrum Master nicht nur für sie da ist. Auch wird ein einziger Scrum Master weniger ein Team Building im Sinne eines einzelnen LeSS Teams vorantreiben, sondern eher das Team Building des gesamten Produktteams im Auge haben. So entstehen erst gar keine Gräben und Abgrenzungen zwischen den Teams, wie sie sonst entstehen können, wenn die Teams sich ihren eigenen Namen geben, sich als eigenes Scrum Team fühlen, das seine eigene Dynamik und Gesetze hat, seine eigene Team Charta, seinen eigenen Raum und am Ende noch gar in einen Konkurrenzkampf zu den anderen Teams tritt. Dies belebt hier nämlich nicht das Geschäft, sondern behindert das gemeinsame Streiten für das eine gemeinsame Produkt. Gerade diese letzten Punkte sind markant, wenn ein unerfahrener LeSS-Coach die Teams gutgläubig nach klassischem Scrum ausbildet und aufstellt und die wenigen zusätzlichen LeSS-Events, wie eben z.B. die Overall Retrospective, einfach als weitere unabhängige Bausteine sieht. Obacht, Falle!

Kategorien:Agile Minds