23 Wege um eine (agile) Transformation an die Wand zu fahren

Der ultimative Leitfaden zur Eliminierung von Selbstorganisation und Mitarbeitermotivation

Laura Sophie Aichroth, ST Kambor-Wiesenberg

• Verlag: Books on Demand
• Jahr: 2019
• ISBN drucken: 9783748178897
• eBook-ISBN: 9783749488704
• Auflage: 1
• Thema: Informatik
• Thema: Informationstechnologie

Laura & ST unterstützen seit vielen Jahren Individuen, Teams und Unternehmen bei (agilen) Veränderungsprojekten. Manchmal war das sehr enttäuschend und frustrierend. Als eigentherapeutische Maßnahme fingen sie an, sich Kurznachrichten zu schreiben, in denen sie ihre Umgebung satirisch wiedergaben oder einfach nur zitierten. Nachrichten wie: "Das kannste machen, wie du willst, aber nicht so." oder "Testen? Das machen wir nicht, das ist viel zu teuer. Wir ändern live!" oder "Das ist eine sehr gute Methode, aber bei uns funktioniert sie leider nicht." oder "In der Zeit für die Planung kann ich auch was Richtiges arbeiten." hellten die bedrückte Stimmung auf. Im Laufe der Zeit kamen kleine Zeichnungen dazu und so entstand die Idee für dieses Buch. Damit der Inhalt nicht nur negativ konnotiert ist, haben sie bei jedem Anti-Tipp Verbesserungsvorschläge beschrieben.

KAPITEL II

Agile washing

Gute Softwareentwickler sind schwer zu bekommen. Agilität, Scrum und Kanban sind angesagt. Das Problem: eine agile Transformation ist richtig anstrengend und man muss viel ändern. Unser Tipp: mache kleine Änderungen ohne großen Aufwand und simuliere ein agiles Umfeld. Kaufe einen Kickertisch, eine ordentliche Kaffeemaschine, suche einen Mate-Lieferanten und die Entwickler kommen zu dir. Jetzt musst du sie nur noch mit Versprechungen so lange hinhalten bis sie Teil deines Systems sind und sich nicht mehr wehren.

Klebezettel und neue Bezeichnungen = Scrum!

Benutze bunte Klebezettel am Fenster und mache Meetings im Stehen. Fertig ist Scrum. Alles andere kann so bleiben. Falls jemand eine präzisere Umsetzung der Methode fordert, benenne Meetings und Rollen um. Zum Beispiel Projekt Manager heißen jetzt Scrum Master, Entwickler sind jetzt DevOps oder das wöchentliche Reporting heißt nun Standup.

Kaum hat man einen Hammer, sieht man überall Nägel. Agile Frameworks wie Scrum tauchen auf und auf den ersten Blick sieht es so aus, als ob Scrum die Lösung für alle deine Probleme ist. Das ist unserer Erfahrung nach selten der Fall. Es gibt oft Probleme, die vor dem Scrum Prozess liegen.

Beantworte folgende Fragen und mache die Antworten für alle Beteiligten und Betroffenen transparent:

• Welches Problem hast du?
• Eignet sich die Art deiner Aufgaben überhaupt dafür, Scrum einzusetzen?
• Bist du hinsichtlich unterschiedlicher Arbeitsmethoden qualifiziert und kannst deshalb eine adäquate Entscheidung treffen?

Wenn du einfache oder komplizierte, also sich wiederholende Aufgaben hast, die bei einem erneuten Problem mit der identischen oder ähnlichen Vorgehensweise gelöst werden können, ist Scrum keine geeignete Methode. Hier kann es helfen, Prozesse mit Hilfe der Kanban-Methode zu visualisieren und die Durchlaufzeiten zu messen, um dann den Prozess zu verbessern. Dies setzt jedoch voraus zu messen, wie lange ein Vorgang dauert und an welcher Stelle er aus welchen Gründen hakt. Das musst du wollen.

