Scaled to Death

Scaled to Death
Lehren aus agilen Skalierungsvorhaben großer Konzerne
Dr. Timo Volkmer, November 2018
www.timovolkmer.com

Übersicht
▪ Was ist eigentlich Skalierung?
▪ Warum rede ich so viel von Scrum?
▪ Beobachtung 1: „Murcs of Murcs“ – Mehr Meetings, weniger Kommunikation.
▪ Beobachtung 2: „Die Agilitätspolizei“ – Neue Regeln, neue Schmerzen.
▪ Beobachtung 3: „Matrix Reloaded“ – Alter Wein in neuen Schläuchen.
▪ Beobachtung 4: „Demokratiefalle“ – Fairness bis zur Lähmung.
▪ Beobachtung 5: „Der P.O. als Team-Owner“ – Der Brei und die vielen Köche.
▪ Beobachtung 6: „Systemfehler“ – Wer ist hier der agilste Scrum Master?
© Dr. Timo Volkmer – www.timovolkmer.com

Was ist Skalierung?
Mit Skalierung meint man üblicherweise den Fall, wenn
mehrere Teams an der Herstellung eines Produktes parallel
arbeiten.
Mit anderen Worten: Wenn die Arbeit mehrerer Teams eine
starke Kopplung aufgrund von Abhängigkeiten zueinander
aufweist.

Warum rede ich so viel von
Scrum?
… weil es das ist, was ich beobachte.
Ich glaube nicht, dass man zwingend ein Framework wie
Scrum braucht, um agil zu arbeiten.

Murcs of Murcs
Mehr Meetings, weniger Kommunikation

9 Scrum Teams, 9 Product Owner und diverse Produktmanager. Getrennte Backlogs, Plannings und
Refinements. Gemeinsam soll eine Plattform mit stark gekoppelten Funktionalitäten entwickelt werden.
Ein anderes Unternehmen. 4 Entwicklungsteams, ein Product Backlog, ein Product Owner, sowie
gemeinsame Plannings und Refinements. Auch hier wird gemeinsam an einer Plattform entwickelt.
Auf Wunsch einiger in den Teams organisieren die Scrum Master ein Scrum of Scrums. Nach
kürzester Zeit kommt auch hier niemand mehr. Jedoch existieren auch keine Integrationsprobleme
und wir fanden auch raus warum …
Erste Beobachtung:
Zweite Beobachtung:
?
?
?
? Abhängigkeiten zwischen den Teams führen immer wieder zu Blockaden.
Ein Scrum of Scrums wird „verordnet“ aber nach kurzer Zeit kommt niemand
mehr. Die Kritik ist harsch, die Scrum Master ratlos.
Die Probleme bleiben bestehen.

Was passiert:
Selbstorganisation findet immer statt.
Im ersten Fall sorgt sie dafür, dass die Teams sich auf Ihr
Backlog und ihre Team-Tasks fokussieren. Unnötige Meetings
werden eliminiert.
Im zweiten Fall können die Teams das gemeinsame Ziel
erkennen und organisieren sich informell selbst (z.B. beim
Kaffee), so dass ein formelles Meeting überflüssig wird.

Die Agilitätspolizei
Neue Regeln, neue Schmerzen

Wir machen jetzt auch „Agil“ im Unternehmen. Neue Dinge wie Kanban-Boards, Stand-up
Meetings und Retrospektiven sprießen aus dem Boden. Alle fordern Partizipation,
Feedback- und Fehlerkultur.
Die Beobachtung:
Sämtliche etablierten Prozesse und Angewohnheiten werden
plötzlich belächelt, ja, sogar verhöhnt.
Alles muss jetzt „agil“ passieren. „Agil“ ist der neue Maßstab.
Es fallen Sätze wie: „… das ist dann aber nicht agil“ oder „Ihr
seid noch nicht soweit bei Agil“.
Kurzum: „Agil“ ist die neue Referenz. Was nicht „agil“ ist, ist
nicht gut.
Allerdings ändert sich auch irgendwie nichts, außer dass nun alle darüber reden, wie man zu
arbeiten hat. Als nächstes macht sich Frust breit und zu guter Letzt wird „Agil“ zum
Schimpfwort.

Was passiert:
Ob man es nun mag oder nicht, im Wirtschaftssystem ist der
einzig sinnvolle Gradmesser der kommerzielle Erfolg.
„Agil“ als Selbstzweck auszurufen ist sinnlos, sogar schädlich.
Die Referenz „Agil“ ist vollkommen nach Innen gerichtet. Das
Unternehmen beschäftigt sich vorwiegend mit sich selbst.

Matrix Reloaded
Alter Wein in neuen Schläuchen

Mehrere Teams entwickeln nun ein Produkt, die Notwendigkeit zur teamübergreifenden
Abstimmung während der Entwicklung ist deutlich sichtbar.
Der agile Methodenkoffer kennt natürlich auch darauf eine Antwort: Communities of
Practice (CoP). Gleich ruft man mehrere dieser teamübergreifenden CoPs ins Leben.
Die Beobachtung:
Da man das Vorgehen natürlich an die im Konzern gängigen
Glaubenssätze (z.B. Steuerung, Kontrolle, Regeln) anpassen muss, werden
gleich noch neue „CoP Leads“ bestimmt.
Experten werden von außerhalb der Teams beigesteuert, Regeltermine
festgesetzt und natürlich
bekommt jede CoP auch einen Auftrag.
Plötzlich ist nichts mehr wie es war, überfüllte Kalender, Scope Creep, Revierstreitigkeiten … die CoPs
generieren zusätzliche Arbeit, die niemand machen möchte.
CoP Lead
P.O.

