5 Fakten über die agile Transformation

Ich war noch nie ein Fan von Horrorfilmen. Aber Halloween fand ich schon immer toll. Als Kind liebte ich es, mir gruselige Kostüme anzuziehen und damit meine Freunde und andere Leute zu erschrecken. Und ich gebe zu, dass ich den Nervenkitzel mag, an Halloween in ein gut hergerichtetes Gruselhaus zu gehen.

Allerdings gibt es auch bei jeder agilen Transformation Aspekte, die einem einen kalten Schauer über den Rücken laufen lassen können – und diese Momente sind nicht ganz so berauschend.

Lassen Sie uns also gemeinsam diesen fünf Dingen den Schrecken nehmen und darüber sprechen, was genau diese Dinge sind und warum sie gar nicht so furchteinflößend sind, wenn man sie erst einmal richtig verstanden hat.

1) Ahhh! In Agile gibt es keine Design-Phase!

Häufig sind die Architekten und Mitarbeiter der Entwicklungsabteilung beunruhigt, da es in Agile keine explizite Design-Phase gibt. Auch wenn es stimmt, dass agile Teams Design-Phasen zu Anfang eines Projekts vermeiden, bedeutet das nicht, dass das Design vernachlässigt wird.

Design in einem agilen Projekt ist durch zwei Merkmale gekennzeichnet: es ist emergent und intentional.

Emergentes Design kommt mit der Zeit zustande. Anstelle einer initialen Design-Phase ist das Design ein fortlaufender Prozess. Das Design entsteht bei der Erschaffung von Software.

Design ist aber auch intentional. Das bedeutet, dass das Design nicht zufällig entsteht. Das Design wird von den leitenden technischen Mitarbeitern eines Projekts oder sogar einem bestimmten Architekten geleitet.

Wenn sich diese Personen Sorgen über einen bestimmten Teil des Systems machen, sollte der [Product Owner]/de/product-owner/ "Product Owner") ein oder zwei [Product Backlog Items]( "Product Backlog Item") aus diesem Bereich priorisieren. Dadurch bekommt das Team die Chance, diesen Teil des Systems besser kennenzulernen, indem sie einen kleinen Teil davon entwickeln. Dies wird dabei helfen, das richtige Design dafür zu finden.

Entsteht das Design auf diese Weise durch die Entscheidungen des Teams, ist die Tatsache, dass es in Agile keine explizite Design-Phase gibt, gar nicht mehr so angsteinflößend.

2) Hilfe! Ich werde zum Generalisten!

Einer der am weitesten verbreiteten Mythen in Agile ist, dass agile Teams keine Spezialisten haben wollen und stattdessen möchten, dass jeder im Team ein Generalist ist.

Das macht vielen Leuten aus zwei Gründen Angst: Erstens erledigt nicht jeder gerne jede Art von Arbeit. Zweitens besteht oft Sorge, dass es zukünftig Auswirkungen auf die Arbeitsmarktfähigkeit haben könnte, wenn jemand vier Dinge halbwegs gut kann statt eine Sache extrem gut.

Die Vorstellung, dass jeder in einem agilen Team ein Generalist sein muss, ist falsch. Wenn ich ein Team coache, das den besten JavaScript-Profi der Welt hat, will ich, dass dieser Superstar tolle Dinge mit JavaScript macht und nicht, dass er lernt, ein Datenbankadministrator zu werden.

Ja, in agilen Teams möchte man Teammitglieder mit verschiedensten Fähigkeiten haben: z.B. den Tester, der auch ein wenig Code entwickeln kann. Die einfachste Möglichkeit ist, jemanden zu haben, der beide Arten von Arbeit gleich gut erledigen kann. Wenn Ihr Team beispielsweise ein Ungleichgewicht an Programmier- und Testarbeiten hat, ist es hilfreich, jemanden im Team zu haben, der sowohl programmieren als auch testen kann.

