Wer kennt sie nicht: Scrum Team Probleme! Egal wer sich mit dem agilen Framework Scrum befasst, hatte schon mal mit Herausforderungen im Scrum Team zu kämpfen. In diesem Artikel beleuchte ich mit dir eine (nicht abschließende) Anzahl an Problemen, die in deinem Scrum Team auftreten können. Nutze die Reflexion und vermeide Fehler.
Typische Scrum Team Probleme
Die folgende Übersicht über Probleme in Scrum Teams ist nicht abschließend und eine Übersicht von dessen, was ich erlebt habe. Lasse dich von den Herausforderungen einfach inspirieren.
Kein gemeinsames Ziel im Team haben
Starten wir direkt mit einem totalen Klassiker. Ein Scrum Team hat kein gemeinsames Ziel. “Wir arbeiten zusammen” ist nie ein Ziel, sondern ein Scrum Team hat immer ein geteiltes Ziel und strebt dieses gemeinschaftlich zu erreichen an. Wenn du kein gemeinsames Ziel hast, funktionieren auch Events wie der Sprint mit dem Sprint Ziel nicht richtig und auch ein Product Backlog mit einem Produkt Ziel werden dann nicht die Wirkung erzeugen, die ihr im Scrum Team benötigt. Den Begriff des Ziels kannst du in Scrum auf mehreren Ebenen sehen, allerdings mangelt es oft schon an dem grundsätzlichen Verständnis eines Ziels.
Glauben, dass Splitterkapazität hilfreich ist
Auch sehr beliebt auf der Skala von Problemen bei Scrum ist es, mit der sogenannten Splitterkapazität zu arbeiten. Sprich, die Claudia arbeitet zu 20% im Team mit, macht 80% was anderes und alle anderen Teammitglieder haben ähnliche Konstellationen. Das führt unweigerlich dazu, dass bei gemeinsamen Aufgaben für eurer Ziel niemand unmittelbar Zeit hat, Abstimmungen erfolgen müssen und das ganze Produkt auch nur langsam entwickelt wird und damit holt ihr euch schnell Nachteile aus dem klassischen Projektmanagement in die Agilität wie Ressourcenplanung und ähnlichem mehr.
Keine cross-funktionalität leben
Eine Crossfunktionalität oder Interdisziplinarität im Scrum Team ist essentiell und zielt darauf auf, gemeinschaftlich an einem Ziel auch arbeiten zu können, weil wir eben alle Skills in einem Team haben, die wir auch brauchen, um unser Ziel zu erreichen und um unser Produkt auch entwickeln zu können.
Silos zu bilden oder einfach die bestehenden Menschen so zu lassen wie sie sind und einfach denen den Begriff des „Team“ umzuhängen, funktioniert natürlich auch hier nicht. Oft wird dabei klar, wie schlecht es eigentlich um das Team steht, da nämlich überhaupt nicht die richtigen Skills in der Organisation für das Team existieren.
Denken, dass Projekt und Produkt als Synonym verwendet werden kann!
Leider immer immer wieder gerne gemacht und nie wirklich hinterfragt: Agiles Projektmanagement im Sinne von Scrum lässt vermuten, dass wir Projekte machen, aber das tun wir nicht. Und Projekte sind nun etwas anderes als Produkte. Projekte sind nicht schlecht per se, nur sie passen eben nicht zu einem agilen Team, das Scrum machen möchte. Das Scrum Framework ist für komplexe Produkte und Fragestellungen konzipiert. Und eben nicht für ein Projekt. Elementare Pfeiler der Agilität, also zum Beispiel die Möglichkeit schnell und flink reagieren zu können, kann so mit einigen unüberlegten Aktionen schnell zu Nichte gemacht werden.
Unterschiedliche Chefs mit unterschiedlichen Interessen für Teammitglieder
Ebenso nicht selten gesehen ist der Gedanke ein Team aus unterschiedlichen Menschen zu erstellen, die alle oder teilweise unterschiedliche Chefs haben, die mit unterschiedlichen Interessen hinsichtlich der Teammitglieder agieren. Solange sich Chefs nicht in das Produkt einmischen und keine inhaltlichen Interessen haben, mag das noch funktionieren, oft sind aber an die Rolle des Chefs in Unternehmen unterschiedliche Erwartungen hinsichtlich des Inhalts und der Mitbestimmung geknüpft, die meistens konträr zu dem stehen, was Mitglieder im Team leisten und verantworten sollen.
Kapazitative und wertorientierte Planung verwechseln!
Bei einem Scrum Team geht es nach Wert. Es geht nicht um Kapazität. Das ist wohl das, was man am häufigsten sieht, gerade wenn viele für die Agilität notwendige technische Grundlagen im Team gar nicht existieren. Am Ende eines Sprints wollen wir einen möglichst großen Wert in einem Inkrement erzeugt haben. Wir wollen nicht alle Mitarbeiter auslasten und irgendwas aus dem Backlog abarbeiten, was gerade nicht wichtig ist. Das ist ganz entscheidend und ein oft großes Shift im Mindset, wenn dein Scrum Team vorher klassisch entwickelt hat. Und je weniger cross-funktional dein Team ist, desto mehr tendieren Teams aus meiner Sicht immer zu kapazitativer Planung.
Push statt Pull praktizieren
Ein Backlog ist keine Liste, die ein Projektleiter nutzt, um Arbeit an unterschiedliche Personen zu verteilen. Es ist eine Liste, die der Product Owner für das Produkt sortiert, damit es möglichst gut die Wünsche der Kunden trifft. Während der Product Owner diese Reihenfolge vorgibt, ist es an den Entwicklern zu sagen, was sie schaffen können. Sie ziehen sich also die Arbeit selbst, was wir pull nennen, niemand schiebt die Arbeit zu ihnen rein, was einem push gleichzusetzen wäre.
Einfach Rollen auf bestehende Menschen verteilen
Wer ein Projektleiter war, kann nicht einfach den Product Owner machen. Ich kann die Rolle des Scrum Masters nicht einfach irgendwem geben. Das geht schief und hat auch noch nie geklappt. Ein Wechsel zu Scrum kann vieles offenbaren und meistens kommt zu Tage, dass wir gar nicht alle benötigten Menschen und Skills an Board haben. Dann einfach die Rollen auf die Menschen zu verteilen, weil sie ja vergeben werden müssen, endet oft – wie die anderen Probleme auch – im Desaster.
Collaboration und Cooperation verwechseln
Eine wirkliche Zusammenarbeit ist eine Collaboration. Eine Cooperation oder Kooperation beschreibt nur das Zusammenspiel mehrerer Personen, die oft eigene Ziele haben und auf Teilaspekte hinarbeiten. Und genau das wollen wir in Scrum auch nicht. Wir haben den Fokus auf ein Produkt, welches wir gemeinsam entwickeln wollen.
Statisch und stabiles Team verwechseln
Wenn du ein Team für Scrum hast, dann kommt es darauf an, dass dieses stabil ist. Der Begriff wird manchmal falsch interpretiert. Er bedeutet nicht statisch! Stabil ist ein Team, wenn der Eingang und Ausgang, wenn die Velocity, wenn der Zweck und ähnliches mehr gleich bleibt und erreicht werden kann. Statisch ist ein Team, wenn du keinerlei Änderung an diesem zulässt. Menschen ändern sich und gehen, neue Techniken halten Einzug und Ziele müssen justiert werden. All das kann in einem stabilen Team erfolgen, in einem statischen nicht (Vgl. Statisches oder stabiles Team)
FAZIT: Scrum Team Probleme
Viele der hier vorgestellten Probleme sind sehr real und verhindern gut ausgerichtete Scrum Teams. Teams oder Organisationen, die Scrum nicht vollumfänglich umsetzen, mögen die Probleme nicht so wichtig erscheinen. Möchtest du Scrum aber sehr nahe kommen, dann wirst du an diesen Problemen je nach Organisation vorbei kommen.
Nutze die Herausforderungen für dein Coaching
Als Scrum Master oder Coach kannst du mit dem Wissen dieser möglichen Probleme natürlich auch gute Fragestellungen für dich und dein Team ableiten. Versuche dabei eine Haltung einzunehmen, in der du dich fragend an die Herausforderungen annäherst, sie aber dem Team nicht nennst, um eine Beeinflussung des Systems weitestgehend zu vermeiden.
