APM 13 – Scaling Agile Teil 2

Bernd Schiffer hat noch ein paar weitere Ansätze, wie agile Skalierung (Scaling Agile) in Unternehmen funktionieren kann, die im ersten Teil nicht drangekommen sind. Das schließen wir heute ab. Spannend am Ende die Frage: für wen ist Scaling Agile eigentlich eine Herausforderung? Denn: sobald man bei diesem Problem angekommen ist, sollten vorher eine ganze Reihe anderer Probleme (allgemeiner Entwicklungs-Workflow, Agil im Kleinen) gelöst sein, so dass die Skalierung gar nicht mehr so schwierig sein sollte.
avatar Toby Baier Paypal Icon Amazon Wishlist Icon Bitcoin Icon
avatar Bernd Schiffer

ScALeD

00:08:56

(Scaled Agile Lean Development — Entstanden aus Missmut mit SAFE — geleitet durch Prinzipien: Autonomie, Meisterschaft, Zweck (Dan Pink) — hochperformante Teams)  — Begeisterte Kunden, produktive Mitarbeiter, globale Optimierung (Abhängigkeiten reduzieren)  — Handlungsanweisungen und Werte (Werte sind dazu da, Werkzeuge und Prozesse einzusortieren — "Prinzipien sind Brücken zwischen Werten und Praktiken" (Bernd)) .

Product Development Flow

00:21:38

(Buch von Don Reinertsen — Studieren, nicht lesen! — Don beweist, dass agile Prinzipien richtig sind mit schlüssigen Argumentationsketten — Aus der Lean Development Ecke, aber die Prinzipien sind allesamt für agile Skalierung zu empfehlen — Dezentraliserung von regelmäßigen Entscheidungen — Innovation sollte nicht zentralisiert sein) .

Holacracy

00:31:33

(bei Zappos — nach dem dezentralen Experimentieren sollte die Implementierung zentral entschieden werden)  — Frische Ansätze:.

MAXOS

00:36:55

(Matrix of services — Genau wie die Technik in Microservices geteilt wird, passiert es auch mit Teams — Kleine Teams, Jedes mit eigener Vorgehensweise und Kultur — Google, Amazon, Facebook nutzen es — Blog post von Andy Singleton — Teams haben mindestens einen Service — Abhängigkeiten werden von Teams selbst entschieden — Nicht zu verwechseln mit Matrix-Organisation disziplinarisch/fachlich — Kultur muss nicht unbedingt konsistent sein, aber Schnittstellen müssen funktionieren — QA wird von Programmierern selbst gemacht — alle Tests werden automatisiert — Scrum und Agil sind zu langsam — keine Methode zum Kopieren) .

Scaling Scrum (Ansatz)

00:47:07

(irrtümlich Scaling Agile genannt)  — Scrum Inc (Jeff Sutherland) — Informationen hinter Paywall versteckt — Scrum selbst ist schon fraktal.

XSCALE

00:50:41

(Excellence Scale-Symmetry Continuous Autonomous Lean Ecosystem — aus Sydney (Australien) — bedient sich aus den verschiedenen bestehenden Modellen — obskur mit vielen Inhalten: Lean Startup, Open Space, Behaviour Driven Development, git... — "Alles was geht" (Toby)) .

Wie skaliert man Werte?

00:57:13

(Frage: ist agil für alle Oranisationen hilfreich? Verschiedene Lager — "Too-big-to-fail Organisationen sollten nicht agil werden" (Bernd) — Agil setzt einen gewissen Level an Softwareentwicklung voraus — Auf dieser Stufe kann man direkt mit Prinzipien arbeiten und braucht keine konkreten Handlungsanweisungen — DAD hat als Verkaufsargument, dass man weniger Coaches braucht, weil die Dokumentation alles abdeckt)  — Vielleicht muss man gar nicht skalieren (Vorher abklären: was soll durch die Skalierung erreicht werden — Wenn jemand Agile Skalierung als Problem nennt aber noch Probleme mit der Entwicklung selbst hat, sollte er diese vielleicht zuerst lösen) .

Ein Gedanke zu „APM 13 – Scaling Agile Teil 2

  1. Johannes Thönes

    Hallo Bernd,
    Hallo Tobi,

    beide Episoden fand ich sehr spannend und interessant, vor allem weil ihr mir einen guten Überblick gegeben habt, was es alles so gibt an “Scaling Agile” Prozessen.

    Ich habe allerdings so meine Bedenken, ob ein Prozess um Agile zu skalieren wirklich die richtige Lösung ist. Ist nicht jede Organisation so individuell, dass eine Standardisierung oft mehr schadet als nutzt? Klar, wenn man erfahrener Agile Coach wie einer von euch ist, kann man die Prozesse als Vorlage nehmen und sie an die Organisation anpassen. Nur: Veröffentlichte Prozesse werden (so meine Erfahrung) oft von Firmen genommen ohne groß nachzudenken und einfach ‘drüber gestülpt. Das passiert schon mit Scrum viel zu häufig. Aber dann noch einen Schritt drüber?

    Mein Kollege Barry O’Reilly hat ein Vorgehen von Lean Enterprise (abgeleitet von Lean Startup) beschrieben, der sich für mich besser als Startpunkt eignet. Da es kein fertiger Prozess zwingt es die Menschen (mehr) selbst nachzudenken. Ich habe da mit ihm für SE Radio drüber geredet (http://www.se-radio.net/2015/08/se-radio-episode-234-barry-oreilly-on-lean-enterprise/) und sein Buch in meinem Podcast besprochen (http://der-alltaegliche.de/2015/01/19/lean-enterprise-buchbesprechung-dap-057/).

    Vielen Gruß & Danke
    Johannes

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.