Ein Ziel in Agile ist die Bildung interdisziplinärer Teams. Das heißt, dass ein Team über alle Fähigkeiten verfügt, um ein fertiges, funktionierendes Produktinkrement in einer Iteration zu erschaffen. Das bedeutet aber nicht, dass jedes Teammitglied jede im interdisziplinären Team benötigte Fähigkeit besitzen muss.

Wenn der Gedanke daran, ein Generalist zu werden, Ihnen die Haare zu Berge stehen lässt, werden Sie erleichtert sein, zu erfahren, dass Spezialisten auch in interdisziplinären Teams willkommen sind.

3) Oh nein! Wir haben weder Pläne noch Voraussagen!

Häufig schüttelt es Manager bei dem Gedanken, dass ein agiles Team keine Pläne machen oder Vorhersagen über die aktuelle Iteration bzw. den aktuellen Sprint hinaus treffen kann.

Glücklicherweise ist das so nicht ganz richtig.

Ja, agile Teams geben den falschen Komfort überplanter Projekte mit unübersichtlichen Gantt-Diagrammen und exakten Zeitplänen bis weit in die Zukunft auf. Das bedeutet jedoch nicht, dass agile Teams nicht in der Lage sind, zu planen und die Zukunft zu prognostizieren.

Ein großer Vorteil agiler Methoden ist, dass das Team in jeder Iteration den gesamten Entwicklungsprozess überprüft und anpasst. Es nimmt eine Idee in Form einer einfachen User Story und implementiert dieses Feature. Das bedeutet, dass Teams alle paar Wochen ihren Fortschritt messen können. So finden sie heraus, wie viel Arbeit sie schaffen.

Vergleichen wir das mit einem traditionellen Entwicklungsprojekt, das vielleicht eine Analyse-Phase, eine Design-Phase, eine Coding-Phase und zum Schluss eine Test-Phase hat. Wenn solche Teams ihren Fortschritt messen möchten, können sie immer nur feststellen, wie schnell sie eine (oder vielleicht zwei) dieser Arbeiten erledigen. Wie schnell ein Team mit dem Design ist, sagt nichts darüber aus, wie schnell es mit dem Code oder dem Testen voran kommt.

Das Wichtigste bei der agilen Transformation ist, die Ungewissheit willkommen zu heißen – sich einzugestehen, dass es unmöglich ist, jegliche Funktionalität vor Beginn des Projekts zu kennen – und sich dann eine der vielen Möglichkeiten auszusuchen, um sich daran anzupassen. Wenn Teams das verstanden haben und die Menge an Arbeit in jeder Iteration messen, sollte dies das Management beruhigen und zu einer verlässlichen Planung führen.

4) Hilfe! Ich werde meinen Job verlieren!

Die Vorstellung einer agile Transition eines Teams oder eines ganzen Unternehmens kann dem ein oder anderen Manager einen ganz schönen Schrecken einjagen, denn viele haben Angst, dass ihr Job nach der Transition überflüssig sein wird.

Das ist verständlich. Natürlich wäre es schrecklich eine Transition zu beginnen und zu wissen, dass dies die eigene Rolle überflüssig macht.

Allerdings habe ich noch nie einem Unternehmen bei der agilen Transformation geholfen und mitbekommen, dass gesagt wird: „Okay, Leute mit dieser und jener Rolle brauchen wir jetzt nicht mehr. Sie werden alle gefeuert.” Das wird nicht passieren. Natürlich kann es sein, dass eine bestimmte Stellenbezeichnung nicht mehr benötigt wird oder nicht mehr adäquat ist, aber diese Personen haben dann immer noch einen Job. Ich glaube sogar, dass sie in den meisten Fällen hinterher mit besseren, passenderen Jobs dastehen als zuvor. Sicher kann es sein, dass einige Leute dadurch weniger direkte Kontrolle über Mitarbeiter und Entscheidungen haben und deswegen frustriert sind – manchmal sogar so frustriert, dass sie das Unternehmen verlassen.

