E-Learning: Scrum-But

Wenn Rollen, Artefakte, Ereignisse oder Regeln von Scrum verändert oder einfach weglassen werden, dann ist das Ergebnis ein Prozess, der als Scrum But (übersetzt: »Scrum, aber«) bezeichnet wird. Der Begriff ist entstanden, weil in Unternehmen in solchen Fällen gerne Sätze fallen, wie z. B.:

• »We are using Scrum, but we do Daily Scrums only once a week.« (zu Deutsch: »Wir nutzen Scrum, aber führen Daily Scrums nur einmal in der Woche durch.«)
• »We are using Scrum, but we have two Product Owners instead of only one.« (zu Deutsch: »Wir nutzen Scrum, aber wir haben zwei verschiedene Product Owner.«)

Folgende Abweichungen von Scrum kommen in der Praxis immer wieder vor:

• Die Entwickler sind gleichzeitig noch in andere Projekte involviert.
• Der Product Owner ist kein Teammitglied.
• Der Product Owner verfügt nicht über ausreichend Produktwissen.
• Es gibt mehrere Product Owner.
• Es kommen Anforderungen während eines Sprints hinzu.

Es gibt unzählige Projektteams, die von sich behaupten, Scrum zu nutzen. Tatsächlich praktizieren aber sehr viele davon Scrum But. Kurz erklärt liegt das daran, dass in der Praxis Rahmenbedingungen für Projekte existieren, die nicht so recht zu Scrum passen. In vielen dieser Projekte wird aber dennoch sehr erfolgreich mit der Methode gearbeitet, weil das Team ganz bewusst mit den Abweichungen umgeht und diese nur dort vorsieht, wo die Essenz von Scrum nicht angetastet wird. Andere Projekte weichen in kritischen Punkten von Scrum ab und verlaufen dann weniger erfolgreich.

Vor allem im klassischen Projektumfeld ist der Einsatz von Scrum in seiner Reinform nahezu unmöglich. Die dann unausweichlichen Abweichungen sollten allerdings geplant erfolgen. Nur so kann eine Balance zwischen der Agilität, die Scrum voraussetzt, und der Planung, die das klassische Umfeld fordert, hergestellt werden. Im Folgenden betrachten wir einige kritische Abweichungen näher.

