Christian Methfessel

Das Grundwasser, ganz unten, besteht aus einer speziellen mentalen Grundhaltung: Neugier und Experimentierfreude. Das wird häufig auch Growth Mindset genannt.

Wenn diese Grundhaltung nicht da ist, dann hat man quasi schon innerlich gekündigt: Wir haben keine Freude mehr an der Arbeit, wir wollen weder uns selbst noch unsere Zusammenarbeit oder unsere Produkte verbessern, und eigentlich ist doch alles sowieso egal.

Wenn diese Freude am Job fehlt (oder durch chronische Überforderung erstickt wurde), warum sollte man dann morgens überhaupt noch aufstehen und zur Arbeit gehen? Was zählen dann noch Werte, Erfolge, Leistungen und die Zusammenarbeit, wenn alles von Sinnlosigkeit, Hoffnungslosigkeit und Eintönigkeit geprägt ist? Wenn das Burnout (oder Boreout) an die Tür klopft?

Diese neugierige, begeisterte und wachstumsfördernde mentale Grundhaltung wurde vielen von uns leider schon früh in der Schulzeit abtrainiert. Höchste Zeit, dass wir uns einen Ort finden, in dem es noch richtig viel erfrischendes und mitreißendes Grundwasser gibt!

Über dem Grundwasser befindet sich eine nährende, wachstumsfördernde Erdschicht: Das ist unsere gemeinsame Wertebasis. Scrum basiert beispielsweise auf den fünf Grundwerten Offenheit, Engagement, Fokus, Respekt und Mut.

Für mich genauso essentiell sind die Werte Vertrauen (braucht viel Mut!), die Bereitschaft zu Reflexion und Adaption, sowie die Verlässlichkeit (was sich zum Teil auch in den Werten Engagement/Commitment und Respekt wiederfindet).

Eine gemeinsame Wertebasis ist deshalb so wichtig, weil sie die Grundlage für die weitere Zusammenarbeit bildet. Sie definiert, wie wir miteinander umgehen wollen und was für das Team wert-voll ist. Auf dieser fundamentalen Ebene befinden wir uns sehr abstrakt und im Inneren.

Wir finden hier noch keine konkreten Lösungen und Methoden. Sondern wir finden gemeinsam heraus, warum wir zusammenarbeiten wollen und warum wir ein Team sind (und nicht nur eine Anhäufung von Einzelkämpfern): Werte sind das WARUM des Teams.

Der Stamm des agilen Baumes ist fest in dieser nährstoffreichen Werte-Erde verwurzelt. Er besteht aus vier agilen Leitsätzen (im agilen Manifest etwas missverständlich ausgedrückt als "Agile Values", obwohl es keine Werte sind, sondern eben eher Leitsätze) und den zwölf agilen Prinzipien. Und dann natürlich aus allen Leitsätzen und Prinzipien, die dem Team etwas bedeuten. Beispiele könnten sein:

• Inspect & Adapt,
• schnelle und regelmäßige Iterationen,
• Entscheidungsbefugnis (und -verantwortung) liegt im Team,
• Transparente Kommunikation im Team und mit allen Stakeholdern.

Die agilen Leitsätze und Prinzipien definieren die Zusammenarbeit des Teams. Sie bieten noch immer nicht konkrete Handlungsanweisungen ("Wie genau stellen wir eine transparente Kommunikation sicher?"), sondern sind eher als richtungsweisende Beschlüsse zu verstehen.

Dadurch sind sie noch immer nicht wirklich konkret, aber schon etwas konkreter als die zugrundeliegende Wertebasis.

Für das Team beantworten diese agilen Leitsätze und Prinzipien die Frage: Wie möchten wir zusammenarbeiten? Welche Leitsätze führen uns durch unseren Arbeitsalltag und geben uns immer wieder die Leitplanken, auf denen wir unsere konkreten Entscheidungen und Umgangsformen ausrichten möchten?

Der Stamm wächst dann ins starke, tragende Geäst. Dies sind unsere agilen Frameworks, also Sammlungen an gut zusammenspielenden agilen Techniken und Methoden. Beispiele für agile Frameworks sind Scrum (mit Skalierungsframeworks wie LESS, SAFe, etc.), Kanban, aber auch "Extreme Programming" oder die "Design Thinking"-Philosophie.