Da ich noch nie gesehen habe, dass Personen mit bestimmten Rollen oder Fähigkeiten bei einer agilen Transformation einfach entlassen werden, denke ich, dass die Angst davor so unangebracht ist wie die vor einer Zombie-Apokalypse.

5) Uhhh! In Scrum gibt es zu viele Meetings!

Wie die meisten Menschen hasse ich Meetings. Im Großen und Ganzen geht es mir darum, warum ich tue, was ich tue. An den meisten Tage habe ich überhaupt keine Meetings. Welch ein Glück.

Trotzdem kann sogar ich mir eingestehen, dass einige Meetings wichtig und nützlich sind. Dies beinhaltet die vier Standard-Meetings in Scrum: Das Sprint Planning Meeting, das Daily Scrum, das Review und die Retrospektive.

Allein der Gedanke an all diese Meetings lässt manche Leute in Schweiß ausbrechen.

Und das Problem mit Scrum Meetings: sie haben einen Namen. Wenn etwas einen Namen hat, kann man es besser attackieren. Meiner Erfahrung nach hatten die meisten Teams vor Scrum mehr Meetings. Diese Meetings hatten aber keine Namen und wurden meistens spontan abgehalten, um bestimmte Dinge zu klären.

Mit einem Experiment können Sie das schnell überprüfen. Suchen Sie in Ihrem Kalender irgendeinen Monat, in dem Sie noch nicht mit Agile arbeiteten. Addieren Sie die Zeit, die Sie in diesem Monat in Meetings verbracht haben. Dann addieren Sie die Zeit, die Sie nun in Scrum Meetings verbringen und vergleichen die beiden Zahlen.

Ich glaube, dass Sie von dem Ergebnis überrascht sein werden. Da die Meetings in Zeiten vor der agilen Transformation nicht regelmäßig und wiederholt abgehalten wurden, hatten sie keine Namen und blieben so auch nicht im Gedächtnis wie beispielsweise ein „Sprint Planning Meeting”.

Der wichtigste Tipp, um keine Angst mehr davor zu haben, zu viel Zeit in Meetings verbringen zu müssen, ist, die Meetings kurz zu halten. Ab und zu arbeite ich mit Teams, die ich dazu auffordern muss, sich etwas mehr Zeit für ihre Meetings zu nehmen.

Die meisten Teams verbringen jedoch zu viel Zeit in den Scrum Meetings. Sobald man es schafft, sie kurz und knapp zu halten, sollten sie niemandem mehr Angst einjagen.

Fazit: Entspann’ dich… diese Geister sind nicht real!

Durch ein Gruselhaus zu laufen und sich zu verkleiden macht Spaß, da wir alle wissen, dass all das nur Schein ist. Die Geister, Monster, Vampire, Werwölfe und Verrückten mit einer Kettensäge sind nicht real.

Und die hier beschriebenen fünf agilen Mythen sind es auch nicht. Es ist nichts Verwerfliches, anfangs etwas ängstlich zu sein. Aufklärung und Erfahrung werden diese Mythen jedoch schnell enttarnen und Ihnen ein sicheres Gefühl geben.

Wenn du dir aber selbst ein Bild zu der Agilen Realität und den Mythen zu Scrum & Co ein Bild machen willst, wirf doch einen Blick in unsere Agile Journey, wo wir dir die Rollen genau vorstellen, oder werde jetzt zertifizierter ScrumMaster oder besuche unser Agile Leadership Training.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Innovation im Unternehmen

=> Was zeichnet innovative Unternehmen aus?

Gelebte Strategie

=> Finde heraus, wie du deine Unternehmensstrategie auf ein neues Level hebst.

Unbesiegbare Unternehmen

=> Wie sieht modernes innovationsmanagement im Unternehmen aus?