29.04.2022 -
Agilität ist wie Fahrradfahren. Man verlernt die Methodik nicht, wenn man sie einmal erlernt und angewendet hat. Genauso wie das Radfahren muss Agilität aber gelernt und geübt werden. Und das sicher nicht an einem Steilhang mit einem Rennrad, sondern erst einmal auf einer wenig befahrenen Straße oder einen ruhigen Platz ohne Gefälle, um bei der Analogie zu bleiben. Viel zu oft wird Agilität nämlich erst in einer Notlage angewendet, wenn das wichtige Großprojekt schon fast in den Graben gefahren ist und Scrum es nun zu einem erfolgreichen Ende bringen soll.
Weiterlesen »
29.04.2022 -
Agilität ist wie Fahrradfahren. Man verlernt die Methodik nicht, wenn man sie einmal erlernt und angewendet hat. Genauso wie das Radfahren muss Agilität aber gelernt und geübt werden. Und das sicher nicht an einem Steilhang mit einem Rennrad, sondern erst einmal auf einer wenig befahrenen Straße oder einen ruhigen Platz ohne Gefälle, um bei der Analogie zu bleiben. Viel zu oft wird Agilität nämlich erst in einer Notlage angewendet, wenn das wichtige Großprojekt schon fast in den Graben gefahren ist und Scrum es nun zu einem erfolgreichen Ende bringen soll. Ohne dass die Mitarbeiter vorher in einem stressfreien Rahmen mit Fokus auf Teamwork agile Methoden einüben, praktizieren und verinnerlichen konnten, wird der Rettungsversuch des Projekts scheitern. Trotz beispielhafter Sprints wie aus dem Lehrbuch und Daily Meetings wird Scrum kein Projekt retten können. Marcus Raitner hat diesen schönen Vergleich auf Führung-erfahren.de ausgeführt und erklärt in seinem Artikel, wie Agilität wirklich zum Erfolg führt. Wir fassen
seinen Artikel im Folgenden für Sie zusammen.
Klein starten, aber nicht zu klein
Idealerweise sollten agile Arbeitsmethoden in einem geschützten Rahmen ausprobiert werden können. Wenn Sie Ihr Unternehmen also auf agile Methoden umstellen wollen, beginnen Sie im Kleinen. Steigern sie sich von Projekt zu Projekt, wagen Sie sich nach und nach an komplexere Aufgaben heran und weiten Sie die Agilität schließlich auf alle Projekte aus. Marcus Raitner weist aber auch darauf hin, dass man nicht zu klein starten sollte. Einfach bestehende Arbeitsgruppen oder Gremien von einem Tag auf den anderen zu agilen Teams zu erklären und ansonsten alle Strukturen genauso zu belassen, wie sie es schon immer waren, wird natürlich keinen Erfolg bringen. Raitner nennt das „Agilität im Silo“ und ist davon überzeugt, dass diese sich nur minimal, wenn überhaupt, auf die Geschwindigkeit und die Wertschöpfung auswirkt. Wieder kommt der Fahrradvergleich ins Spiel: mit einem eleganten Sportlenkrad erzielen Sie nur ein besseres Aussehen, keine Veränderung am Fahrverhalten.
Behutsamer Einstieg in die Agilität
Perfekt für den Start in die agile Transformation Ihres Unternehmens ist ein kleineres Projekt oder Produkt, bei dem ein oder zwei Teams innerhalb kurzer Zeit einen echten Wert kreieren. Es sollten natürlich echte Spezialistenteams sein, nicht bloß ein Entwicklerteam oder ein Testteam, sondern ein wichtiges interdisziplinär zusammengestelltes Team, das mit jedem Sprint das Produkt ein wenig verbessert. Viel wichtiger als das lehrbuchmäßige Abarbeiten von Sprints ist dabei der Aspekt des Teamworks und der Ownership. Wie beim Radfahren sollten die frisch gebackenen interdisziplinären Teams nun in einer Umgebung üben können, die kaum Störfaktoren aufweist. Kein Schotter, kein Autoverkehr, keine zu steilen Hänge. Einfach eine flache Fläche, auf der der Neuling in die Pedale treten und sich an das Gleichgewichthalten gewöhnen kann. Was mit Schotter und Hängen gemeint ist, können Sie sich ja vorstellen. Idealerweise gäbe es bei diesem ersten Übungsprojekt keinen großen Zeitdruck, denn in Phasen mit hohem Zeitdruck ist die Änderung der Gesamtstrategie nie eine gute Idee. Wie wäre es zum Beispiel mit einem Projekt oder Produkt, das intern im Unternehmen verwendet werden soll? Das wäre eine Möglichkeit, den Druck vom neu gebildeten Scrum Team zu nehmen und tatsächlich eine störungsarme Umgebung zu schaffen.
Die ideale Umgebung für Agilität
An dieser Stelle zitiert Raitner Brooks Law: „Adding manpower to a late software project makes it later.“ Auch wenn in vielen vor allem älteren Büchern zum Projektmanagement die Ergänzung von mehr Ressourcen als Allheilmittel für verspätete Projekte angepriesen wird, wurde dies wohl spätestens in der Softwareentwicklung vollkommen widerlegt. Mehr Ressourcen helfen vielleicht zu Beginn noch, aber wenn es bereits Verspätung gibt, sorgen mehr Ressourcen nur für zusätzlichen Verzug. Und wer in der kritischen Phase seines Projekts eine Verspätung mit der abrupten Einführung von Scrum Methoden retten will, wird ebenso scheitern. Scrum kann nicht in einer Notlage als Patentrezept gesehen werden, dafür ist es viel zu komplex und es kann auch nicht mehr Projekte schneller durch ein enges Nadelöhr drücken, wenn es nicht von Anfang an eingesetzt wird. Und zwar richtig. Jeff Sutherland hat in seinem Buch über Scrum versprochen, dass durch Scrum eine Verdopplung der Arbeitsleistung in der Hälfte der Zeit möglich ist. Aber dieses Versprechen kann nur mit einem eingespielten Scrum Team gehalten werden, das seine Methodik kennt und das vor allem ein ideales Umfeld für agiles Arbeiten vorfindet. Dieses ideale Umfeld sieht so aus, dass im gesamten Unternehmen Barrieren eingerissen werden müssen. Es darf keine Hindernisse in der Kommunikation zwischen Forschung, Design, Verkauf, Marketing, Entwicklung und Produktion mehr geben. Alle müssen das Teamwork verinnerlichen und ernst nehmen. Jeff Sutherlands Versprechen kann auch erst dann eingelöst werden, wenn das entsprechende Unternehmen seine Lernphase schon hinter sich hat. Niemand halbiert auf Knopfdruck die Zeit für ein Projekt. Alles will erst einmal gelernt werden. Aber wenn Barrieren fallen und Schnittstellen quasi entfallen, weil alle zusammen arbeiten, dann liefert Srcum Erfolge. Marcus Raitner verweist noch einmal auf einen verbreiteten Fehler: Wenn Sie einfach ein Konzeptteam, ein Entwicklungsteam und ein Testteam haben, die zwar nach agilen Vorgaben arbeiten, die aber ganz traditionell nacheinander die verschiedenen Phasen eines Projektes abarbeiten, dann hat das nichts mit agiler Arbeitsweise zu tun und es wird auch keine Erfolge zeigen, weder auf der Zeitschiene noch auf der Seite der Ressourcennutzung. Ist Ihr interdisziplinäres Team aber erst einmal eingespielt, dann werden die Projekte schneller und besser ablaufen. Versprochen. Es ist wie Fahrradfahren. Was das Team einmal gelernt hat, wird es auch in Zukunft anwenden können.
« Alle Beiträge