Einen wunderschönen guten Morgen, liebe Community.
Es ist Montag - Zeit für eine neue Frage der Woche.
Wenn du in einem Unternehmen Agilität fördern und erste agile Methoden einbringen müsstest - womit würdest du starten?
Was sind deine Gedanken dazu? Lass uns dazu gerne in den Austausch gehen.
Viele Grüße,
Dani
Hallo Dani,
wieder mal eine schöne Frage mit Potenzial für Kontroversen 
Aus meiner Sicht ist es genauso wichtig zu fragen, WO man die Methoden einbringt. Ich war schon mehrfach Teil von “grassroots approaches”, die dann im Verlauf “ge-SAFed” wurden. Für viele, die dann in der agilen Arbeitsweise schon eine gewisse Reife hatten, ein etwas frustrierender (Rück-)Schritt.
Mit den Jahren komme ich immer mehr zur Erkenntnis, dass im klassisch hierarchischen Unternehmen oben angefangen werden sollte. Nicht nur mit Schulungen zur Agilität für die Führungsriege, die dann das Agile an die unteren Ebenen delegiert, aber selbst nicht so arbeitet und eine Agile Transformation womöglich noch als Wasserfall-Projekt aufsetzt.
Anfangen würde ich mit einem Kanbanboard, Daily und Retro. Also nicht gleich Kanban mit WIP-Limits und Co., sondern richtig einfach. Ergeben sich im Verlauf der Arbeit die Gründe, warum es z.B. WIP-Limits gibt, dann kann man es entsprechend iterativ erweitern. Es wird anfangs schon genug Diskussionen geben, die sich meist um Prioritäten und Transparenz drehen. Wichtig sind anfangs auch die Inspect&Adapt Events, Daily und Retro. Läuft es irgendwann gut, dann kann man sicher auch auf kontinuierliches Inspect&Adapt umsteigen und die Retros weglassen, aber da sind wir sicher schon lange nicht mehr am Anfang.
Schönen Gruß
Stuart
Hm, ein Stück weit ist es doch so wie bei fast allem - Es kommt darauf an.
Ich gebe @stuarth Recht, in sog. klassischen Unternehmen macht es durchaus Sinn “oben” anzufangen. Nichts desto weniger muss meiner Erfahrung nach aber auch die breite Basis abgeholt und mitgenommen werden, damit nicht (schon wieder) etwas Top → Down in Bezug auf Arbeitsweise und Struktur vorgegeben wird. Vom Vorgehen her würde ich erstmal erfassen wie es um das bereits bestehende agile Verständnis bestellt ist und darauf dann weitere Maßnahmen aufbauen.
Ich würde mich ebenfalls im KANBAN bedienen, jedoch erstmal damit beginnen Prozesse und Agreements explizit zu machen und erste Rituale zu etablieren. Ich habe die Erfahrung gemacht, dass ein “KANBAN-Board” sehr schnell dazu verleitet zu denken “Hey, wir sind voll agil unterwegs.”, auch wenn die agile Transformation möglicherweise noch ganz am Anfang steht.
Hallo in die Runde, ich versuche mich mal mit meinem ersten Beitrag in dieser Community.
Mir wäre wichtig das Mandat zu klären und welche Ziele und Erwartungen existieren, seitens Management.
Daraus ergibt sich ein Backlog mit sicherlich vielen Punkten die geklärt und priorisiert werden möchten.
Somit wäre auch ein Kanban zur Visualisierungen meine erste Wahl.
Ich würde als Start fragen: wozu?
Das wäre auch meine erste Frage.
Wobei soll euch Agilität helfen?
Wofür wollt ihr es einsetzen?
Erwartungen, Wünsche und Bedürfnisse klären, um zu verstehen, warum eine Firma/Organisation glaubt Agilität könne ihnen weiterhelfen.
Wie ja bereits hier von einigen beschrieben wurde, ist es wichtig, dass das Unternehmen / Team / Department / Business Unit versteht, warum sie denken, dass sie Agilität einbringen wollen.
Da habe ich in Gesprächen schon einige Antworten erlebt, zum Beispiel teilte mir ein COO eines SW Outsourcing Unternehmens mit: “Weil es gut für unser Branding ist”. - Na ja, wenigstens ehrlich.
Ich denke, dass sich viele Unternehmen zu Beginn gar nicht bewusst sind, wie viele Änderungen die Einführung von Agilität für das komplette Unternehmen bedeutet. Und vor allem, dass dies auch die Arbeitsweise auf Geschäftsführungs-Ebene ebenso beeinflusst. Es reicht nicht, einfach das Team Scrum machen zu lassen und ihnen zu sagen, dass sie als Team operieren und das Produkt machen sollen; aber man misst und evaluiert individuelle Leistung und zahlt so Boni aus.
Nach meine Erfahrung kommt es bei der Einführung immer auf den Kontext an:
Aber natürlich sind das oben eher Beispiele, wie man verschieden vorgesehen kann. Am Ende ist für mich das Grundverständnis der folgenden Dimensionen auf oberster Entscheidungsebene wichtig:
Das sind natürlich nur meine Erfahrungen.
Hi Chris und herzlichen willkommen im AgileHub!
Danke für das Teilen deiner Erfahrungen, die ich als sehr wertvoll empfinde und absolut teile. Ich finde deine Ausführungen echt interessant, weil du gefühlt einen Dienstleisterblick darauf wirfst. Ergänzend würde mich noch mal interessieren, wie du den Purpose “gut für Branding” bewerten würdest? Was denken die Community dazu?
Danke, Tim.
Der Purpose “gut für Branding” ist ja zunächst ein Indiz.
Wenn das gesagt wird und man danach wirklich an Veränderungen interessiert ist und die eigene Herangehensweise grundlegend hinterfragt, ist das ja auch gut. Ich würde dann halt sicherstellen, dass dies vielleicht nicht als Vision / Goal in die Transformation eingebettet wird, sondern etwas Inspirierendes formuliert wird.
Aber: Meist wird das gesagt, weil man sich von der Agilität einen Shortcut versprich. Und deshalb bin ich da initial immer ein wenig skeptisch. Und so war es dann auch hier der Fall.
Ich hatte bei der besagten Firma begonnen, einen wöchentlichen Workshop zu organisieren, wo ich das C-Level bat, sich konstant zu hinterfragen, was sie in der kommenden Woche als Organisation verbessern wollen, um agiler zu werden. Nach 2 Events bat mich der COO, das zu unterlassen.
Danach arbeitete ich nur mit den Teams, das hatte aber keinen grossen Effekt, da die Teams zu abhängig vom C-Level war. Falsche Deadline-Versprechungen und ein teilweise archaisches Verständnis von Software-Entwicklung (aus den 80ern) machte es den Projektleitern sehr schwer, gute Produkte zu entwickeln.
TL;DR: Was halte ich von dem purpose? It depends. Aber meistens ist es doch ein Indiz, dass viele nicht an Veränderung interessiert sind, sondern das doch eher als Shortcut sehen.