Sind die Aufgaben komplex und lassen sich nur durch Ausprobieren Lösungen finden, dann kann Scrum hilfreich sein. In bestimmten Zeitabschnitten arbeitet sich das Team an eine Lösung heran. Nach jeder Iteration hält es kurz inne und reflektiert die Ergebnisse und die Zusammenarbeit. Für die nächste Iteration werden Ziele und eventuell neue Regeln der Zusammenarbeit beschlossen und der Prozess beginnt von vorn.

Es ist in Ordnung und sogar förderlich, dir einzugestehen, wenn du keine Ahnung hast oder du nicht in der Lage bist, die oben gestellten Fragen zu beantworten. Dann lass dir nur eines raten: lies nicht einfach nur ein paar populärwissenschaftliche Artikel und lege los. Scrum wird oftmals als einfache Methode benannt, was unserer Ansicht nach nicht korrekt ist, da sie eingesetzt wird, um mit Komplexität umzugehen. Unser Gehirn lernt durch Wiederholung und das ist wichtig; also nochmal: wir erinnern uns, dass Komplexität meint, dass auftretende Aufgaben nicht mit der identischen Lösung zu beherrschen sind, sondern Plan, Versuch, Lernen und Anpassung der Vorgehensweise benötigt werden. Lasse dich selbst ausbilden oder hole dir qualifizierte Hilfe. Mit qualifizierter Hilfe meinen wir nicht, dass alleine das Vorweisen einer Zertifizierung ein Garant für Wissen und Können ist. Bei der Auswahl können dir beispielsweise folgende Fragen helfen:

• Arbeitest du selbst nach Scrum, auch wenn du nicht Software entwickelst?
• Welche agilen Methoden hast du selbst bereits genutzt?
• Wann sind welche Methoden geeignet und welche Vor- und Nachteile bringen die Methoden mit sich?
• Woran misst du, ob die Methode zur Lösung des Problems passt?

Wer Scrum einsetzen will, muss Transparenz mögen. Benenne ein Problem, definiere Akzeptanzkriterien, wann es als gelöst gilt und arbeite methodisch an einer Lösung. Wenn du agile Methoden oder Scrum nur durch Umbenennen von bestehenden Meetings oder Rollen simulieren willst, um nach außen modern und interessant für Bewerber zu wirken, dann ist das keine gute Idee.

Mehr machen, weniger planen!

Scrum hat viel zu viele Meetings. In der Zeit kann man auch produktiv arbeiten! Lege Review, Retro und Planning zusammen und erledige alles ohne Vorbereitung in ein bis zwei Stunden. Alles andere wäre nicht effizient.

Wir wollen den Scrum Guide¹ hier nicht wiederholen, denn darin ist alles aufgeschrieben und viele schlaue, erfahrene Menschen haben hilfreiche Bücher und Artikel geschrieben. Am Anfang ist jede Veränderung schwer und eine häufig gestellte Frage ist, ob die Zeit, die bei Scrum in Planung und Reflexion investiert wird, nicht unverhältnismäßig sei. Die Antwort ist: nein. Je klarer das zu erreichende Ziel ist (Sprint Vision) und die hierbei benötigten Aufgabenpakete sind (User Stories), desto schneller ist ein Team während der laufenden Zeit (Sprint), da die priorisierten Aufgaben von jedem im Team verstanden worden sind und bearbeitet werden können. Je fokussierter ein Team ist, desto schneller ist es. Wenn ihr als Team mit Scrum startet, geben wir euch folgende Empfehlungen:

• Haltet die festgelegten Zeremonien (Review, Retrospektive, Planning, Refinement, Daily) genau ein. Haltet mindestens 10 Sprints genauso durch, wie sie definiert sind. Erst dann werdet ihr als Team in der Lage sein, entscheiden zu können, was für euch nicht hilfreich ist und wie ihr das ändern könnt.
• Haltet folgende Reihenfolge beim Sprintwechsel ein:

