Agile Mythen: Agilität ist gleich Scrum ?!?

Rund um die Abgrenzung von Agilität ranken sich ja bekanntlich Mythen. Heute: Agilität ist gleich Scrum.

Nachdem sich Scrum in den vergangenen 20 Jahren immer stärker in der Softwareentwicklung etabliert hat, sehen es viele Menschen als den Stereotyp für agiles Arbeiten an. Aber war’s das? Steckt hinter dem Zauberwort “agil” noch etwas anderes? Ja, das sollte es, denn Scrum ist für die Produktentwicklung gedacht, und nicht jede Arbeit ist Produktentwicklung.

Das agile Universum besteht aus mehr

Sehen wir uns das agile Universum an, können wir einen stabilen Kern entdecken, um den sich alles dreht: Agile Werte und Prinzipien. Sie sind langfristig betrachtet stabil und unterliegen nur geringen Veränderungen.

Auf diese Werte und Prinzipien bauen die agilen Frameworks auf. In dieser Sphäre liegen neben Scrum auch andere viele andere agile Arbeitsweisen wie z.B. Scrum, Design Thinking oder Kanban. Agile Frameworks geben – wie der Name schon sagt – einen Rahmen vor, mit dem agil gearbeitet werden kann. Diese Rahmenwerke sind ziemlich stabil, es kommt jedoch auch hier zu Veränderungen. Ein Beispiel hierfür ist das Produkt Backlog Refinement. Dieses war im „Ur-Scrum“ nicht vorgesehen. Es hat es sich in der Praxis aber bewährt, und so wurde es in den Scrum Guide aufgenommen.

Rund um die agilen Frameworks gibt es ein – sehr breites – Set an (agilen) Arbeitstechniken. Techniken können im Rahmen agiler Frameworks mehr oder weniger beliebig eingesetzt, ausgetauscht oder angepasst werden. Techniken sind keinem spezifischem Framework zugeordnet: so findet man z.B. das Kanban-Board unter dem Namen Task-Board auch in der Anwendung von Scrum wieder.

Diese Hinzunahme von Techniken zu den agilen Frameworks ist auch der Grund, warum man von “Rahmenwerken” spricht: sie geben einen Rahmen vor, der erst durch die Hinzunahme von agilen Techniken operational wird.

Im Umkehrschluss müssen Teams nicht alle agilen Techniken anwenden, um agil zu arbeiten – man denke hier zum Beispiel an das breite Set der Priorisierungstechniken: Magic Prioritization, WSJF und Kano haben sich beispielsweise im Umgang mit agilen Teams bewährt. Hier heißt es, auszuwählen.

Viele der agilen Techniken sind übrigens keine Erfindungen der Agilisten – Code Reviews ist beispielsweise nichts anderes als das Vier-Augen-Prinzip, dass uns fernab der Produktentwicklung in Bereichen wie Due Dilligence begegnet.

Agile Frameworks sind also agil !?

Das bedeutet also im Umkehrschluss, dass agil ist, wer agile Frameworks anwendet? – nicht ganz; nehmen wir das bereits erwähnte Beispiel Kanban: Kanban leitet sich aus dem Lean Management ab, welches in den 1970er von Toyota entwickelt wurde, also weit bevor sich die „Erfinder“ von agil damit beschäftigt haben, was agil ausmacht; zwar bauen diese auf dem Wissen auf, dass man durch die Anwendung von Lean Management erlangt hat, man kann aber klassisches Kanban implementieren, ohne sich an agilen Werten und Prinzipien zu orientieren. Für Lean Management gelten in erster Linie ausschließlich die Lean Prinzipien. Die Praxis zeigt uns aber, dass sich Kanban sehr gut mit „Agilität“ vereinbaren lässt, Teams, die sich an agilen Werten und Prinzipien orientieren, also produktiver werden.

Schwieriger wird die Sache schon bei Scrum: Scrum ist ja per Definition ein agiles Framework, das bedeutet also, dass wer Scrum anwendet, per Definition agil sein muss. – in der Theorie soweit stimmig. In der Praxis zeigt sich jedoch, dass Scrum oft unter Umständen implementiert wird, die echte Agilität beeinträchtigen oder behindern: Sieht man Scrum als modisches oder hippes Mittel, um Teams produktiver werden zu lassen, entspricht das einer kurz- bis mittelfristigen Sichtweise. Hierbei wird jedoch allzu gerne vernachlässigt, dass agil auch eine Veränderung in der individuellen Werthaltung, bzw. in der Werthaltung von Organisationen erfordert. Wie bereits erwähnt handelt es sich hier aber um langfristige Änderungsprozesse, die nicht von heute auf morgen stattfinden können. Agile Vorgehensweisen, Frameworks und Techniken werden also auf eine Organisation angewandt, welche die zugrunde liegenden Werte für sich nicht verinnerlicht hat. Wir nennen das mehr oder weniger liebevoll „Scrum-Theater“: Auf der öffentlichen Bühne wird ein stück gespielt, wie es hinter der Bühne zugeht, bleibt dem Zuseher aber verborgen. – Perfekte Voraussetzungen, um eine agile Transformation scheitern zu lassen und das Buzzword „Scrum“ verbrennen zu lassen.

Also erst ein paar Jahre an den Werten arbeiten?

Natürlich geht ein gesunder Veränderungsprozess in allen Bereichen Hand in Hand – den Prinzipien folgend inkrementell. Dazu muss an dieser Stelle gesagt werden, dass die Welt nicht schwarz und weiß ist; Techniken wie „Delegation Poker“ zeigen anhand des Beispiels „Selbstorganisation und Empowerment“ sehr schön auf, dass es auch bei der Frage wie Prinzipien gelebt werden können, Abstufungen geben kann. Entscheidend ist aber, dass wer #echtagil sein will, sein Framework wie auch seine Wertehaltung gleichermaßen entwickeln muss.