Der Chef kommt rein und sagt: „Mayer, wir müssen was mit Scrum machen! Machen Sie mal Scrum in Ihrem Team, Sie fangen doch eh grad mit dem Projekt DKJWW an. Reporten Sie mir in 4 Wochen, wie wir Scrum am besten im Unternehmen einsetzen. Toi, toi, toi!“ So, und jetzt?
Herr Mayer ist ein senioriger Abteilungsleiter, gewohnt, auf kurzfristige Chef-Anfragen zu reagieren, die Dinge mit Engagement anzugehen und mit seiner Abteilung zum Erfolg zu führen. Scrum? Schon mal gehört, denkt er, aber googeln wir mal, wie das genau läuft. Aha, einen Scrum Master braucht man... Und einen Product Owner... Und man soll in 2- oder 3-Wochen-Zeitabschnitten arbeiten, sogenannten Sprints. Er liest sich ein und beschließt, einen Teil seines Fortbildungsbudgets für ein Scrum-Master-Training zu investieren, das glücklicherweise noch in derselben Woche auf dem Plan steht. Weil er weiß, dass er nicht zugleich Scrum Master und Product Owner sein kann, kommt Herr Schulz mit auf das Training, damit dieser als Product Owner fungieren kann. Montags darauf ist Kickoff-Meeting im Team: „Also... folgende Situation...wie werden jetzt mal eine Sache ausprobieren, die heißt Scrum. Herr Schulz, der ja ohnehin Projektmanager ist, ist dabei unser sogenannter Product Owner, das ist die Projektmanagementrolle in Scrum. Wir haben beide eine Schulung dazu gemacht. Ich werde das Amt des Scrum Masters bekleiden, der sorgt dafür, dass alle möglich gut läuft, Probleme identifiziert und gelöst werden und so weiter.“
Die Teamstimmung rangiert von desinteresssiert („Scrum = die nächste Sau durchs Dorf getrieben“) über mittelbegeistert („ein Bekannter von mir bei TheOthers GmbH macht Scrum, der hat gutes berichtet“) bis hin zu einem Fall von Enthusiasmus („endlich agil, ich sags ja schon die ganze Zeit!“). Erkennen Sie sich wieder?
Einführungen von Agile laufen oft so. Ich darf das aus vollem Herzen sagen, da die Einführung bei der Firma, bei der ich bin, der TechDivision, mit ein paar Unterschieden im Detail so ungefähr lief. Das ist legitim und eher häufig in meiner Erfahrung, der Dreisprung geht so: Wir haben ein Problem. Es gibt eine Idee, wie wir es anders angehen könnten, diese Idee kommt „von oben“. Wir starten.
Die Reise beginnt
Die Entwicklungsabteilung von Herrn Mayer startet den ersten Sprint. Herr Schulz hat ein Backlog mit User Stories gefüllt, es wurde besprochen, geschätzt, geplant, und der Sprint geht los. Neun User Stories haben es in den Sprint geschafft und werden vom Team umgesetzt. Zwei Wochen später ist Review-Meeting mit dem Kunden, in dem das Team mit Herrn Schulz die Ergebnisse des Sprints Herrn Mayer und anderen Stakeholdern präsentiert. Nach einer Retrospektive im Team, was man im nächsten Sprint besser machen könnte, wird der nächste Sprint geplant, und weiter geht’s!
Ist das jetzt Agile?
Ja. Und nein. Und über diesen Unterschied möchte ich sprechen. Wussten Sie, dass Herr Schulz, der PO, in seiner Freizeit Kung Fu macht? Einen Shaolin-Stil, um genau zu sein. Wenn Sie mich fragen, ist das Kung Fu, sage ich: Ja. Wenn Sie einen 70-jährigen Shaolin-Mönch aus Tibet fragen, sagt er vielleicht nein... Herr Schulz macht die Bewegungen soweit ganz gut, aber Kung Fu ist es noch nicht wirklich. Und wussten Sie, dass Herr Mayer in seiner Freizeit Aquarelle malt? Landschaften, um genau zu sein. Wenn Sie mich fragen, ist das Kunst, sage ich: Ja. Haben Sie die Bilder gesehen? Toll! Wenn Sie einen Künstler von Weltrang fragen, sagt er vielleicht nein: Es sind schöne Bilder, aber es ist keine Kunst, weil Herr Mayer Abteilungsleiter ist, und einer sein will, und kein Künstler. Ist das Arroganz? Geht es um besser und schlechter? Ist das Kung Fu von Herrn Schulz jetzt schlechter als das Kung Fu eines buddhistischen 70-jährigen Shaolin-Mönchs aus Tibet? Sind die Auqarelle von Herrn Mayer schlechter als die von einem Künstler von Weltrang?
Was ist das Ziel? Was ist der Zweck?
Nein! Sie sind nicht schlechter. Sie sind etwas anderes. Sie dienen einem anderen Zweck, sie haben ein anderes Ziel. Ist es arrogant, das so zu sehen? Ist es arrogant, dem Team von Herrn Mayer abzusprechen, dass es agil ist? Vielleicht müssen wir uns klar werden, dass die Frage an sich unsinnig ist. Ist Agile eine Religion? Wollen Sie agil sein, weil das die Erfüllung unseres göttlichen Lebenssinnes ist? Nein. Wir wollen agil sein, um unsere Ziele (besser) zu erreichen. Insofern hat das Mayer-Team einen Erfolg zu verzeichnen: Nach zwei Wochen hat man etwas geliefert, statt sonst nach sechs Monaten. Unmittelbares Feedback der Stakeholder folgte, man riskiert also nur zwei Wochen Fehler, nicht sechs Monate. Man lernt nach zwei Wochen, nicht nach sechs Monaten. Das ist agil: Schnelles Feedback, schnelle Anpassungsfähigkeit. Jedoch machen wir das nicht, um Scrum zu machen, sondern um erfolgreich zu sein. Wenn also jemand behauptet, dies sei agil und jenes nicht, geht das nicht am eigentlichen Thema vorbei: Was bringt uns Erfolge? Was ist das Ziel unseres Tuns? Sicher nicht: Agile sein um des Agilen willen.
Agile Fortschritte: Sein versus Tun
Das Agile Fluency Model von Diana Larsen und James Shore (zwei Urgesteine der agilen Welt) beschreibt vier Level. Das Augenmerk liegt dabei nicht auf den Praktiken, die gerade ausgeführt werden (etwa Sprints, Retrospektiven etc.), sondern auf dem Grad, in dem Verhalten und Mentalität „wie im Schlaf“ beherrscht werden. Fluency beschreibt beim Spracherwerb die Fähigkeit, die Sprache fließend, ohne Nachdenken zu sprechen. In einer Krise, einer brenzlichen Diskussion, einem schwierigen Klärungsgespräch, ist Ihnen da Englisch oder Deutsch lieber? Vermutlich Deutsch, wenn Sie Muttersprachler sind, weil Ihre „Flüssigkeit“ in Deutsch größer ist. In Englisch müssen Sie sich eher konzentrieren, mal nach den Worten suchen, Sie beherrschen die Nuancen und Feinheiten weniger usw. Im Normalfall ist das nicht so wichtig. Im Ernstfall kann es den entscheidenden Unterschied machen. Dasselbe ist bei der agilen Fluency gemeint: Welches Level hat ein Team, wobei es ohne Nachzudenken mühelos und automatisch ein Muster von Verhaltens- und Denkweisen anwendet? In einem solchen Level „tut“ man nicht agil, man „ist“ agil. Das klingt esoterisch? Ist es nicht. Den Experten unterscheiden vom Anfänger v.a. Reflexe, implizites Wissen, Bauchgefühl (die Summe der Erfahrungen!). Die Frage nach „Sind Sie agil?“ ist also ungefähr so präzise wie die Frage „Können Sie Englisch?“. Entscheidend ist, ob Sie im Urlaub im Laden Brot und Olivenöl kaufen wollen, und das Englisch dafür passt, oder ob Sie als Simultanübersetzer in der UNO arbeiten wollen, und das Englisch dafür passt. Je höher das Level sein soll, desto mehr muss man übrigens investieren. Küchen-Englisch lernt man schneller also UNO-Simultanübersetzer-Englisch. Agilität in einzelnen, wertorientierten Praktiken lernt man schneller als Agilität als ständige Optimierung auf systemischer Ebene.
Die Reise geht weiter
Um Agilität in die Organisation zu bringen, sind also vor allem folgende Punkte zu bedenken:
- Warum wollen Sie Agile? Welche Ziele verfolgen Sie damit?
- Welche Level an Agile ist für Sie (momentan) das richtige Ziel?
- Wie viel sind Sie bereit, zu investieren? Dabei geht es nicht nur um Geld, sondern auch um Veränderungsbereitschaft – in der gesamten Organisation!
Das simple Prinzip „Mach lieber eine Sache gut als fünf Sachen halbgar“ gilt auch hier. Es ist wichtig, die „agilen Reflexe“ auf einem Level einzuüben, bevor man Halbfertiges in die ganze Organisation trägt. Es bringt nichts, etwas zu multiplizieren, was in sich noch nicht wirklich funktioniert.
Und denken Sie vom Ziel her. Man kann Scrum machen, ohne agil zu sein, und man kann agil sein, ohne Scrum zu machen. Was ist Ihr Ziel? Seien Sie ehrlich zu sich selbst: Was brauchen Sie? Wollen Sie, dass Ihre gesamte Organisation adaptiv und selbstorganisiert am Markt operiert? Dass sie aus einem Netzwerk von verantwortlichen Individuen besteht, die globale Wertschöpfungsoptimierung in selbstorganisierten Teams vollzieht? In Kollaboration mit allen Stakeholdern? Wenn das so ist, und ich sage das nicht, weil ich Berater bin, ehrlich, aber: Dann lassen Sie sich helfen. Wenn Sie Kung-Fu in Weltklasse erlernen wollen, machen Sie das nicht allein. Wenn Sie Englisch auf UNO-Simultanübersetzer-Niveau lernen wollen, machen Sie das nicht allein. Als wir bei der Techdivision vor circa sechs Jahren den agilen Weg eingeschlagen haben, war uns das nicht klar genug. Wir haben viel gelernt, aber im Nachhinein weiß ich: Wir hätten es doch ein wenig leichter dabei haben können. Mein Fazit: Wenn Sie in einem Team Scrum und agile technische Praktiken einführen wollen, brauchen Sie (meiner Meinung nach vermutlich) keine Hilfe. Wenn Ihre Ziele darüber hinausgehen, holen Sie sich Hilfe.
Agile Vorgehensweisen bündeln und gründen sich im Agilen Manifest, das von führenden Denkern und Software-Entwicklern im Jahr 2001 veröffentlicht wurde. Man betitelt das Gesamtuniversum, das daraus entsprang, mit dem englischen Begriff Agile (ˈæd͡ʒ.aɪl). Die bekannteste und am weitesten verbreitete Umsetzung von Agile ist Scrum. Daneben gibt es nennenswerte andere, wie Extreme Programming (XP), Feature Driven Development (FDD), sowie Ansätze für sehr umfangreiche agile Vorhaben (Stichwort Skalierung) wie DSDM, SAFe, LeSS oder Nexus. Um die agilen Ansätze „herum“ gibt es viele Systeme, die Agile ergänzen oder bereichern, etwa Kanban, Design Thinking, Management 3.0, systemische Organisationsentwicklung usw.
Wenn Sie sich jetzt etwas tiefer einsteigen möchten, dann können wir Ihnen unser umfangreiches Whitepaper mit dem Titel "Modernes (Projekt-)Management" und über 100 Seiten geballtem Praxiswissen sehr empfehlen. Dies steht unter nachfolgendem Link kostenlos zum Download bereit: https://www.techdivision.com/projektmanagement-whitepaper.html