Es gibt keine Blaupause

In einer Diskussion vor einigen Monaten bei der Manage Agile vertrat mein Gesprächspartner eine These, die ich nicht vertreten wollte: Scrum funktioniere nicht. Als agile Coach und Teamleiter der Scrum Master in meinem Unternehmen konnte ich förmlich nicht anders, als Scrum zu verteidigen. Und dann stellte er eine Frage, die mich nachdenklich gemacht hat.

Hast du schon mal ein Team erlebt, das Scrum erfolgreich eingesetzt hat?

Der erste Gedanke war: Klar habe ich das und nicht nur das, mein Scrum Master Team und ich selbst haben aktiv dafür gesorgt, dass Scrum erfolgreich eingesetzt wurde. Aber stimmt das wirklich?

Vor noch viel mehr Monaten hat Ken Schwaber mal gesagt: Wenn du Scrum nicht richtig machst, dann nenn es auch nicht Scrum. Und er ergänzte, dass Teile von Scrum zu machen besser sei, als sie nicht zu machen – aber es sei dann kein Scrum. Wenn also Scrum nur Scrum ist, wenn es wie im Lehrbuch formuliert angewendet wird, machen wir dann wirklich Scrum? Oder habe ich schon mal ein Team erlebt, das wirklich Scrum (in seiner Reinform) gemacht hat?

Scrum in Reinform

Mittlerweile muss ich sagen: Nein, ich habe selbst noch kein Team erlebt und jedes Team hatte andere Schwierigkeiten. Hier ein paar beispielhafte Passagen aus dem Scrum Guide, mit denen mir bekannte Teams zum Teil immer wieder Schwierigkeiten hatten.

  •  „Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Entwicklungsteam abhängig zu sein.“
  • „Die inkrementelle Auslieferung von „fertigem“ [Done] Produkt sorgt dafür, dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht.“
  • „Der Product Owner ist eine einzelne Person, kein Komitee.“
  • „Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten.“
  • „Nur Mitglieder der Entwicklungsteams erstellen das Produkt-Inkrement.“
  • „Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem Entwicklungsteam, wie es aus dem Product Backlog potentiell auslieferbare Funktionalität machen soll.“
  • „Entwicklungsteams sind interdisziplinär tätig. Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Produkt-Inkrement zu erstellen.“
  • „Scrum kennt keine Titel außer „Entwickler“ für Mitglieder des Entwicklungsteams. Dies ist unabhängig von der Arbeit, die diese Personen erledigen. Es gibt keine Ausnahmen von dieser Regel.“

Wenn es also offensichtlich schwer fällt, unter nicht idealen Rahmenbedingungen Scrum in Reinform zu machen, ist dann Scrum die richtige Wahl für Software-Entwicklung? Kritiker sagen nein, Befürworter sagen ja und ich sage als Befürworter Ja und Nein.

Ja und nein

In der ersten Phase der Einführung beschäftigt sich das Team meistens mit sich selbst in einem eng gesteckten Rahmen mit häufig hohem Handlungsspielraum. Die eigentliche Herausforderung bei der Durchführung von Scrum sind gewisse Rahmenbedingungen, die erfüllt sein müssen, dass man Scrum wirklich in Reinform ein- und durchführen kann. Bestimmte Organisationsstrukturen und eine moderne und mitarbeiterorientierte Unternehmenskultur gehören dazu und befinden sich außerhalb des Handlungsrahmens eines Scrum Teams. Wenn aber Teams gar nicht den nötigen Einfluss auf die Rahmenbedingungen haben, um nach Scrum „by the book“ zu arbeiten, warum ist dann Scrum vielleicht dich die richtige Wahl?

Scrum ist nur ein Mittel zum Zweck. Es ist ein Rahmenwerk, um schlank und gut organisiert mit klaren Verantwortlichkeiten kundennah und schnell Software in hoher Qualität zu entwickeln. Scrum deckt gleichzeitig durch das iterative Vorgehen und den eingebauten kontinuierlichen Verbesserungsprozess Unstimmigkeiten im System auf und stößt damit einen Veränderungsprozess an.

