ScrumBut und ScrumAnd

Bild: Flickr / David Molloy - CC BY 2.0

So schlicht Scrum auch ist, so viel kann man bei seiner Umsetzung falsch machen. Das meiste davon dürfte unbewusst passieren und den Handelnden gar nicht bewusst sein, also in die Kategorie fallen für die sich der schöne Name Cargo Cult eingebürgert hat. Es gibt aber auch Fälle in denen absichtlich am Vorgehen herumgedoktort wurde. Auch für die beiden hierbei möglichen Varianten gibt es mittlerweile Bezeichnungen: ScrumBut und ScrumAnd.

ScrumBut ist abgeleitet von der Aussage "We do Scrum, but ...", also "Wir machen zwar Scrum, aber ...". Hinter diesem "aber" verbergen sich dann die Einschränkungen denen das Vorgehen unterworfen wurde. "Wir machen zwar Scrum, aber nur auf Teamebene.", "Wir machen zwar Scrum, aber ohne Scrum Master." oder "Wir machen zwar Scrum, aber nur für die IT." sind klassische ScrumBut-Aussagen, wie man sie überall dort wiederfinden kann wo vor einer wirklichen Einführung zurückgeschreckt wurde.

Das irritierende an dieser Variante - selbst bei offensichtlich eingeschränktem Umfang bleiben die an Scrum gerichteten Ansprüche meistens unverändert hoch. Dass auch diese proportional zum Rückbau der Methode sinken müssten wird selten eingesehen, und selbst wenn es erkannt wird kann eine überzogene Erwartungshaltung dazu führen, dass eine ernsthafte Organisationsveränderung blockiert wird. "Das soll erstmal auf Teamebene für Verbesserung sorgen bevor wir es woanders einführen" entspricht etwa der Aussage "Die Glühbirne soll erstmal zeigen, dass sie Licht machen kann, bevor sie Strom bekommt." Kann man so sehen, bringt einen aber nicht weiter.

ScrumAnd geht dagegen ist die genau andere Richtung: Scrum wird zwar wie vorgesehen eingeführt (zumindest weitgehend), gleichzeitig aber mit zusätzlichen Inhalten überfrachtet. Ein Beispiel dafür wäre ein Geschäftsführer, der zusätzlich die Rolle eines Product Owners übernimmt (und aus Zeitmangel fast alle damit verbundenen Tätigkeiten ins Team delegiert). Ein anderes Beispiel wäre die Integration so vieler Randaspekte in die Produktentwicklung (Werbekampagnen, First Level Support, etc.), dass das Team kaum noch focussiert arbeiten kann.

Rein formal lässt sich gegen diese Auslegung in vielen Fällen nichts sagen, der Scrum Guide erwähnt zwar nichts Derartiges, untersagt es aber auch nicht. In der Realität führt eine solche Überladung erfahrungsgemäss aber fast immer zu Reibungsverlusten, Zielkonflikten und Motivationsrückgang. Gleichzeitig kann es auch im Fall von ScrumAnd zu unrealistischen Erwartungshaltungen kommen. "Aber in den Regeln steht doch, dass der PO delegieren darf und dass dass Team crossfunktional sein muss." wäre eine klassische Begründung dafür, auch in solchen Konstellationen reibungslose Performance zu erwarten.

Sowohl bei ScrumAnd als auch im Fall von ScrumBut sind die Erwartungshaltungen auch der Punkt an dem angesetzt werden sollte um an Verbesserungen zu arbeiten. Dass stark beschnittene oder überfrachtete Vorgehensweisen ihre positiven Effekte nicht voll entfalten können wird fast jeder nachvollziehen können, wer an diesen Effekten interessiert ist wird daher erkennen, dass er ein Zurückfahren der Missstände zumindest erwägen muss. Und wer von den alten Strukturen und breiten Aufgabenspektren nicht ablassen kann (wofür es gute Gründe geben kann) dem kann man vermitteln, dass Scrum seinen Ansprüchen nicht genügen wird und er einen anderen Ansatz ausprobieren sollte.

Dass auch ein anderer Ansatz mit hoher Wahrscheinlichkeit an diesen Ansprüchen scheitern dürfte steht dann auf einem anderen Blatt, hat aber mit den beiden hier beschriebenen Scrum-Antipattern nichts mehr zu tun.