7 Gründe für SCRUM

Was der Bauer nicht kennt, frisst er nicht – dies gilt leider viel zu oft auch in Unternehmen. Neue Ansätze und Ideen werden gerade in alteingesessenen Unternehmen häufig als neumodischer Schnickschnack abgetan und bekommen erst gar nicht eine realistische Chance, sich zu bewähren. Wer in einem Unternehmen SCRUM neu einführt wird sich oft gegen interne Widerstände behaupten müssen. Eine vernünftige Kommunikation der Vorteile kann helfen, Widerständen zu überwinden.

1. Agilität
   • Dieser Begriff wird meist mit SCRUM in Verbindung gebracht. Die fortwährende Einflussnahme und Steuerungsmöglichkeit der Stakeholder während des gesamten Entwicklungsprozesses ist ein Argument, was bei vielen die ersten Widerstände bröckeln lässt. Gerade dieses Argument sollte hervorgehoben und untermauert werden.
2. Kommunikation
   • Die zahlreichen SCRUM Meetings sind gerade zu Beginn ungewohnt. In vielen Projektteams gab es vor SCRUM meist weniger Serientermine und nun sollen zahlreiche neue Termine, die Arbeitszeiten kosten, hinzukommen/ bisherige ersetzen. Bei diesem Argument werden fast immer „ad-hoc“ Abstimmungsmeetings und erhöhte Iterationsschleifen unterschlagen. Die genaue Abstimmung, des Leistungsumfangs, die Definition der Arbeitspakete insbesondere im Refinement– und Planungsmeeting reduzieren erheblich die sonstigen Abstimmungsbedarfe zwischen den Teammitgliedern und vermeiden, dass Umsetzungen nicht den Anforderungen entsprechen und nachträglich erneut geändert werden müssen.
3. Emanzipation
   • Damit SCRUM erfolgreich funktioniert bedarf es die richtigen Leute für die richtigen Rollen. Dies ist aber kein SCRUM-Phänomen, sondern trifft wohl in der gesamten Arbeitswelt zu. Ein funktionierendes SCRUM Team wird stolz sein, Eigendynamiken entwickeln, selbstbewusst auftreten, Ideen und Innovationen hervorbringen und sich selbst organisieren. Sie können hiervon nur profitieren, wenn der Freiraum gemäß SCRUM dem Team gegeben wird.
4. Time-to-Market
   • Konzeption, Design, Umsetzung, Testing, Deployment – je nach Projektgröße können hier schon mal mehrere Wochen oder Monate ins Land ziehen, bevor der Kunde (respektive Stakeholder) sein Produkt zu sehen bekommt. Machen Sie SCRUM-Zweiflern klar, dass gerade hier ein großer Benefit enthalten sind. In kurzen Zyklen werden live fähige Produktbestandteile (Increments) vorgestellt. Der Stakeholder kann jederzeit nun die Anforderungen überprüfen und gegebenenfalls den Kurs anpassen. Zudem kann der Stakeholder pro Sprint entscheiden, ob das Produkt den Reifegrad erhalten hat, live bereitgestellt zu werden.
5. Opportunitätskosten
   • Gerade in Kunden-Dienstleister Beziehungen kann dies ein offensichtliches Argument sein. Insofern das SCRUM Team des Dienstleisters nach SCRUM organisiert ist, ist eine genaue Schätzung, die Angebotserstellung, -prüfung, -freigabe etc. nicht erforderlich. Es wird ein SCRUM-Team „verkauft“ für einen definierten Zeitraum mit einer definierten Anzahl an Personen. Langwierige Diskussionen über den genauen Leistungsumfang, ob eine Aufgabe nicht doch irgendwie schneller durchgeführt werden könnte etc. entfallen. Aber gerade bei neuen Kunden/ Dienstleisterverhältnissen ist sicherlich zu Beginn nicht das erforderliche Vertrauensverhältnis gegeben, dass der Kunde keine genau abgesteckten Leistungen einkauft.
6. Qualität
   • Das Projekte erst am Ende getestet und abgenommen werden können, ist aus meiner Sicht ein Hauptkritikpunkt am klassischen Wasserfallmodell. Das Testing mag vielleicht in einen überschaubaren Zeitraum umsetzbar sein, aber meist wird dabei vergessen, dass beim Testing Fehler aufgedeckt werden und diese noch behoben werden müssen. Dieses Testing wird bei SCRUM kontinuierlich während des gesamten Entwicklungsprozesses als fester Kernbestandteil aufgenommen. Denn am Sprintende werden nur erfolgreich getestete Features dem Kunden vorgestellt (Review-Meeting) sodass fortwährend die Produktqualität gewährleistet ist.
7. Identifikation
   • Die Identifikation der einzelnen Teammitglieder und damit auch die Arbeitsbereitschaft für ein Produkt steigt erheblich mit den Freiheitsgraden und auch den Einflussmöglichkeiten. Knallhart vorgegebene Aufgaben werden womöglich auch sauber umgesetzt, dennoch fühlt sich der Mitarbeiter hier wohl eher als Maschine. Ist hingegen dem Team die genaue Product Vision klar und entscheidet auch selbst, welche Aufgabenmenge in einem Sprint umgesetzt werden kann, steigt die Identifikation für das Projekt unweigerlich.  Geben Sie dem Team das nötige Vertrauen, erst dann ist eine freie Entfaltung möglich

Erfahrungsgemäß bedeutet die Einführung von SCRUM viel Überzeugungsarbeit. Ist diese Hürde erstmal geschafft und der SCRUM Prozess kann beginnen, wird die Welt auch nicht neu erfunden werden. Es werden sich mit der Zeit Verbesserungen einstellen, einiges wird zu Beginn sicherlich auch schieflaufen aber dies liegt in der Natur der Sache, wenn neue Methoden eingeführt werden. Insgesamt wird ein SCRUM Team erst nach 5-7 Sprints sich eingefunden und eingespielt haben. Je nach Sprintlänge kann dies in Summe dann schon mal 3-4 Monate bedeuten. Es kann durchaus auch Sinn ergeben, zunächst in einer Abteilung SCRUM zu etablieren, ohne die Einführung an die große Glocke zu hängen. Sammeln Sie zunächst in dem Team Erfahrung, testen und probieren Sie mit dem Team die für sie beste Vorgehensweise aus. Trittbrettfahrer (im positiven Sinne) werden schneller an die Tür klopfen als Sie denken, wenn Sie von dem Erfolg der Implementierung erfahren haben.