NBAK04: Mindset vor Methode

Viele Teams machen Scrum, nutzen Jira, halten ihr Daily – und sind trotzdem frustriert. Der Grund: Sie haben bei der Methode angefangen statt bei der Haltung. In dieser Folge erkläre ich, warum Agilität zuerst ein Mindset ist, wofür die Stacey Matrix gut ist und welche zehn Bausteine wirklich zählen.

Überblick

„Wir machen doch Scrum" – und trotzdem funktioniert es nicht. Dieses Gefühl kennen viele. In dieser Folge gehe ich der Ursache auf den Grund: dem Missverständnis, Agilität sei eine Methode. Ich zeige, warum die erste Frage immer lauten muss „Was für eine Arbeit machen wir eigentlich?", wie die Stacey Matrix bei der Antwort hilft und warum das Mindset immer vor dem Framework kommt.

Zusammenfassung

Agilität wird oft mit klassischem Projektmanagement verwechselt – pünktlich, im Budget, unter Kontrolle. Genau das kann und will sie nicht leisten. Sie ist die Antwort auf Neuland: Projekte, bei denen weder Anforderungen noch Lösungsweg am Anfang klar sind. Die Stacey Matrix macht sichtbar, wann agiles Arbeiten sinnvoll ist und wann ein klassischer Plan genügt. Der entscheidende Punkt: Scrum, Kanban und Jira sind nur Hilfsmittel, die auf einem Fundament aufsetzen – dem Agilen Manifest und seinen Prinzipien. Wer dieses Fundament überspringt, spult Zeremonien ab, ohne agil zu sein. Die zehn „Agile Primitives" von Stefan Wolpers sind der Baukasten, auf den es wirklich ankommt – unabhängig von jeder Methode.

Shownotes

• Du erreichst mich hier
• Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du hier
• Die Stacey Matrix: Wann agil, wann klassisch? 
• Buch: „Agiles Arbeiten in der Praxis" – no-bullshit-agile.de/buch
• Diskutier mit auf Mastodon