Was passiert:
Menschen empfinden es als Widerspruch,
in selbstorganisierten (Scrum-)Teams zu sein,
Teamautonomie zu leben, und andererseits von außen durch
gelenkte CoPs fremdgesteuert zu werden.
Die Selbstorganisation der Menschen sorgt nun meist für
Ablehnung, Kampf um mehr Freiraum und letztlich
für weniger Kooperation.

Die Demokratiefalle
Fairness bis zur Lähmung

Gerne werden hierarchiefreie Unternehmensstrukturen und Partizipation aller gefordert. Irgendwie
bedeutet agil ja auch Augenhöhe und da sind Entscheidungen „von oben herunter“ per se falsch.
Die Beobachtung:
Für jede noch so kleine Entscheidung wird ein
Meeting einberufen. Alle müssen „abgeholt“
und „mitgenommen“ werden.
Da steigt das eine um das andere Mal der
Frustlevel bei vielen enorm ob der ständigen
Diskussionen.
Der ständige Zwang zu Basisdemokratie lähmt das Unternehmen. Wollte man mit diesem „Agil“
aber nicht auch irgendwie schneller werden?

Was passiert:
Soziale Systeme bilden (natürliche) Hierarchien; so finden wir
u.A. die Experten für bestimmte Problemstellungen.
Ein Wirtschaftsunternehmen ist den Gesetzen des
Wirtschaftssystems unterworfen. Entscheidungen müssen
möglichst schnell und mit Sachexpertise getroffen werden.
Ein dogmatisch-demokratischer Ansatz verhindert das.
Die Experten sind stets gezwungen, sich auch gegenüber nicht-
Experten zu erklären.

Der P.O. als Team-Owner
Der Brei und die vielen Köche

Bei mehreren Teams mit Scrum, wird häufig nach der Devise gehandelt: Jedes Team braucht einen P.O.,
und jeder P.O. braucht ein eigenes Product Backlog.
Die Beobachtung:
Man macht also einfach Copy & Paste des gelernten Scrum
Bildes. Dummerweise kann man dann oft beobachten, dass die
Abstimmungsprobleme zwischen Teams eher zunehmen.
Die P.O.s kooperieren nicht, sondern verfolgen ihre eigene
Agenda. Schließlich hat ein P.O. ja die Entscheidungshoheit über
sein Backlog.
Oft werden als Folge Abhängigkeiten nicht erkannt oder nicht
beachtet. Immer wieder kommt es zu Verzögerungen,
Blockaden und schlussendlich zu Schuldzuweisungen.

Was passiert:
Das Ziel ist, ein Produkt zu entwickeln,
jedoch sind die Teams organisatorisch nicht so aufgestellt.
Mehrere Product Owner und mehrere Product Backlogs
fördern Alleingänge der P.O.s und nur auf das eigene Backlog
bezogene Handeln der Teams.
Deshalb: Richte die P.O. Rolle am Produkt aus.
Partitioniere große Produkte in Produktbereiche,
die sich gut entkoppeln lassen.

Systemfehler
Wer ist hier der agilste Scrum Master?

Bei der Scrum Skalierung sind meist mehrere Scrum Master anzutreffen. Fast immer bilden auch sie ein
Team, dass den Scrum Teams in ihrer Gesamtheit zu besserer Zusammenarbeit verhelfen soll.
Die Beobachtung:
Fast immer beobachte ich im Scrum Master Team jedoch eher Misstrauen und
Machtkämpfe anstatt Kooperation.
Wessen Team „performt“ am Besten? Wer ist hier der coolste Fisch im Teich
der Scrum Master?
Die angelegten Rollenbeschreibungen wie „Der Scrum Master ist für die
Leistung des Teams verantwortlich“ oder „Der Scrum Master schützt sein Team
…“ spiegeln interessanterweise die Haltung der Scrum Master wieder.
Anstatt die Scrum Einführung für einen echten Neuanfang zu nutzen, findet man die bisherige
Unternehmenskultur im neuen Gewand auch hier wieder.

Was passiert:
Scrum einzuführen ist eine Sache. Kulturelle Veränderung zu
ermöglichen eine andere.
Kultur ist ein mächtiger Stabilisator, der sich auch durch
neue Modelle nicht beeindrucken lässt.
Natürlich agieren auch Scrum Master genauso wie der
Systemkontext es fordert. Also anschlussfähig zur Kultur.
Erst ein wirksamer Schutz vor der bestehenden Kultur würde
helfen, neue Verhaltensmuster zu etablieren.

Was ich mitgeben möchte:
• Das einzige was wirklich skaliert, ist Selbstorganisation; Schaffe ein System, in dem Du
Selbstorganisation zur Erreichung der Unternehmensziele nutzbar machst!
• Stärke informelle Kommunikation!
• Minimiere interne Referenzen; Ermögliche Orientierung an externen Referenzen!
• Sorge dafür, dass Entscheidungen dort getroffen werden können, wo maximale Expertise
zur Problemstellung existiert!
• Setze Dich mit Deinem Produkt auseinander, partitioniere Dein Produkt fachlich und
strukturiere Teams für Deine (Teil-)Produkte: Beachte Conways Gesetz!
• Unterscheide zwischen formellen und sozial legitimierten Hierarchien; Nutze sozial
legitimierte Hierarchien wann immer möglich.
• Betrachte Dein Unternehmen als Soziales System und setze Dich mit der Systemtheorie
auseinander!

Scaled to Death

Recommandé

Recommandé

Contenu connexe

Similaire à Scaled to Death

Similaire à Scaled to Death (20)

Scaled to Death