Warum Scrum (und andere Methoden) nicht der Pfad zur Erleuchtung sind

Kürzlich hat ein Kollege einen Bill-Talk über Scrum gehalten, um sein neuerworbenes Wissen aus der Scrum-Schulung mit uns zu teilen. Dabei kam die Frage auf: Muss es immer Scrum sein? Und was gibt es denn eigentlich an Alternativen zu Scrum?

Auch wenn sich Scrum heutzutage nicht mehr als reine Softwarentwicklungsmethodik versteht, ist Scrum gerade bei anderen Arten von Projekten oft nicht oder nur schwer in Reinform anzuwenden. Das hängt damit zusammen, dass der damit verbundene Wandel (bedingt durch die mit Scrum verbundenen Rollen, Events und Artifakte) oft einen ziemlichen Kulturschock darstellt und andererseits die Umgebungsbedingungen für eine Umsetzung auch nicht immer gegeben sind.

Kurzum: Manchmal stellt sich die Frage nach Alternativen.

Fundamente agilen Arbeitens

Bevor ich einen Blick auf die möglichen Alternativen zu Scrum werfe, möchte ich einen kurzen Blick auf die drei Säulen werfen, die das Fundament von Scrum und vielleicht sogar agilen Arbeitens an sich ausmachen:

• Transparenz

• Überprüfung

• Anpassung

Auch wenn als Argument für die Undurchführbarkeit von Scrum häufig die End Note im Scrum-Guide angeführt wird (da steht ungefähr: Wenn du Dinge veränderst, ist es nicht mehr Scrum) sollten wir uns immer bewusst machen, dass es bei agilem Arbeiten eben gerade nicht um buchstabengetreues Befolgen einer Methode geht.

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Viel mehr geht es darum gute Arbeit im Sinne des agilen Manifests zu leisten, also im Wesentlichen: Das bestmögliche für den Kunden rausholen, sich dabei möglichst auf das Wesentliche konzentrieren (Verschwendung zu vermeiden) und versuchen besser zu werden.

Das agile Mindset ist viel wichtiger als Methoden.

Diese Aussage kann man meiner Meinung nach nicht überstrapazieren. Methoden sollten einem nur zur Orientierung dienen, als Startpunkt um das eigene ideale Vorgehen zu finden.

Wo könnte man außer mit Scrum noch starten?

Scrum ist mit großer Sicherheit ein guter Startpunkt für Produktentwicklung mit einem dedizierten, standortgebundenen Team und wenn man selbstorganisierte Teams sowie die unmittelbare Einführung von neuen Rollen und festen Aktivitäten nicht scheut. Wenn doch, kann es auch ein guter Startpunkt sein, aber dann muss man vielleicht etwas mehr darüber nachdenken und gegebenenfalls auf Adaptionen ausweichen.

Ansonsten gibt es noch die folgenden Möglichkeiten:

Kanban

Kanban basiert auf Lean-Prinzipien und setzt vor allem auf evolutionärer statt revolutionärer Veränderung. In meinem Artikel „Kanban – Evolutionär statt Knall auf Fall“ hatte ich darüber schon mal geschrieben. Das ist vielleicht der zärtere Ansatz zur agilen Transition, für diejenigen die lieber mit dem kleinen Zeh ins Wasser gehen wollen statt gleich vom 10-Meter-Turm zu springen.

Scrumban

Scrumban vereint ein paar Aspekte aus Scrum mit Aspekten aus Kanban. Ursprünglich als Methode gedacht, um von Scrum zu Kanban zu wechseln (ja, das geht auch!), rutscht man hier vermutlich eher rein als das man Scrumban bewusst auswählt. Aber das muss natürlich nicht zwingend so sein.

Extreme Programming (XP)

Sehr auf Softwarentwicklung fokussiert (oh wunder bei dem Namen :-)) setzt Extreme Programming auf viele kurze statt eines langen Entwicklungzyklus, automatisiertes und parallel zur Entwicklung stattfindende Tests, viel Kommunikation (insbesondere auch zwischen Entwicklern und Kunden, um Verständnis für Business-Anforderungen zu entwickeln) und Feedback-Loops und – sehr wichtig – die Vermeidung von Überarbeitung.

Crystal Clear

Statt auf Prozesse oder Artifakte legt Crystal Clear von Alistair Cockburn den Fokus auf Menschen und verlangt neben einer sicheren Umgebung:

• Regelmäßige Lieferungen nutzbarer Ergebnisse an die Benutzer
• Verbesserung über Reflektion
• „Osmotische“ Kommunikation, indem Menschen bevorzugt am selben Ort sind

Ansonsten gibt es noch viele Methoden, von denen sich Manche nur auf Teilaspekte eines agilen Vorgehens konzentrieren: Agile modeling (Modellierung und Dokumentation von Software anhand von Best Practices), Dynamic systems development method, Feature-driven development und Rapid application development. Um nur ein paar zu nennen.

Vielen der Methoden merkt man an, dass sie von Softwareentwicklern für ihre Arbeit entworfen wurden und sich oft nicht 1:1 übertragen lassen. Auch aus diesem Grund sollte man nicht nach der bestimmten Methode als Pfad zur Erleuchtung suchen, sondern immer wieder: Try/Experiement, inspect and adapt.