Scrum Praxis vs. Theorie

Die Methode Scrum gehört zu den bekanntesten agilen Methoden. In der Theorie ist es einfach Scrum zu verstehen, allerdings sieht die Praxis häufig anders aus. Genau darüber sprechen wir in diesem Blogeintrag.

Scrum wurde 2001 von Ken Schwaber und Jeff Sutherland im Scrum Guide, einem 19-seitigen Dokument, beschrieben. Dieses enthält die grundlegenden Spielregeln für Scrum. Wenn du dieses Dokuments gelesen hast, weißt du alles, was dafür notwendig ist, Scrum anzuwenden. Die Methode selbst ist sehr leichtgewichtig und einfach zu verstehen. Es gibt klare Regeln, die immer eingehalten werden müssen. Scrum wirklich zu meistern und erfolgreich einzusetzen, wird viele Iterationen dauern und ist nicht ganz einfach. Das ist aber vollkommen in Ordnung, denn es braucht Zeit, um sich an die Arbeitsweise zu gewöhnen und dann die Vorteile aus der Methode zum tragen kommen.

Ich habe viele Unternehmen erlebt, die „agiler“ werden wollen und mit der Verwendung von Scrum starten. Dass die Regeln einfach zu verstehen und umzusetzen sind, ist hier allerdings eine „Falle“, da die wirkliche Agilität in den dahinterliegende Prinzipien liegt. Ich habe häufig erlebt, dass die Regeln von Scrum „perfekt“ eingehalten wurden und das Team trotzdem keine Ergebnisse produziert hat. Dieses Vorgehen bezeichne ich als „mechanisches Scrum“ und es ist der erste Unterschied zwischen Realität und Praxis.

Wenn beispielsweise ein Daily stattfindet, aber keine darüber spricht, dass er Hilfe braucht, läuft etwas schief. Das Team hat dann häufig kein tiefes Vertrauen zueinander und um Hilfe zu fragen wird als Versagen wahrgenommen. Genauso ist es mit Retrospektiven. Erst wenn das Team ehrlich und offen miteinander kommuniziert, kann Spaß und Leistung entstehen. Scrum ist eine wertvolle und sehr produktive Methode, wenn sich das Team mit den dahinterstehenden Prinzipien beschäftigt und diese anwendet. Gerade die Werte, für die das Team steht sind dabei besonders wichtig. Sie regeln die Art und Weise wie wir miteinander umgehen und wir treffen auf deren Basis Entscheidungen.

Der zweite Unterschied zwischen Praxis und Theorie ist die durchgängige Betrachtung der Wertschöpfungskette. In der Theorie sollte ein Team vollumfängliche Verantwortung für ein Produkt übernehmen können.

Im letzten Artikel haben wir über das Thema DevOps gesprochen. Gerade in der IT ist der Betrieb der Software eine elementare Tätigkeit. Sobald das Produkt oder der Service für den Kunden nicht verfügbar ist, können Image- oder Umsatzschäden resultieren. In der Realität habe ich häufig erlebt, dass Scrum für die Entwicklung (den Dev Part) verwendet wird und der Betrieb (Ops) als eigenständige Einheit / Team angesehen wird. Bei der Übergabe der fertigen Inkremente kam es immer wieder zu Problemen. Der Hintergrund sind die verschiedenen Ziele, die von Dev und Ops verfolgt werden. Während ein Entwickler (Dev) das IT System verändern möchte, sorgt der IT Betrieb (Ops) für Stabilität. Hier einen Weg zu finden, wie der Übergang von Dev zu Ops möglichst reibungslos funktioniert, ist eine der größten Herausforderungen von Unternehmen in der Softwareentwicklung. In der Theorie sollte dieser Konflikt nicht existieren, in der Praxis ist er allerdings allgegenwärtig.

Scrum in Konzernen kann nur funktionieren, wenn die gesamte Wertschöpfungskette betrachtet wird. Ein Ergebnis zu produzieren, mit dem niemand etwas anfangen kann, ist unnötig.

Ein großer Unterschied zwischen Theorie und Praxis ist die Art, wie Teams zusammengesetzt werden. Ich habe diesen einen Kollegen in meinem Team gehabt, der sich gegen alle Scrum Rituale gewehrt hat und einfach nur sein Ding machen wollte. Tatsächlich macht er einen ausgezeichneten Job bei den Aufgaben, die er zugewiesen bekommt. Allerdings ist er fürs Team wie ein schleichendes Gift, welches die Laune und Motivation nach unten zieht. In der Theorie kann das Team darüber entscheiden, wie es zusammengesetzt ist und klärt zwischenmenschliche Themen untereinander. Dazu gehört auch, dass jemand mal ein Team verlassen muss. In Konzernen und der Welt von Betriebsräten ist das allerdings fast unmöglich. Jemanden aus dem Team in ein anderes Team zu geben ist wirklich schwierig und ich bin selbst bin daran schon einmal gescheitert. Wir haben dann eine Vereinbarung innerhalb des Teams getroffen, dass dieser Kollege in seinem Arbeitsmodus weiterarbeitet und wir ihn nicht mehr als Teil des Teams betrachten. Das hört sich hart an, war allerdings die Lösung, die dazu geführt hat, dass wir wieder neue Energie gefunden und Ergebnisse produziert haben. In der Theorie ist es einfach ein hochperformantes Team zu bauen. In der Praxis ist es schwierig, weil nicht jeder im agilen Arbeiten seine Stärken ausspielen kann und du so auf Menschen triffst, für die die Arbeit nach Scrum nicht möglich ist. Wichtig ist mir, dass das vollkommen OK ist! Es gibt viele Aufgaben, für die die Anwendungen von Scrum keinen Sinn macht und jeder Mensch sollte so eingesetzt sein, dass er seine Stärken nutzen kann.

Der nächste Unterschied von Praxis zu Theorie ist die Verzahnung mit anderen Teams. In der Theorie sind Scrum Teams in sich geschlossene Einheiten, die volle Verantwortung für ihr Produkt haben. Durch die Vernetzung mit anderen in sich geschlossenen Teams entsteht dann eine starke Organisation, die flexibel und produktiv ist. In der Praxis habe ich immer wieder erlebt, dass viele Teams gemeinsam an einem Produkt arbeiten und sich kontinuierlich miteinander abstimmen müssen. Dies führt zur einer steigenden Komplexität und verlangsamt alle Teams. Wichtig dabei ist, immer wieder zu reflektieren, was das Team verlangsamt und gegebenenfalls blockiert.

Abschließen möchte ich mit einem Unterschied, der mir extrem wichtig ist. In der Theorie nutzen wir die Zeit für Retrospektiven, für kontinuierliches Lernen und für Innovationen. In der Praxis habe ich erlebt, dass Teams bis zum Anschlag mit Arbeit verplant werden und keine Zeit mit zum Lernen und Experimentieren haben. Dieses Element sollte unbedingt beachtet werden, denn wer nicht an sich, am Team oder am Know How Aufbau arbeitet, der sieht den Wald vor lauter Bäumen nicht mehr. Das wird früher oder später dazu führen, dass das Team langsamer wird und auf der Stelle tritt.

Wie sind deine Erfahrungen in der Praxis mit Scrum?

Dein Fabian

Schreibe einen Kommentar

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