Transkript

 Hallo und herzlich willkommen bei NoBildshit Agile Kompakt, mein Name ist Thomas.
 In der letzten Folge habe ich über die 12 agilen Prinzipien gesprochen, die habe ich
 tatsächlich umgewandelt in Fragen, weil ich das Gefühl habe, mit solchen Fragen kann
 man im Team, in einem Meeting zum Beispiel mehr anfangen.
 Heute geht es tatsächlich, wie ihr im Titel wahrscheinlich gesehen habt, um Mindset-Vormethode
 und ich höre euch schon stöhnen, agiles Arbeiten ist ein Mindset.
 Ich weiß, das ist ziemlich platt getreten, aber ja, gibt dem Ganzen eine Chance, ich
 habe da so einen gewissen Spin drauf.
 Ich bin der Meinung, man muss zuerst im Kopf verstehen, warum man agil arbeiten will und
 was das bedeutet und erst dann wendet man einen Werkzeugkasten an, also Werkzeugkasten sowas
 wie Scrum oder Werkzeugkasten sowas wie Jira oder einem Daily.
 Es ist wichtig, deswegen habe ich damit angefangen zu verstehen, was bedeutet agiles Arbeiten
 im Fundament, warum arbeitet man überhaupt agil.
 Man muss das agile Manifest und die agilen Prinzipien verstehen, warum die entstanden sind, was der
 Hintergrund dazu ist und dann kann man sich mit Methoden und Implementierungsarten beschäftigen.
 Ihr baut sonst zuerst das Dach von einem Haus, bevor ihr das Fundament habt und dann wundert
 ihr euch, ja, warum bleibt das Dach nicht in der Luft schweben.
 Also, was für eine Arbeit machen wir eigentlich, das ist eine entscheidende Frage.
 Und ich höre halt immer wieder und lese auch immer wieder, wir machen doch Scrum, warum funktioniert
 es bei uns nicht?
 Und ja, oft genug liegt eben das Problem genau an dieser Stelle.
 Da ist was implementiert worden, eine Methode, aber das Verständnis, warum wollen wir diese
 Methode anwenden, das ist halt nicht da.
 Aber das erste Missverständnis ist so ein bisschen, dass es oft eine falsche Erwartungshaltung
 gibt.
 Also, macht das einfach mal zum Spaß, ich habe das auch mal gemacht, googelt einfach mal
 why agile oder warum agil.
 Da kommen sehr interessante Sachen bei raus, also sowas wie, hilft Projekte pünktlich im
 Budget abzuschließen oder da habe ich eine bessere Projektkontrolle.
 Und da sieht man halt schon, wo der Denkfehler ist.
 Agiles Arbeiten hat nichts mit Projektmanagement oder Projektcontrolling zu tun.
 Darum geht es agil im Arbeiten nicht.
 Ich finde, eine fundamentale Frage, die man sich da stellen kann, ist, was für eine Arbeit
 machst du?
 Also, dein Team, dein Unternehmen und ich habe da zum Beispiel, ich weiß, das stimmt nicht
 so ganz, aber ich finde es halt einfach passend, wenn man einen Golf baut, einen VW Golf, das
 Auto, dann ist es halt so, dass eigentlich ziemlich klar ist, wie dieser Golf gebaut werden
 muss.
 Das hat man einmal erforscht und ab dann ist es nur noch Reproduktion.
 Also, wir bauen jetzt von dieser Variante des Golfs 200.000 Stück.
 Und wenn wir in Software arbeiten, ist es sehr, sehr oft so, dass wir Neuland betreten.
 Die Anforderungen sind vage.
 Manchmal weiß der Kunde auch nicht so genau, was hinten rauskommt.
 Das ist auch ganz normal.
 Das ist überhaupt kein Vorwurf.
 Und wir erkennen eben an, dass wir im Projekt schlauer werden, dass wir am Anfang von einem
 Projekt nicht benennen können, wo wir landen und wann wir sagen, so ist es gut oder gut
 genug.
 Und das ist halt der große Unterschied zu sowas wie einem Golf bauen.
 Da weiß man eben, wenn der gebaut wurde, dann hat der folgende Eigenschaften.
 Und da sind sich alle auch einig drüber.
 Und um das ein bisschen auf eine Landkarte zu malen, gibt es eigentlich ein ganz schönes
 Bild, auch schon ziemlich alt, die sogenannte Stacy-Matrix.
 Die verlinke ich auch.
 Und die hat im Prinzip zwei Achsen.
 Auf der einen Achse steht das was, also sind die Anforderungen klar.
 Und auf der anderen Achse steht das wie, ist der Lösungsweg klar.
 Und daraus entstehen so vier Bereiche.
 Es gibt so einen Bereich einfach, also Anforderungen sind sehr klar und Lösungsweg ist sehr klar.
 Da kann man einen Wasserfall machen.
 Das ist überhaupt kein Problem.
 Am Wasserfall selber ist ja auch nichts Schlimmes.
 Dann gibt es einen Bereich, der ist kompliziert.
 Da braucht es dann vielleicht Expertenwissen.
 Aber ich kann trotzdem noch eine klassische Methode anwenden.
 Also es ist eigentlich klar, was rauskommen soll.
 Dann kommen wir in einen ganz interessanten Bereich, nämlich in den Bereich Komplex.
 Da sind wir oft in der Softwareentwicklung.
 Das ist das Neuland.
 Die Anforderungen sind nicht ganz klar, also das was.
 Und der Lösungsweg ist nicht ganz klar.
 Wir haben das nicht hunderttausend Mal gemacht.
 Das ist also eine komplexe Umgebung.
 Und da ist Agilität zu Hause.
 Und dann gibt es ganz rechts oben noch so einen Bereich Chaos.
 Hier ist halt im Prinzip kein Plan möglich.
 Da muss man erstmal stabilisieren, um zumindest in diesem Bereich komplex zu kommen.
 Dafür gibt es dann zum Beispiel ja diese weltberühmten Spike-Stories.
 So eine Erforschungs-Story.
 Also wichtig ist zur Ergänzung vielleicht an dieser Stelle,
 wenn man dieses Bild von der Stacey Matrix mal verstanden hat,
 noch ein bisschen Begrifflichkeit.
 Agil heißt halt nicht schnell.
 Agil heißt beweglich sein.
 Und darum geht es.
 Es geht, einen Weg zu finden im unbekannten Umfeld,
 ein schnelles, ein gutes, ein bewegliches Vorgehen zu finden.
 Und da drin zu lernen.
 Ja, und so komme ich eben darauf, dass Agilität ein Mindset braucht.
 Man muss das Verständnis dazu haben.
 Das meine ich mit Mindset.
 Und dann wird dieses Bild, das Agile Manifest, zwölf Prinzipien, total klar.
 Und dann ist es auch wirklich kein Problem, eine Methode jetzt anzuwenden,
 wie zum Beispiel Scrum und zu sagen, okay, das ist ja gut.
 Und natürlich ist es so, viele Menschen wollen gerne klare Regeln.
 Deswegen ist Scrum da halt ziemlich gut, um einzusteigen.
 Und da habe ich auch überhaupt kein Problem mit.
 Ich finde es halt gut, das habe ich in anderen Folgen ja auch schon mal gesagt.
 Vielleicht muss man sich an manchen Stellen dann ein bisschen weiterentwickeln.
 Ja.
 Wichtig finde ich als Zusammenfassung, macht euch da wirklich mal Gedanken,
 was produziert ihr, in welchem Umfeld arbeitet ihr?
 Ist das alles eher unbekannt?
 Ist das vielleicht alles eher komplex?
 Oder ist es doch eher einfach und repetitiv?
 Und schaut euch gerne das Agile Manifest und zwölf Prinzipien nochmal an
 und überlegt euch mal, wie passt das denn zu dem, wie wir jetzt agil arbeiten?
 Also wenn ihr eine Methode anwendet, wie ihr die anwendet?
 Ich finde, daran kann man viel sehen.
 Es ist halt eine Haltung und ihr braucht erst eine Haltung, ein Verständnis.
 Und dann kommt das Werkzeug, also die Methode.
 Ich werde dazu in der nächsten Folge, der Agile Eisberg, nochmal ein Bild malen,
 dass das Ganze noch von der anderen Seite beleuchtet.
 Nämlich, wenn wir über agiles Arbeiten sprechen,
 nennen viele Leute sehr schnell sowas wie Scrum, Daily, Retro.
 Das ist Leuten immer klar, aber es steckt halt viel, viel mehr dahinter.
 Und das ist halt deswegen dieses Eisbergbild unter der Wasseroberfläche verborgen.
 Wie gesagt, da würde ich dann in der nächsten Folge nochmal drüber sprechen.
 Ansonsten sind wir für heute durch.
 Ich hoffe, dir hat das gefallen.
 Ich freue mich über Feedback.
 Wie du mich erreichst, findest du in den Shownotes.
 Übrigens auch Verlinkungen zu weiterführenden Themen findest du in den Shownotes.
 Und ansonsten sage ich, ich habe noch eine ganz tolle Woche.
 Und bis zum nächsten Mal bei NoBudget Agile Kompakt.