Agile beyond Scrum

Im Bereich Softwareentwicklung kommen häufig Modelle des agilen Projektmanagements wie Scrum oder Kanban zum Einsatz. In diesem Blogartikel geht es darum, wie sich das Verständnis und der Einsatz solcher Modelle, insbesondere Scrum, im Laufe der Zeit gewandelt entwickelt haben.

Seit 20 Jahren gibt es das Agile Manifest. Dieses hat die Softwareentwicklung stark geprägt. Auch wenn in diesem Grundsatzpapier agiler Prinzipien zunächst von Scrum als Vorgehensmodell nicht die Rede ist, setzte es sich spätestens bis 2006 gegenüber anderen Frameworks durch und entwickelte sich durch den wiederholt aktualisierten Scrum Guide weiter.

Der Erfolg dieser Vorgehensweise beruht im Wesentlichen darauf, dass sie leicht zu verstehen und gleichzeitig einfach überschaubar ist. Nach einiger Zeit kamen den Unterzeichner:innen des Agilen Manifests jedochZweifel, ob die Weiterentwicklung noch den selbst auferlegten Prinzipien entspricht. Immer häufiger wurde im öffentlichen Diskurs die Kritik laut, Scrum und seine verwandten Modelle wären überdekoriert und überorganisiert.

Organisierte Über-Organisation

Die Grundlagen und Vorläufer von Scrum reichen bis in die japanische Industrielandschaft der 1950er-Jahre zurück. Erst zum Ende der 1990er-Jahre wurde das Prinzip als theoretisches Modell aufbereitet. Im Fahrwasser des Agilen Manifests wurde die strukturell schlanke Handlungsempfehlung zur Bedienungsanleitung für agile Prozessgebilde in der Softwareentwicklung erstellt. Durch die stark ausgeweiteten medialen Möglichkeiten bekam Scrum viel Aufmerksamkeit. Gleichzeitig witterten Beratungsgrößen weltweit die Chance, immer komplexere Verfahrensmodelle auf der Grundlage des einst leichtgewichtigen Frameworks zu konstruieren. Eine Rolle spielte dabei das Bedürfnis nach Skalierung – insbesondere in sehr großen Unternehmen. Hierbei wurden immer komplexere Gebilde entworfen, die sich vom leichtgewichtigen Vorbild entfernten. Selbst der ScrumGuide enthielt immer mehr und strengere Regeln. Die Anwender:innen spürten statt der versprochenen Handlungsräume und Eigenverantwortung vermehrt Kontrollmechanismen. Gleichzeitig ersetzen oftmals vorab geplante Mustern die iterative Herangehensweise. Als Folge stiegen die Aufwände, während der Output stagnierte oder sank.

Katharsis

Wenn Modelle sich durch falsches Verständnis oder individuelle Interessen verkomplizieren und an Attraktivität verlieren, erscheint es zunächst logisch, dies genauer erklären zu wollen. Die Autoren des Scrum Guides, Ken Schwaber und Jeff Sutherland, hatten Scrum schon seit 1993 formalisiert und die Rollen entsprechend in Softwareentwicklungsteams definiert. Das eigentliche Handbuch erschien jedoch erst 2010. Beide wollten dieses kurze Grundlagenwerk als Empfehlung verstanden wissen. Die zunehmend mit der Digitalisierung überforderten Organisationen klammerten sich jedoch buchstäblich an das „Regelwerk“. Aber wie sollte man etwas einfaches noch einfacher machen? Und war das überhaupt richtig? Die Autoren entschieden sich bei der Überarbeitung zunächst für mehr formalisierte Beschreibungen, befeuerten damit aber unbeabsichtigt eine strengere Formatierung von Scrum.

Innerhalb weniger Jahre bekamen einige Unterzeichner:innen des Agilen Manifests das ungute Gefühl, dass sich das einst schlanke Konstrukt Scrum in der Praxis vom agilen Grundgedanken entfernt hatte. Als Alternativentwürfe entstanden Konzepte wie Modern Agile oder Heart of Agile. Diese wurden radikal verschlankt, sodass nur noch die wichtigsten Kernfragen agilen Handelns eine Rolle spielen sollten:

• Wie arbeiten wir zusammen?
• Was produzieren wir wie?
• Wie reflektieren wir unsere Arbeit?
• Was verbessern wir grundlegend am Gesamtprozess?

Grundsätzlich gehen die Agilist:innen hinter den Modellen davon aus, dass ausreichend Kompetenz vorhanden ist, um solch offene und schlanke Konstrukte wirksam nutzen zu können. Immerhin werden mittlerweile im aktuellen Update des Scrum Guide die Zügel wieder etwas lockerer gelassen, was man durchaus als Reaktion werten kann.

Wie viel Scrum muss eigentlich in Scrum sein?

Diese Frage kann bei Projekten eine wichtige Rolle spielen, insbesondere in crossfunktionalen oder multidisziplinären Teams. Je nachdem wen man fragt, bekommt man darauf eine mehr oder weniger radikale Antwort. Denn obwohl Scrum als Leichtgewicht unter den Prozessmodellen angetreten ist, werden die Vorschläge des Scrum Guide tatsächlich vielfach als eine Art „Gesetz“ ausgelegt.

Bei team neusta wird darauf geachtet, dass die Teams im agilen Workflow genau das bekommen, was sie brauchen. Noch mehr Flexibilität erfordert (und erlaubt) das Denken im Rahmen der Organisationsberatung, die seitens team neusta geleistet wird. Gerade wenn man agile Arbeitsstrukturen in nicht-technischen Umfeldern realisieren will, ist agiler Dogmatismus völlig unangebracht. Das führt häufig dazu, dass bei unseren Kund:innen individuelle Modelle genutzt werden, die exakt zu ihrem Umfeld passen. Hierbei bedienen sich die Teams teilweise an Elementen von Scrum, Kanban und Co – je nachdem, wie es zum Projekt passt. Insgesamt lässt sich feststellen, dass kein bestimmter „Grad“ von Scrum in Projekten anzuwenden ist, sondern nur verschiedene Versionen des jeweiligen agilen Prozessgebildes. Und das ist gut so.

Dein Experte: Oliver Schaper arbeitet als Berater bei der HEC und ist überzeugter Agilist. Er verfügt über jahrelange Erfahrung in der Anwendung agiler Modelle wie Scrum in Kundenprojekten.

Du willst mehr erfahren?

Oliver Schaper freut sich von dir zu hören: oliver.schaper@hec.de

www.hec.de