Niko Zimmermann

 

Machen wir mit Scrum weiter?
Brauchen wir Scrum noch? Oder Scrum 2.0 oder etwas anderes?
Star

17. April 2025

Als Wirtschaftsingenieur mit dem Schwerpunkt Logistik konnte ich auch schon damals, 1997, meine Kunden, meistens vor Ort, in ihrer Problemstellung abholen.
Im engen Kontakt und in Absprache mit den Menschen vor Ort konnte ich in der Rolle "Customizer" die Anforderungen klären und gleich die Anpassungen für das vorhandene, datenbankgestützte ERP-System entwickeln. Diese Rolle Customizer fasst quasi den Business Analysten, Product Owner und Entwickler in einer Rolle zusammen. Das Ergebnis wurde noch während dieses Vor Ort-Einsatzes vom Kunden getestet und entweder für gut befunden oder eben nochmal angepasst.
Am Abend der Abreise war das System beim Kunden dann bereits produktiv!
Das ging bei mir viele Jahre so, weil ich als One-Man-Show gerne bei den Kunden unterwegs war. Ich kannte als Entwickler von meinem vorherigen Arbeitgeber, Hersteller des ERP-Systems, die technische Infrastruktur des Kundensystems ausreichend genug, um vor Ort Anpassungen vorzunehmen oder kleine Neuentwicklungen zu programmieren.
Damit konnte ich mich schon damals 1997 selbständig machen.
Diese Vor Ort-Einsätze waren natürlich keine technisch ausgereiften, nachhaltigen Lösungen, aber das brauchten sie auch nicht sein. Mit meiner "Bordmittel"-Entwicklung vor Ort was das genau das, was der Kunde in seiner aktuellen Situation benötigte. Es half ihm sofort weiter.
Kommt Ihnen das, bezogen auf unsere heutige, agile SCRUM Welt irgendwie bekannt vor?
Anhand der kurzen Anekdote könnten wir heutige Buzzwords wie MVP (Minimal Viable Product), Feedback-getriebene Entwicklung, BizDevOps, kurze Iterationen (Sprints) usw. durchaus wiederfinden. Diese agile Denke war mir bereits damals in Fleisch und Blut übergegangen. Noch lange bevor ich mit Scrum und der agilen Bewegung in Berührung kam.
Als ich dann erstmalig in 2014 von Scrum und dem agilen Manifest hörte, hab ich mich auch gleich zertifizieren lassen. Ein Jahr später fing ich dann an, in meiner neuen Rolle Scrum Master zu arbeiten.
Die neue Rolle und die SCRUM Methode führten dazu, dass ich auch neue Kunden kennenlernte. Damals war das mit den Schlagworten Agil und Scrum noch relativ neu. Die Kunden empfingen mich Anfangs mit einer gewissen Neugier. Auf der einen Seite war das für mich sehr schön, meine Auftragslage gut, aber auf der anderen Seite erstaunte es mich auch ein wenig, denn als "Customizer" war ich ja die Kundenorientierung damals schon seit 20 Jahren gewohnt.
Und wie sieht es heute aus?
Ich selber durfte die letzten 10 Jahre bereits für mehr als ein Dutzend verschiedene Kunden, in mehrmonatigen, agilen Projekten als Scrum Master und Agiler Consultant arbeiten. Heutzutage bin ich oft nicht der einzige und auch nicht der erste Scrum Master im Kundenprojekt.
Agil, Scrum und Kanban sind für die meisten meiner Kunden heute nichts neues mehr.
Agil, Scrum und Kanban sind im Mainstream angekommen.
Und hier gibt es leider ein Problem. Weil es bei einigen Kunden nicht zu einer Verbesserung führte.
Ich nenne das an dieser Stelle mal "Agiles Theater". Was meine ich damit?
Im Agilen Theater liefert Scrum als Methode eine gute Vorstellung im Unternehmen ab. Aber ohne die Kundenrealität richtig abzubilden! Ohne einen wirklichen Vorteil für das Unternehmen zu bieten.
Alle im Unternehmen wissen von dem neuen Scrum-Projekt, ganze Abteilungen von Mitarbeitern werden in den Scrum-Rollen ausgebildet und zertifiziert. Scrum als Methode kann korrekt implementiert und durchgeführt werden, und trotzdem keinen nennenswerten positiven Einfluss auf die wirklichen Unternehmensziele haben.
Viele fragen sich daher, brauchen wir Scrum? Was hat es uns gebracht? Oder brauchen wir ein neues Scrum 2.0? Oder ganz was anderes? Oder wieder das alte, wieder zurück zum klassischen Projektmanagement und Wasserfall?
Liegt es überhaupt an Scrum? Mir persönlich gefällt Scrum, weil es mir hilft sehr schnell zu erkennen, was der Kunde als nächstes benötigt. Quasi als eine Schablone bringt das Scrum Framework für mich selber Transparenz in die Situation. Es hilft mir ungemein bei der Beurteilung meines neuen Kunden-Projektes.
Welchen Wert liefert unser Produkt? Nicht die Scrum Methode als solche, sondern das Produkt für den Endkunden?
Hier komme ich zum Abschluss gerne nochmal auf meine eingangs erzählte Anekdote über die Kundenorientierung zurück.
  • Holen wir unsere Kunden (auch interne Kunden) in ihrer Problemstellung ab?
  • Sind wir im engen Kontakt und in Absprache mit den Menschen vor Ort?
  • Können wir, statt ausführlicher Lösungen schon mal etwas Kleines zeigen, im Sinne eines MVP?
  • Können wir anhand dieser ersten Durchstiche Feedback bekommen und Anpassungen im nächsten Sprint vornehmen?
  • Arbeiten Business Analysten, Product Owner und Entwickler mit dem Kunden zusammen?
  • Kann jeder Sprint ein Deployment erzeugen und der Kunde etwas testen? Entweder für gut befinden oder eben nochmal kritisch würdigen, damit es angepasst wird?
Wenn Sie diese Fragen alle mit Ja beantworten können, warum sollten Sie dann nicht mit Scrum weitermachen? Scrum On!