Eine Organisation zu agilisieren ist mit viel Arbeit verbunden. Viele Organisationen nehmen sich der Sache an und machen allesamt die gleichen Fehler, die zum scheitern führen können. Ich habe 9 aufgelistet, die mir am häufigsten begegnet sind.
Wenn meine Kollegen oder ich zu einem Einsatz gerufen werden, stecken einige der Organisationen in mehr als nur einem der 9 Punkte fest. Unser Job ist es zu erkennen was die Blockaden sind und diese aufzulösen. Ich hoffe ich kann euch mit diesem Beitrag dabei unterstützen, aus den Fehlern der anderen zu lernen.
1. Leck an Wissen
Häufig werden nicht alle Beteiligten in den Grundlagen geschult. Das fehlende Wissen führt zu Sackgassen, aus denen Teams nicht weiterwissen. Diese Sackgassen führen dazu, dass man alte Wege geht und agil nicht wirklich eine Chance hat. Das ist sehr schade, da eine einfache Grundlagenschulung die Unsicherheit nimmt.
Es ist notwendig, dass alle Beteiligten die Rollen und ihre Definition kennen, wissen wo die Einsatzgebiete von agilem Arbeiten sind, den Sinn und Ablauf der festen Events verstehen, sowie den korrekten Einsatz der Artefakte beherrschen.
2. Cherry Picking aus agilen Frameworks
Ich habe persönlich die Erfahrung gemacht, dass Organisationen sich schnell agil nennen wenn sie lediglich ein Daily machen und ein Ticketing System nutzen. In beinahe all diesen Fällen ist das Daily ein Statusmeeting, in dem sich alle Beteiligten zum Status äußern und in die Rechtfertigung rutschen. Diese „Dailys“ sind länger als 15 Minuten und stellen keine Hilfe für das Umsetzungsteam dar. Sie werden von dem Vorgesetzten dominiert und gelenkt und haben nichts mit einem echten Daily Scrum zu tun.
Weitere Cherries, die eine Organisation pickt, sind z.B. das Push and Pull Prinzip aus dem Kanban Modell, um ihre Interessen durchzusetzen. So werden ständig hoch priorisierte Tickets eingespielt, die sofort zu erledigen sind, obwohl sie doch angeblich nach Scrum arbeiten.
„Wir sind doch agil.“ Wird häufig dafür verwendet, Sachen nicht fertigzustellen und was anderes anzufangen. Das wäre nicht so schlimm, wenn die Anforderungsänderung aus Resultaten von Nutzerverhalten und Stakeholder Feedback stammt. Meistens sind das aber lediglich Meinungen der Produktverantwortlichen, die behaupten sie wissen was der User möchte, ohne ihn gefragt zu haben. Agil heißt nicht planlos. Es heißt auch nicht, dass man sich täglich trifft und ein Board nutzt. Lass dir nicht erzählen, dass ihr agil seid, wenn du deine Organisation jetzt wiedererkannt hast.
3. Keine echten Rollen
Scrum scheitert, wenn die Rollen nicht verstanden und richtig eingesetzt werden. Es scheitert ebenfalls, wenn es Doppelrollen beim Produkt gibt. Organisationen erhoffen sich Ersparnisse durch Doppelrollen, diese führen eher zu kostspieligem Scheitern der gesamten agilen Arbeiten.
Zum Scheitern verurteilte Doppelrollen, die ich persönlich in Organisationen erlebt habe:
– Der Scrum Master ist ebenfalls Teil des Dev-Teams.
– Der Scrum Master ist gleichzeitig Product Owner.
– Der Scrum Master macht irgendetwas anderes als „echten Job“.
– Der Product Owner ist Qualitätsmanager.
– Der Product Owner hat „eigentlich einen anderen Job“ jeglicher Art. Z.B. Kundenservice Mitarbeiter, Controller, Account Manager und weitere.
– Der Product Owner ist Stakeholder aus dem Marketing Bereich, wobei es noch weitere 4 große Stakeholder Gruppen in der Organisation gibt. Das führt dazu, dass die Anforderungen aus dem Marketing höher priorisiert werden und die anderen Bereiche keine faire Chance haben.
4. Mächtige Gegner in der Organisation
Du hältst das für Fiktion? Ich enttäusche dich ungern, aber je größer die Organisation ist, desto mehr persönliches Interesse und politische Machtspielchen gibt es. Gerät man in einen Machtkampf, kann es ganz schnell zu Ende sein mit der schönen neuen agilen Welt.
Nicht nur einmal habe ich solche Machtkämpfe erlebt und musste als Mediator fungieren. Schließlich muss es in einem professionellen Umfeld IMMER um das Wohl des Produktes gehen. Das ist einfach gesagt, allerdings spielt Vernunft bei solchen Machtkämpfen keine Rolle.
Eine Agilisierung bedarf den Rückhalt der Organisation. Die Scrum Master und Agile Coaches sind in der Bringschuld dafür zu sorgen. Das schaffen sie durch Verteilung von Wissen, neutrale Moderation bei Meinungsverschiedenheiten und Aufklärung in undurchsichtigen Situationen. Mächtige Gegner machen es nicht unmöglich, wenn ein Experte im Haus ist.
5. Versteifung auf eine Methode
Oder anders ausgedrückt: Die dogmatische Auslebung des Scrum Guides oder eines anderen agilen Frameworks.
Oft erlebe ich, dass Organisationen sich auf eine Methode festlegen, ohne empirische Erkenntnisse zu haben.
Wie kann das funktionieren? Gar nicht! Agiles Arbeiten basiert auf Empirie.
Es gibt zahlreiche agile Frameworks, insbesondere in skalierten Umfeldern, die dir erzählen, dass sie genau die richtige Methode für deine Organisationen sind. Ich kann dir SAFE sagen, dass das nicht funktioniert. Weil ich häufig als Feuerwehrmann für solche Fälle gerufen werde. Um es in Zahlen auszudrücken, von 11 großen Agilisierungen in skalierten Umfeldern die ich in den letzten 10 Jahren betreut habe, waren 4 Fälle ein Rückbau einer vermeintlich sicheren Methode für Agilität im skalierten Umfeld. „Reagieren auf Veränderungen überwiegt dem befolgen eines Plans.“ Heißt es in einem der agilen Werte.
Bleib agil und finde heraus, welche Elemente von skaliertem Scrum für deine Organisation funktionieren können. Probiere sie aus und passe sie regelmäßig an. Nur so bleibt deine Organisation agil. Das führt mich zum nächsten Punkt.
6. Agilisierung ohne Experten
Experten haben ihren Preis, das Versagen von Agilität ist allerdings deutlich teurer. Viele Organisationen versuchen eine hochkomplexe Agilisierung erst einmal ohne Experten. Per se ist das keine schlechte Idee. Wichtig ist, dass man rechtzeitig einen Experten dazu holt. „Start with what you have“ ein häufiger Satz, wenn es um Agilisierung geht. Starte mit dem was du hast. Schärfe deine Sensoren, ab welchem Punkt du einen ScrumArchitect oder erfahrenen Scrum Master/ Agile Coach hinzuziehen solltest.
Meine Kollegen und ich kommen häufig bei Kunden an, die bereits agil gestartet sind. In einigen Fällen wurde bereits so viel Schaden angerichtet, dass die Dev-Teams das agile Arbeiten nicht mehr ernst nehmen. Das bedeutet umso mehr Arbeit für meine Kollegen und mich und eine Verzögerung in der Einführung bis zur Performance Phase. Hab ein Gespür dafür, wann der richtige Zeitpunkt für einen Experten ist. Im besten Fall lässt du dich bereits im Vorfeld beraten. Nicht verzichten solltest du auf professionelle Schulungen durch Scrum Experten für alle Beteiligten, von Dev-Teams bis Stakeholder und das vor oder während des Starts.
7. Unterschätzung der Notwendigkeit eines echten Scrum Masters
In Punkt 3 habe ich bereits auf die nicht richtige Ausübung der Rollen hingewiesen. Schlimmer als das ist die Idee, dass man einige dieser Rollen gar nicht braucht. Der Scrum Master ist für nicht agile Organisationen ein besonderes Mysterium.
Wie ist es möglich, dass dieser einen ganzen Arbeitstag füllt? Brauchen wir überhaupt einen? Wer bereits agil arbeitet, wird das für einen Scherz halten.
Diese neue Rolle eines Servant Leaders wird meist erst in Aktion verstanden. Die Notwendigkeit einer neutralen Institution, die alte Gewohnheiten erkennt und zum agilen Arbeiten coacht wird in den ersten Wochen der Agilisierung deutlich.
Organisation die mit einem echten, freigestellten Scrum Master aus den eigenen Reihen starten, sind seltener als ein vierblättriges Kleeblatt. Sie Starten ohne diese Rolle.
In den wenigen Fällen in denen sie mit der Rolle starten, ist der erste Scrum Master, in mehr als den meisten Fällen jemand aus dem Dev-Team, oder jemand der einer anderen Vollzeittätigkeit nachgeht.
Leicht zu verstehen, schwer zu meistern heißt es wenn du Sutherland oder Schwaber fragst. Ich habe die Erfahrung gemacht, dass es nicht so leicht verstanden wird. Wenn es leicht zu verstehen wäre, dann würde die ebenfalls von den Scrum Urvätern stammende Aussage „Es funktioniert nur als Ganzes“ nicht ständig ignoriert werden. Willst du agil arbeiten? Brauchst du eine echten Scrum Master, der dafür freigestellt ist diese Rolle auszuüben. Das gleiche gilt übrigens auch für den Product Owner. Dieser wird allerdings in der Regel als notwendiger erachtet.
8. Zweigleisiges Fahren – Wasserfall & Scrum Mix
Organisationen, die nicht an agil glauben, versuchen es häufig in ein Wasserfall Projekt zu pressen. Das heißt tatsächlich es gibt einen Projektleiter, Milestones, einen Projektplan, sowie eine feste Ressourcenplanung.
Reaktion auf Veränderung in einer Wasserfall Welt ist der Start für die Supernova. Supernova nenne ich es, wenn innerhalb eines Produkts Wasserfall auf Agilität stößt. Menschen gehen den Weg des geringsten Widerstandes. Schön ist allerdings, dass wer einmal agil gearbeitet hat, sich so gut wie immer in agil und Selbstorganisation verliebt, sodass der Weg des geringsten Widerstandes für sie das agile Arbeiten ist. Nun kommt es in diesen Gebilden dazu, dass sich 2 Lager bilden, die ihren gewohnten Weg gehen.
Der Konflikt hat keinen Sieger. Der größte Verlierer ist allerdings das Produkt. Es hatte eine echte Chance marktgerecht zu werden, nun wird es in Iterationszyklen entwickelt, allerdings ohne echte Erkenntnisse als Live Produkt. Der Wasserfall Plan sieht einen Release erst zu einem bestimmten Datum und mit einem bestimmten Umfang vor. Wie bereits erwähnt, gewinnt bei der Supernova niemand. Meiner Erfahrung nach ist das Ergebnis ein klassisches Wasserfallprodukt mit zu vielen unnötigen Features und veralteter Technik, welches in Sprints entwickelt wurde. Diese „Selbstverarsche“ hat aber auch etwas positives, nämlich die ersten Berührungspunkte mit agilen Frameworks.
9. Unterschätzen der Unternehmenskultur
Einer die häufigsten Gründe, warum eine Agilisierungen scheitern kann, ist das Nichtberücksichtigen der Unternehmenskultur. Agiles, selbstorganisiertes, zielgelenktes und produktzentrisches Arbeiten beinhaltet mehr als die Einführung von Regeln. Es ist ein Kulturwandel.
Deine Organisation braucht z.B. eine gesunde Fehlerkultur. Wie wird in deiner Organisation mit Fehlern umgegangen? Empirie heißt Erkenntnisse sammeln. Zu wissen wie es nicht geht, also Fehler machen, ist einer der effizientesten Wege Erkenntnisse zu sammeln. Das ist nur einer von vielen Punkten, die Unternehmenskulturen ausmachen.
Ich habe aus meiner gesammelten Erfahrung heraus Punkte einer Unternehmenskultur die essentiell für die Agilisierung sind in einem anderen Beitrag aufgelistet. Beitrag: 8 Wichtige Unternehmenskultur Eigenschaften für die Agilisierung
Das waren die 9 Punkte, die ich als häufigste Agilisierungs-Impediments erlebt habe. Ich hoffe, dass dieser Beitrag dich beim agilen Arbeiten unterstützen kann.
Sende diesen Beitrag gerne an deine Kollegen, denn nichts ist bei der Agilisierung wichtiger als Erkenntnisse.
Danke für das Lesen.
