Mindset vs. Struktur in agilen Organisationen

‍

„Agil“ ist jetzt Mainstream. Ich setze es jedoch in Anführungszeichen, um zu verdeutlichen, dass „agil“ unterschiedliche Bedeutungen hat, je nachdem, wer das Wort benutzt. Für manche bedeutet es kaum mehr als die Denkweise, sich iterativ auf ein Ziel zuzubewegen. Für andere bedeutet es eine strenge Struktur von Produktentwicklungsprozessen, die die Zufriedenheit der Entwickler:innen fördern. Wieder andere verwenden es, weil sie es müssen, ohne die Denkweise oder die Prozesse zu haben, um die Vorteile von „agil“ wirklich nutzen zu können.

Durch meine Beteiligung an über 50 Projekten in allen Arten von Organisationen glaube ich, ein paar Dinge über „Agilität“ gelernt zu haben. Der wichtige Punkt ist, dass je nachdem, in welcher Organisation und in welchem Team man sich befindet, ein anderer Ansatz der Agilität am besten funktioniert.

Hier sind drei allgemeine Muster, die ich gefunden habe.

A. Minimale Struktur

In diesem Muster, das ich als das agile Ideal bezeichnen würde, wird nur produktive Arbeit geleistet, die direkt auf ein Ziel zusteuert. Das bedeutet keine strengen Strukturen oder Prozesse. Stattdessen leitet eine klare Vision das Team.

Voraussetzungen

• Ein extrem erfahrenes Team, das eher klein ist (< 8 Personen)
• Eine Organisation, die diesem Team die Freiheit lässt, seine Ziele zu erreichen, wie auch immer sie es wünschen
• Eine klare Vision

Vorteile

• Keine unnötigen Meetings oder Dokumentationen, keine stressige Arbeitsatmosphäre
• Schnelles und bewusstes Handeln

Gefahren

• Versuchen Sie dies mit dem falschen Team oder der falschen Führung, könnte am Ende nichts Brauchbares herauskommen.
• Arbeiten Sie nur mit erfahrenen Teams (keine Juniors), die sich idealerweise gut kennen
• Funktioniert nicht bei Projekten, die größere Teams erfordern

‍

B. Benutzerdefinierter Prozess

Größere Projekte erfordern größere Teams, größere Teams erfordern mehr Struktur. Bei diesem Muster nimmt man einen Ansatz wie SCRUM oder KanBan an, extrahiert, was für die Organisation funktioniert, und lässt weg, was nicht funktioniert.

Voraussetzungen

• Manager:innen, der über genügend Erfahrung verfügt, um einen guten, individuellen Prozess zu etablieren und der eine agile Denkweise hat (er besteht nicht auf strengen, vollständigen und im Voraus festgelegten Anforderungen)
• Organisatorische Freiheit, individuelle statt standardisierte Prozesse zu verwenden
• Genügend erfahrene Teammitglieder, um Qualitäts-Feedback zu geben und den Prozess im Laufe der Zeit zu verbessern auch für Neulinge an Bord

Vorteile

• Flexibler als SCRUM nach Vorschrift, weniger Zeitverschwendung
• Die Anpassung des Prozesses an das Team wird zu einem Prozess führen, mit dem alle Beteiligten zufrieden sein können

Gefahren

• Kann manchmal zu weit gehen und wesentliche Elemente agiler Prozesse unterschlagen
• Kann ohne Iterationen zu einem agilen Wasserfall führen
• Kann in größeren Organisationen auf Probleme stoßen, weil jedes Team seine eigene Version erstellt, was die teamübergreifende Zusammenarbeit behindert

C. Nach dem Lehrbuch

Organisationen, für die agil völlig neu ist, könnten davon profitieren, wenn sie ein strenges, im Lehrbuch vorgegebenes Verfahren wie SCRUM einführen, um die Denkweise über den Entwicklungsprozess zu verändern.

Voraussetzungen

• Zeit und Geld, denn für die Einführung eines Prozesses wie SCRUM wird man beides benötigen (aber auf lange Sicht sind Wasserfall-Ansätze mit agil leicht zu schlagen)
• Unterstützung des Managements für eine agile Transformation

Vorteile

• Vergleichsweise einfach einzuführen, da es Trainer gibt, die man einstellen kann
• Standardisiert und strukturiert, einfach für neue Teammitglieder an Bord

Gefahren

• Struktur kann das Mindset nicht vollständig ersetzen. Wenn das Management in alten, ineffektiven Paradigmen stecken bleiben, wird dies im schlimmsten Fall zu einem Wasserfall-Doppelgänger
• Wenn Ihre Unternehmensleitung gerne Meetings abhält, ist SCRUM ein guter Vorwand, um mehr und längere Meetings mit vielen Menschen abzuhalten und dabei unvorstellbar viel Zeit und Geld zu verschwenden.

Fazit

Es war eine harte Lektion für mich zu lernen – dass die auf den ersten Blick ineffiziente und verschwenderische Struktur eines Prozesses wie SCRUM manchmal die beste Option ist. Heute sehe ich das. Dennoch verspüre ich immer wieder die Sehnsucht nach minimaler Struktur, wenn ich vor einer Entwicklungsherausforderung stehe. Und ich würde immer noch sagen, dass für neue Prototypen oder Innovationsprojekte das Muster A. das Optimum ist – wenn man das erforderliche Team hat.

In späteren Phasen und größeren Organisationen muss diesem kleinen Team, das die ersten Prototypen erstellt, mehr Struktur folgen, die das Projekt langfristig bestimmt und erweitert, mit Ansatz B. oder C., je nach Ihrer Organisation und Ihrem Team. Und wenn es an der Zeit ist, sich für eine neue Hauptversion neu zu erfinden, peitschen Sie vielleicht das Expertenteam A. wieder aus, um auf möglichst agile Weise etwas Großartiges aufzubauen!