Zitat von LaberKachelSülz im Beitrag #3
Hm, ich werde nicht warm damit. Es ist mir vieles zu unkonkret. Beispiele:
Angenommen ich habe ein Scrumteam für ein Produkt, zuerst mit 5 Leuten, nun sind es 8. Nun sollen noch vier Leute dazu kommen. Für orginal Scrum ist das zuviel. Was soll an der Frage falsch sein wie man Scrum skaliert?
"Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle." - das ist doch Scrum. Aber wie soll EIN PO das alles schaffen?
"Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block." - auch das ist doch Scrum.
"Organise your teams, that work on 1 product, to work in a single iteration..." - dito
"Move to cross functional line managers" - und wie sollen die konkret arbeiten? Was ist deren Ziel, die hängen die mt Scrummaster PO und Entwickler zusammen?
"Introduce a Human Operations system" - den Begriff habe ich noch nie gehört.
Ich versuche es mal mit einem Beispiel zu verdeutlichen, wie ich den von mir zitierten Blogartikel interpretiere.
Beispiel für ein Unternehmen:
Geschäftsführung --> Fachbereiche A, B, C --> IT-Abteilungen 1, 2, 3 / Betrieb / Datawarehouse
Zum "Ausprobieren" von Scrum sagt das Unternehmen nun IT-Abteilung 1, dass sie aus ihren Mitgliedern doch mal ein Scrum Team bilden sollen und die Scrum Events, Rollen und Artefakte benutzen wollen. Nun läuft es gut, das Team ist motiviert und glücklich und das Unternehmen glaubt, dass es agiler werden muss, weil die Anforderungen von außen sich häufiger und schneller ändern.
Frage: Wie geht man nun vor?
Was ich am häufigsten sehe ist, dass man in den vorhandenen Silos (einzelne Fachbereiche, einzelne IT-Abteilungen, Betrieb, Datawarehouse, ...) nun Scrum einführt bzw. mehrere Teams mit Scrum arbeiten lässt und glaubt/hofft, dass dadurch das ganze Unternehmen agiler wird. Das Problem daran ist, dass es nicht funktioniert. Denn die ganze Steuerung (z.B. durch Fachbereiche) ist Silo/Hierarchie getrieben. Die Teams arbeiten zwar ein bisschen nach Scrum, doch der Product Owner soll eher feste Anforderungen umsetzen und hat eigentlich nichts zu entscheiden (der Fachbereich entscheidet den Scope Monate vorher). Er kann auch nicht wirklich spontan die Software produktiv schalten, da sie zu viele Abhängigkeiten zu anderen Produkten des selben Unternehmens hat.
Ich persönlich habe langjährige Erfahrung damit, dass dies nicht funktioniert. Wenn das Unternehmen agiler werden will, dann muss es die Organisation verändern. Dann muss es in Frage stellen, ob die Silo-Struktur und damit das Silo-Denken mit der Anforderung der Agilität vereinbar ist. Dann muss die Organisation überlegen, ob sie nach jedem Sprint etwas in Produktion liefern kann, nur weil eine IT-Abteilung in Scrum Teams arbeitet oder ob nicht doch die Abhängigkeiten zu anderen Anwendungen, zum Betrieb und zu DataWarehouse das verhindern. So interpretiere ich den Artikel und deswegen stimme ich dem inhaltlich zu.