• Entwickler mit mehreren Projekten: Nach Scrum arbeiten die Entwickler ausschließlich in einem Projekt. In der Praxis ist es gang und gäbe, dass nahezu alle Mitarbeiter eines Unternehmens, und damit auch die Entwickler, in mehrere Projekte gleichzeitig involviert sind. Eine dynamische Selbstorganisation des Teams, wie Scrum sie voraussetzt, ist dadurch so gut wie nicht möglich.
• Product Owner außerhalb des Teams: Häufig liegt die Fachexpertise für das Produkt bei jemandem, der aus organisatorischen Gründen nicht in dem erforderlichen Umfang für das Entwicklungsteam abgestellt werden kann. Diese Person wird dann dennoch Product Owner und soll für das Team »möglichst gut« verfügbar und ansprechbar sein. Im Projektalltag kommt es dadurch immer wieder zu Verzögerungen, weil der Product Owner in alle möglichen anderen Arbeitsprozesse eingebunden und daher de facto nur sehr schlecht greifbar ist.
• Product Owner mit mangelndem Produktwissen: In manchen Scrum-Projekten werden Personen zu Product Ownern ernannt, die nicht über das entsprechende Wissen verfügen. Typische Gründe dafür sind z. B., dass die eigentlichen Experten, die das Wissen tatsächlich haben, in einem anderen Projekt gebunden sind, oder dass das Wissen nur bei einem externen Kunden vorhanden ist, der aber nicht als Product Owner gewonnen werden kann. Hier handelt es sich zwar nicht um einen formalen Verstoß gegen die Scrum-Regeln, jedoch um ein ernsthaftes Problem für den Praxiseinsatz von Scrum. In der Folge kommt es nämlich immer wieder zu Situationen, in denen das Team eine konkrete Nachfrage zu einem Backlog-Eintrag hat, die der Product Owner nicht korrekt oder nur mit Zeitverzug beantworten kann. Antwortet er falsch, ist dann eventuell der Kunde im Review unzufrieden mit dem Produkt oder es wird eine nutzlose Produkteigenschaft entwickelt. Kommt die Antwort erst zeitverzögert, müssen die Entwickler warten. Sie kommen, wenn sich dies häuft, insgesamt mit ihrer Arbeit langsamer voran.
• Mehrere Product Owner: In den Unternehmen gibt es oft mehrere Wissensträger, die nur gemeinschaftlich die Gesamtsicht auf die Produktanforderungen haben. Dann werden manchmal mehrere Product Owner benannt. Bei solchen Konstellationen kommt es schnell zu Unklarheiten bei Absprachen mit und zwischen den Product Ownern.
• Neue Anforderungen im Sprint: Oft mangelt es in der Organisation an Akzeptanz dafür, dass während der einzelnen Sprints keine neuen Anforderungen hinzugefügt werden dürfen. Häufig wird dann doch einfach von oben »angeordnet«, einzelne Produktanforderungen ungeplant im aktuellen Sprint umzusetzen. Es gehört in diesem Fall für den Scrum Master schon einiges dazu, sich dem erfolgreich entgegenzustellen. Kann er das nicht, weil er zu schwach ist, keine Rückendeckung in der Organisation hat oder schlicht die politische Notwendigkeit besteht, die Anforderungen schnell umzusetzen, kann das Vertrauen des Teams in die Selbstorganisation und die Verlässlichkeit der Prozesse erschüttert werden. Das führt oft zur Demotivation der Teammitglieder oder sie halten sich selbst auch nicht mehr zuverlässig an die Prozesse.
• Rollenkonflikte: Eine weitere Schwierigkeit beim Einsatz von Scrum in einem klassischen Projektumfeld entsteht durch die Einlagerung von Scrum in einen klassischen Prozess des Projektmanagements.

Der Projektleiter des Projektmanagementprozesses ist dabei dem Scrum Team übergeordnet. Formal gesehen ist das kein Verstoß gegen die Scrum-Regeln, jedoch ein ernsthaftes Problem für den Praxiseinsatz der Methode: Wenn dieser Projektleiter den Prozess und die Philosophie von Scrum nicht genau verstanden hat oder anderen Zwängen unterliegt und auf klassischen Instrumenten besteht, kommt es unweigerlich zu Schwierigkeiten. Der Scrum Master wird dadurch schnell in Konflikt mit dem Projektleiter geraten, beispielsweise wenn der Projektleiter auf zusätzlichen Meetings (z. B. wöchentliches Teammeeting) oder Dokumentationen (z. B. Pflichtenheft) besteht, die Scrum nicht vorsieht. Der Scrum Master hat die Pflicht, das Team vor solchen zusätzlichen Aufgaben zu schützen. Überall dort, wo der Scrum Master sich nicht durchsetzen kann, wird das Team schnell unzufrieden werden. Schließlich kann es bei zusätzlichen Aufgaben seine Sprint-Planung nur mit Mehrarbeit oder im schlimmsten Fall gar nicht mehr einhalten. Das Problem ist nicht einfach dadurch zu lösen, dass der Projektmanager gleichzeitig die Rolle des Scrum Masters oder Product Owners einnimmt. Denn damit wird der Rollenkonflikt nur auf eine Person verlagert. Lösen kann man es nur, wenn die Rollen und Verantwortlichkeiten explizit festgelegt werden.

Hinter diesen Schwierigkeiten steht oft ein noch viel größeres Problem: nämlich, dass Scrum nicht in der gesamten Organisation verstanden und akzeptiert wird. Dies ist gerade in großen Unternehmen häufig der Fall. Daher sollte die Einführung der Scrum-Methode von einem Organisationsentwicklungsprozess begleitet werden, der die notwendige Motivation schafft und das erforderliche Wissen über Scrum verbreitet.