Die Einführung von Scrum „by the book“ hat den großen Vorteil, dass es als schlanke Blaupause dabei hilft, neue Strukturen, neue Arten zu Arbeiten und neue Verantwortlichkeiten zu lernen. Alle „Mitspieler“ verstehen schnell, wie das „Spiel“ funktionieren soll und arbeiten kontinuierlich daran, sich zu verbessern mit einem klar umrissenen Prozess-Ziel.

Gleichzeitig aber sind die Rahmenbedingungen in Unternehmen immer unterschiedlich, sehr individuell durch Strukturen und auch durch die Mitarbeiter des Unternehmens. Und gerade die Individualität sorgt dafür, dass eine Blaupause sich zwar aus Management-Sicht gut verstehen und „auf dem Papier“ einführen lässt, sich aber um so schwerer umsetzen lässt, weil eine Veränderung verlangt wird, die vielleicht nicht im Interesse aller Betroffenen ist.

Der eigentliche Vorteil

Das Rahmenwerk Scrum bietet viele Antworten auf Herausforderungen bei moderner Wissensarbeit oder bietet einen klaren Verantwortungsrahmen, in dem man selbst individuell passende Antworten zu finden. Scrum berücksichtigt bzw. fordert eine neue Sichtweise weg vom Taylorismus auf Arbeit, auf Motivation, auf Mitarbeiter und bietet schnelle erste Antworten und gute Ideen, wie sich Arbeit anders organisieren lässt. Die Arbeit nach Scrum ist ein großes Ziel, das man anstreben kann und mit diesem Bestreben wird man sich sehr wahrscheinlich verbessern hin zu einer neuen Art der Arbeitsorganisation. Aber auch hier halte ich mittlerweile den Weg für das Ziel.

Scrum ist also eine richtige Wahl, wenn es darum geht, einen Veränderungsprozess „bottom up“ anzustoßen und zu begleiten. Veränderungsprozesse brauchen aber individuelle Lösungen, die auf Organisations-Ebene, aber vielleicht auch in den Entwicklungsteams gefunden werden müssen. Die Scrum-Regeln sind dabei leichtgewichtig, aber manchmal dennoch nicht passend.

Das bedeutet auch, dass die Einführung von Scrum dabei helfen kann, Wissensarbeit besser zu organisieren. Diese Hilfe ist der eigentliche Wert und aus meiner Sicht wichtiger, als die Durchführung von Scrum „by the book“. Ich habe es bisher so erlebt, dass die Einführung von Scrum einen langen Lernprozess bei allen Beteiligten angestoßen hat und dieser Anstoß und die Unterstützung beim Lernen sind die eigentlichen Vorteile von Scrum. Ich kenne kein Team, das Scrum „by the book“ erfolgreich durchgeführt hat. Ich habe aber einige Teams erlebt, die sich durch die Einführung von Scrum und das Bestreben, Scrum „richtig“ zu machen, agile Werte und Prinzipien verinnerlicht haben. Das hat ihnen dabei geholfen, ihre Arbeitsweise und -ergebnisse kontinuierlich zu verbessern.

Richtig begleitet und konsequent verfolgt halte ich die Einführung von Scrum, das Lernen, den Regeln von Scrum immer mehr zu folgen und sich in dem durch Scrum gesetzten Rahmen eine optimale Arbeitsumgebung zu schaffen für den entscheidenden Mehrwert.

Es gibt keine Blaupause für eine ideale Arbeitsorganisation. Betrachtet man Scrum aber als Werkzeug für eine Veränderung und kontinuierliche Verbesserung und begleitet man die Ein- und Durchführung von erfahrenen Mitarbeitern mit einem entsprechenden Menschenbild und Blick auf moderne Wissensarbeit, dann gewinnt man viel durch die Einführung von Scrum, auch wenn man es nicht alle Regeln komplett befolgt.

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Achtung: Ich erkläre mich damit einverstanden, dass alle eingegebenen Daten und meine IP-Adresse nur zum Zweck der Spamvermeidung durch das Programm Akismet in den USA überprüft und gespeichert werden.
Weitere Informationen zu Akismet und Widerrufsmöglichkeiten.