• Macht erst das Review und ladet hierzu Stakeholder ein, um Feedback zu bekommen und die Ergebnisse zu zeigen.
• Führt dann als Team eine moderierte Retrospektive durch, um die Zusammenarbeit zu reflektieren und Maßnahmen der Verbesserung zu definieren.
• Nehmt Maßnahmen aus der Retrospektive als User Stories in euer Backlog auf und plant sie im nächsten Sprint ein.

• Neue Sachen dauern am Anfang immer länger als gedacht. Mit der Zeit bekommt ihr Routine und ihr werdet schneller.
• Ihr werdet schnell die Idee haben, Zeremonien aus Zeitgründen zu kürzen oder zu streichen. Lasst es, es wirft euch nur zurück.
• Je klarer und detaillierter ihr eure Arbeit dokumentiert, desto einfacher wird es, in Stresssituationen durchzuhalten.

1 https://www.scrumguides.org/

Agil heißt flexibel!

Relativiere Verspätungen, Fehlplanungen und sinnlosen Aktionismus mit: Wir sind agil! Agilität ist schließlich ein Synonym für flexibel und ungeplant.

Wir können die Situationen nicht mehr zählen, bei denen spontan und ohne Absprache Pläne mit dem Satz: „Wir sind doch agil.“ geändert wurden. Das ist falsch - agil heißt nicht, dass jeder macht, was er will und jederzeit Dinge umentschieden werden können. Aus diesem Grund ist das Wort agil bei sehr vielen Menschen leider bereits sehr negativ belegt und verbrannt. Oftmals deshalb, weil Menschen das Wort verwenden, ohne Kenntnisse darüber zu haben, was agil im Hinblick auf Arbeitsmethoden eigentlich bedeutet.

Arbeiten nach agilen Prinzipien unterscheidet sich maßgeblich vom planungsgetriebenen Ansatz. Agiles Vorgehen ist ausschließlich wertgetrieben und eignet sich nur bei Problemen in einem komplexen Umfeld, also wo das Wie zur Lösung des Problems noch unbekannt ist. Agil bedeutet nicht ungeplant, sondern es wird regelmäßig ein überschaubarer Zeitrahmen geplant, bei dem sich verändernde Umfeldbedingungen in die Planung einfließen. Agil arbeiten bedeutet:

• Es gibt klare Regeln der Zusammenarbeit.
• Zeit und Budget sind fix.
• Der zu erreichende Umfang ist variabel, deswegen müssen die Dinge, die mehr wertschöpfend sind, vor den Dingen fertig gestellt und geliefert werden, die weniger wertschöpfend sind.
• Allen Beteiligten ist klar, was erreicht werden soll und wann das Ziel erreicht ist. Das Wie muss noch nicht im Detail geklärt sein.
• Der Plan für die nächsten Wochen, ein bis zwei Iterationen (ca. zwei bis vier Wochen pro Iteration) ist sehr konkret. Wie kommen wir dem Ziel näher?
• Tritt etwas ein, das dazu führt, dass in der aktuellen Iteration nicht am wichtigsten Thema gearbeitet wird, muss diese sofort gestoppt und neu geplant werden. Wenn nach dieser Iteration das Projekt zu Ende wäre, ist dann der maximal mögliche Wert geliefert?
• Je weiter man in die Zukunft blickt, desto unkonkreter ist der Plan. Was genau wird zu welchem Zeitpunkt wie gemacht, um dem Ziel näher zu kommen?
• Definiere Kennzahlen für Business und Technik, die dir zu jeder Zeit Auskunft darüber geben, ob die aus Gründen gesetzten Zielwerte erreicht, unter- oder übertroffen werden.

Tipp: Löse schwierige, schwer z...

Inhaltsverzeichnis

• Über die Autoren
• Laura Sophie Aichroth, M.Sc.
• ST Kambor-Wiesenberg, Dipl. Informatiker&MBA
• Inhaltsverzeichnis
• Vorwort
• Kapitel I: Management und allgemeine Demotivation
• Kapitel II: Agile washing
• Kapitel III: Personalarbeit und Haltungsfragen
• Kapitel IV: Entwickler und IT
• Kapitel V: Produktentwicklung und Kundenkontakt
• Impressum