Wir werden hier schon konkreter, aber wirklich ins Tun kommen wir auch hier noch nicht.

Man "macht" nicht Scrum. Man verwendet das Scrum-Framework, um sich eine gemeinsame Struktur mit klar definierten Rollen, Events und Artefakten zu geben.

Diese Struktur setzt sich also wiederum aus vielen konkreten Einzelteilen zusammen:

Diese Frameworks verzweigen sich dann also in die Baumkrone, in ganz viele verschiedene Techniken, Praktiken und Werkzeuge. Diese Techniken kann man nun konkret einsetzen, kombinieren und ergänzen.

Dabei müssen diese Werkzeuge gar nicht unbedingt immer im Rahmen des Scrum-Frameworks implementiert sein. Jedes agile Tool für sich kann das Team schon ein gutes Stück weiter bringen.

Techniken, Praktiken und Werkzeuge sind beispielsweise Meetings/Events wie die Retrospektive, gemeinsame Plannings, kurze Abstimmungsintervalle (Daily Scrum).
Aber auch klar definierte Rollen (wie z.B. ein Scrum Master, ein Product Owner oder ein Kanban Guru) gehören dazu.

Weitere konkrete Praktiken sind zum Beispiel ein Kanban-Board (denn es verbessert die Transparenz im Team und macht Workflows sichtbar), Burndown Charts, WIP Limits, User Stories, Sprints, Story Points sowie Software und Tools zum Verbessern der Zusammenarbeit (wie JIRA oder Git) und der transparenten Kommunikation (wie Confluence, Teams oder Miro).

Häufig wird der Blick ausschließlich auf das Außen, auf das konkret Sichtbare und Machbare geheftet:

Wir verwenden also Scrum mit allem, was dazu gehört:
Mit fest definierten Sprints, mit Sprint Plannings, Sprint Retrospectives, Sprint Reviews, Daily Standups, Story Points, Scrum-Rollen sowie Produktinkrementen und einem Product Backlog. (Häufig wird bei diesem Ansatz leider auch das Sprint Ziel weggelassen, da es ja keinen sichtbaren Mehrwert bietet).
Oder wir verwenden ein Kanban-Board.
Oder wir führen die Software JIRA ein, weil alle das halt so machen.

Das alles ist lediglich "Doing Agile": Man macht halt das, was andere als "agil" bezeichnen.
Ist man dadurch wirklich agil?

Die große und wichtigste Frage dahinter wird dabei häufig außer Acht gelassen:
WARUM tun wir das?

• Warum wollen wir Scrum verwenden?
• Weshalb nutzen wir JIRA?
• Was bringt uns ein Burndown Chart?

Dann baut man eine große, weit auslaufende Baumkrone auf einen dürren, nicht tragfähigen Stamm und auf einer nährstoffarmen Erde, der die ganzen gemeinsamen Werte und das grundlegende Verständnis fehlen.

Denn man arbeitet nicht agil, weil es der Chef oder die R&D-Abteilung so vorschreibt. Wirklich agil ist es erst dann, wenn das Team bei jedem einzelnen Werkzeug verinnerlicht hat, warum sie dies konkret einsetzen wollen und was es dem Team nützt.

Warum das Team genau diese Methoden einsetzen will, um basierend auf ihrer gemeinsamen Wertebasis und ihren "so möchten wir miteinander umgehen"-Prinzipien so richtig geile Arbeit zu machen. Das ist dann "Being Agile": Dann ist/lebt man wirklich agil!

Wir können mit dieser Baum-Metapher noch ein Stück weiter gehen und die Unternehmenskultur mit ins Bild holen:

Die Kultur im Unternehmen, die auf einer neugierigen, experimentierfreudigen Grundhaltung (Grundwasser) und einer wachstumsfördernden, gemeinsamen Wertebasis (Erde) aufbaut, könnte dann der Wald sein.

Das ist doch eine schöne Vorstellung, oder?